Kubernetes-валидаторы и где они обитают

• URL: https://github.com/datreeio/datree 

• Описание: линтер синтаксиса Kubernetes манифестов и Helm чартов + проверка на соответствие лучшим практикам.

• Тюнинг параметров: policy-as-a-code, стандартные проверки на практики, пользовательские проверки, проверки на deprecated ресурсы и так далее.

• Возможность тестирования кластера: через admission webhook.

• Замеченные особенности: условно бесплатная, 1000 бесплатных проверок в месяц

Datree на самом деле уже не просто cli утилита, а целый проект, включающий в себя облачный дашборд, Admission Controller для Kubernetes и возможность мониторить сразу несколько кластеров, получая данные централизованно. Также есть возможность использовать её в GitOps подходе (совместно с ArgoCD, Flux и другими) и писать свои детальные правила валидации манифестов. К сожалению, за полный набор плюшек надо платить, но CLI инструментом можно пользоваться практически безвозмездно (1000 бесплатных проверок в месяц). Является проектом-участником CNCF. 

Давайте приступим.

# .gitlab-ci/jobs/integration-kubernetes.yaml .datree_lint:   image:      name: dtzar/helm-kubectl:3.7.2   variables:     DATREE_VERSION: 1.6.4-rc     DATREE_RAW_PATH: ''     DATREE_HELM_PATH: ''   before_script:     # Install datree     - wget https://github.com/datreeio/datree/releases/download/${DATREE_VERSION}/datree-cli_${DATREE_VERSION}_Linux_x86_64.zip     - unzip -n datree-cli_${DATREE_VERSION}_Linux_x86_64.zip     - mv datree /usr/local/bin     - datree config set offline local   script:     - >       if [[ -z ${DATREE_HELM_PATH} ]]; then         datree test ${DATREE_RAW_PATH} --no-record --ignore-missing-schemas ;       elif [[ -z ${DATREE_RAW_PATH} ]]; then         helm plugin install https://github.com/datreeio/helm-datree         helm dependency build ${DATREE_HELM_PATH} ;         helm datree test ${DATREE_HELM_PATH} --no-record --ignore-missing-schemas;                                                   fi  # .gitlab-ci.yml raw-06:   stage: datree   variables:     DATREE_RAW_PATH: 'kube/raw/*'   tags:     - docker   allow_failure: true   extends: .datree_lint  helm-06:   stage: datree   variables:     DATREE_HELM_PATH: 'kube/helm/parrot-app'   tags:     - docker   allow_failure: true   extends: .datree_lint

После выполнения пайплайна мы увидим вот такую картину:

Как мы видим, утилита успешно справилась с задачей и даже направила нам ссылку на просмотр политик. Там нас встретит окно входа в аккаунт Datree, но об этом далее по тексту. Также, как и у некоторых предыдущих утилит, можно менять вывод программы (—output=simple/yaml/json/xml/JUnit). 

Мы же, не отвлекаясь, переходим к настоящему монстру валидации Kubernetes манифестов, да и самих кластеров – Kubescape.

7. Kubescape

• URL: https://github.com/kubescape/kubescape 

• Описание: линтер синтаксиса Kubernetes манифестов и Helm чартов + проверка на соответствие лучшим практикам.

• Тюнинг параметров: настройки через аргументы командной строки

• Возможность тестирования кластера: через cli

• Замеченные особенности: отсутствуют

Данная утилита позволяет сканировать ваши конфигурации, кластера Kubernetes, описывает, какими CIS практиками это обусловлено, и заботливо выводит информацию о них в выводе. Также она позволяет генерировать отчеты в различных форматах, в том числе pdf и html. Похожим инструментом, только не для Kubernetes, а для UNIX подобных систем я бы назвал lynis (да простят меня специалисты по информационной безопасности за такое сравнение). Является проектом-участником CNCF.

Бежим пробовать!

# .gitlab-ci/jobs/integration-kubernetes.yaml .kubescape_lint:   image:      name: dtzar/helm-kubectl:3.7.2   variables:     KUBESCAPE_VERSION: 'v2.0.183'     KUBESCAPE_RAW_PATH: ''     KUBESCAPE_HELM_PATH: ''     KUBESCAPE_WARNING_SEVERITY: "high"   before_script:     # Install kubescape     - wget https://github.com/kubescape/kubescape/releases/download/${KUBESCAPE_VERSION}/kubescape-ubuntu-latest     - apk add curl gcompat --no-cache     - mv kubescape-ubuntu-latest /usr/local/bin/kubescape     - chmod +x /usr/local/bin/kubescape   script:     - >       if [[ -z ${KUBESCAPE_HELM_PATH} ]]; then         kubescape scan ${KUBESCAPE_RAW_PATH} --severity-threshold ${KUBESCAPE_WARNING_SEVERITY};       elif [[ -z ${KUBESCAPE_RAW_PATH} ]]; then         helm dependency build ${KUBESCAPE_HELM_PATH} ;         kubescape scan ${KUBESCAPE_HELM_PATH} --severity-threshold ${KUBESCAPE_WARNING_SEVERITY};                                       fi  # .gitlab-ci.yml raw-07:   stage: kubescape   variables:     KUBESCAPE_RAW_PATH: 'kube/raw/*'     KUBESCAPE_WARNING_SEVERITY: "high"   tags:     - docker   allow_failure: true   extends: .kubescape_lint  helm-07:   stage: kubescape   variables:     KUBESCAPE_HELM_PATH: 'kube/helm/parrot-app'     KUBESCAPE_WARNING_SEVERITY: "high"   tags:     - docker   allow_failure: true   extends: .kubescape_lint

Как можно увидеть, вывод достаточно подробный. Также его можно представить в других форматах (аргумент –format = pretty-printer/json/junit/Prometheus/pdf/html/sarif) или поставить некий уровень «очков» проверки через аргумент —severity-threshold (что отсылает нас к Polaris). Этой же утилитой мы способны через CLI проверить и наш кластер на наличие проблем с настройкой.

Работа над ошибками

Таким образом, мы рассмотрели семь утилит для проверки Kubernetes конфигураций, а наш неадекватный пайплайн превратился в нечто подобное:

Теперь попробуем внести в наш манифест все необходимые исправления, дабы каждый из наших валидаторов разрешил нам последующий деплой. Некоторые из них требуют наличие в конфигурации PodDisruptionBudget и NetworkPolicy, в данной статье мы опустим их листинг, так как знающие люди их и без линтеров не игнорируют, а время читателя не резиновое. Также для работы нашего приложения необходимо осуществить его пересборку, убрав большую часть проблем на этапе сборки самого образа (привилегированные порты, запуск от привилегированного пользователя и другое). Аналогичные манифесту изменения внесем и в наш Helm чарт.

--- apiVersion: apps/v1 kind: Deployment metadata:   name: bird   labels:     author: "IvanIvanov" spec:   replicas: 3   strategy:     type: RollingUpdate     rollingUpdate:       maxSurge: 2        maxUnavailable: 0   selector:     matchLabels:       app.kubernetes.io/name: parrot-app   template:     metadata:       labels:         app.kubernetes.io/name: parrot-app     spec:       containers:         - name: bird           image: vregret/parrot-uprivileged:0.1           imagePullPolicy: Always           securityContext: #https://snyk.io/blog/10-kubernetes-security-context-settings-you-should-understand/             allowPrivilegeEscalation: false             readOnlyRootFilesystem: true             runAsNonRoot: true             runAsUser: 10000             runAsGroup: 10000             capabilities: #https://man7.org/linux/man-pages/man7/capabilities.7.html               drop:                  - "all"             seccompProfile:               type: RuntimeDefault             seLinuxOptions:               level: "s0:c123,c456"           resources:             requests:               memory: "64Mi"               cpu: "250m"               ephemeral-storage: "5Mi"             limits:               memory: "64Mi"               cpu: "250m"               ephemeral-storage: "10Mi"           ports:             - name: http               protocol: TCP               containerPort: 8080           livenessProbe:             httpGet:               path: /               port: 8080             initialDelaySeconds: 5             periodSeconds: 3           readinessProbe:             httpGet:               path: /health               port: 8080             initialDelaySeconds: 5             periodSeconds: 3           volumeMounts:           - mountPath: /var/cache/nginx             name: cache           - mountPath: /var/run             name: pid       volumes:       - name: cache         emptyDir:           sizeLimit: 5Mi       - name: pid         emptyDir:           sizeLimit: 1Mi  --- apiVersion: v1 kind: Service metadata:   name: parrot   labels:     app: parrot     app.kubernetes.io/name: parrot-app spec:   type: ClusterIP   selector:     app.kubernetes.io/name: parrot-app   ports:     - port: 8080       name: http       protocol: TCP       targetPort: 8080  --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata:   name: parrot   labels:     app: parrot     app.kubernetes.io/name: parrot-app spec:   rules:     - host: parrot.aperture.loc       http:         paths:         - path: /           pathType: ImplementationSpecific           backend:             service:               name: parrot               port:                 number: 8080

Листинг исправленного манифеста

От себя замечу, что даже просто работа по удовлетворению всех хотелок линтеров – весьма занимательное и познавательное занятие. Всем советую, даже если не хочется их потом вносить в свой пайплайн.

На выходе получаем вот такую милую глазу картину:

Казалось бы, всё: мы получили некоторое понимание по работе утилит, можно просто выбрать одну и добавить в свой пайплайн, или улучшить всё это, например, сделав отельный DevSecOps репозиторий, собрав отдельный образ под линтинг манифестов, и дергать его из других репозиториев через Triggered pipelines.

Но что, если «собака-подозревака» в нашей голове хочет большего, если доверия к пайплайну нет, так как разработчики имеют kube-config до продуктового кластера, если хитрые инженеры не хотят запоминать правила написания манифестов отдавая всю работу CI/CD, чем снижают коэффициент Time-to-market? Давайте успокоим себя еще несколькими способами, активно используемыми в сообществе DevOps — рассмотрим сущность Admission Controller Kubernetes и подход Shift-left.

Валидация с помощью Kubernetes Admission Controller и использование подхода Shift-Left

«Everything about this place just doesn’t feel right».

The Count of Tuscany. Dream Theater

Итак, если не копипастить документацию Kubernetes, Admission Controller — это сущность в API Kubernetes, позволяющая проверять или изменять (validation или mutation соответственно) запросы к API от клиентов. В нашем случае мы рассмотрим Polaris и Datree как сущности, которые можно установить в кластер Kubernetes в качестве Admission Webhook серверов. Они будут пропускать через три сита себя применяемые конфигурации и принимать решение о том, стоит ли их пропустить/изменить. Согласно RoadMap Kubescape, данная функция скоро появится и у него.

Начнем, пожалуй, с Polaris — с ним мы пройдем по всем граблям в развертывании Admission Webhook сервера. Основная часть граблей связана с тем, что все запросы (webhook) к API Kubernetes должны осуществляться с использованием tls, а значит, мы должны не просто поставить в Kubernetes приложение, но сформировать csr запрос на сертификат, заверить его во внутреннем удостоверяющем центре Kubernetes и используя полученный от УЦ сертификат, поднять Polaris. Все манипуляции мы будем проводить локально в кластере, созданном через Kind, который также отлично можно использовать и в рамках CI/CD, и как плацдарм для обкатки различных решений. Дабы не тратить ваше время, приведу примерный скрипт для развертывания Polaris Admission controller в Kubernetes:

#!/bin/bash set -e # Добавляем репозиторий Helm helm repo add fairwinds-stable https://charts.fairwinds.com/stable helm repo update mkdir polaris-certs  # Генерируем ключ openssl genrsa -out ./polaris-certs/polaris-webhook.key 2048  # Создаем конфигурацию запроса сертификата cat<<EOF > ./polaris-certs/polaris-webhook.conf [ req ] default_bits = 2048 prompt = no default_md = sha256 req_extensions = req_ext distinguished_name = dn [ dn ] O = system:nodes CN = system:node:polaris-webhook.polaris.svc.cluster.local [ req_ext ] subjectAltName = @alt_names [ alt_names ] DNS.1 = polaris-webhook DNS.2 = polaris-webhook.polaris DNS.3 = polaris-webhook.polaris.svc DNS.4 = polaris-webhook.polaris.svc.cluster.local EOF  # … генерируем запрос на сертификат … openssl req -new -key ./polaris-certs/polaris-webhook.key -out ./polaris-certs/polaris-webhook.csr -config ./polaris-certs/polaris-webhook.conf  # … на базе созданного запроса формируем запрос (каламбур) и направляем его в Kubernetes … cat <<EOF | kubectl apply -f - apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata:   name: polaris-webhook spec:   request: $(cat ./polaris-certs/polaris-webhook.csr | base64 | tr -d "\n")   signerName: kubernetes.io/kubelet-serving   usages:   - digital signature   - key encipherment   - server auth EOF  # … помогаем Kubernetes аппрувнуть запрос и выпустить сертификат … kubectl certificate approve polaris-webhook  # … забираем сертификат … kubectl get csr polaris-webhook -o jsonpath='{.status.certificate}' | base64 --decode > ./polaris-certs/polaris-webhook.crt  # Применяем сертификат в Kubernetes и развертываем Polaris передав ему также CA Bundle Kubernetes kubectl create ns polaris kubectl -n polaris create secret tls polaris-webhook --cert=./polaris-certs/polaris-webhook.crt --key=./polaris-certs/polaris-webhook.key  helm upgrade --install polaris fairwinds-stable/polaris -n polaris -f values.yaml --set webhook.caBundle=$(kubectl get configmaps -n kube-system extension-apiserver-authentication -o=jsonpath='{.data.client-ca-file}' | base64 | tr -d "\n")

Сразу замечу, что сталкивался с забавным моментом. Так как применение Validation Admission Webhook Configuration происходит мгновенно, последующее развертывание подов Polaris может не произойти из-за попытки API Kubernetes обратиться к Polaris для проверки этих самых подов.

Решение достаточно простое – удалить сущность validatingwebhookconfiguration из кластера, подождать старта подов и после этого применить повторно. В идеале – этот момент, а точнее последовательность деплоя, нужно автоматизировать в Iaac репозитории или через Helm hooks. Правила, которыми можно настраивать Polaris, можно явно задать в values.yaml Helm чарта.

После развертывания деплой ненадежной версии приложения будет блокироваться:

Теперь попробуем провернуть подобную процедуру с Datree. Данная система уже не требует такой подготовки и устанавливается гораздо более просто, выполняя под капотом все вышеописанные действия.

#!/bin/bash set -e helm repo add datree-webhook https://datreeio.github.io/admission-webhook-datree helm repo update helm install -n datree datree-webhook datree-webhook/datree-admission-webhook --debug \ --create-namespace \ --set datree.token=dba0xxxx-xxxx-xxxx-xxxx-4acaf52axxxx \ --set datree.clusterName=$(kubectl config current-context)

В datree.token мы должны передать токен, получаемый при регистрации и оформлении подписки Datree. В данном примере мы используем тестовый токен, выданный для тестирования на ограниченный срок. 

Вывод в консоли при попытке применить наш плохой манифест будет выглядеть примерно так:

Обратим внимание на консоль – Datree автоматически формирует ссылку, по которой можно перейти в Datree Dashboard и посмотреть отчет по данной проверке, а также политики и другие «ништяки» данной системы.

Таким образом, мы получили возможность обезопасить кластер Kubernetes от мисконфигураций непосредственно при обращении к нему – это здорово и позволяет спать чуть более спокойно. Однако есть ещё способ проверки манифестов, позволяющий ускорить развертывание приложений и не позволяющий попасть неправильным манифестам не только в Kubernetes, но и в git репозиторий. Немного поговорим про shift-left подход.

Основной смысл и цель подхода — это смещение «влево» (ваш кэп), то есть дать возможность IT-специалистам проверять код и конфигурации до их попадания в систему контроля версий. Реализуется это различными способами, но в ходе изучения данной темы я чаще всего наблюдал использование утилиты pre-commit, которая позволяет настраивать git hooks и внедрять проверку кода различными способами в зависимости от этапов работы с git репозиторием. Она обладает хорошей документацией, которая помогает во всём разобраться и писать свои хуки. Наша же задача – попросить данную утилиту сформировать hook, который бы проверял измененные файлы перед коммитом в системе контроля версий. В качестве утилиты для проверки кода будем использовать kube-score, предварительно установленную на компьютере инженера.

Настройка Pre-commit производится добавлением в корень репозитория файла .pre-commit-config.yaml.

repos: #https://pre-commit.com/#advanced -   repo: local     hooks:     - id: kubernetes-validation-kube-score       name: kubernetes-validation-kube-score       description: Validation kubernetes manifests via kube-score       entry: ./.lint.sh                                language: script       types_or:          - text       verbose: true       files: "^kube/"

Предположим, что по принятым нами стандартам оформления репозиториев, манифесты приложения располагаются в каталоге kube/. Стоит учитывать и то, что в нашем репозитории есть как манифест, так и Helm чарт приложения, а значит, для утилит которые не способны сами шаблонизировать чарт, изменение какого-нибудь template/deployment.yaml повлечет ошибки в валидации go template, который используется Helm. Чтобы  исправить сложившуюся ситуацию, был составлен небольшой скрипт, который позволяет отличать манифесты от чартов и при необходимости проверки чарта – шаблонизировать его для проверки. Данный скрипт располагается в корне проекта и будет вызываться хуком git. Также ничего не мешает в конфигурации pre-commit указывать git репозиторий со всеми необходимыми конфигурациями и скриптами, что упрощает централизацию и переиспользование. Примерный листинг скрипта:

#!/bin/bash set -e # Поиск чартов в репозитории (по наличию файла Chart.yaml) что позволяет найти как обычные чарты так и umbrella чарты (правда для которых необходимо использовать helm dependency build) CHARTS_LOCATIONS=$(find . -name "Chart.yaml" -type f | xargs dirname | sed 's/.\///') # Получение пути до измененного файла (также отображается в git status) FILE=$1 its_chart=false # Сравнение пути до измененного файла с путями до Helm чартов for i in $CHARTS_LOCATIONS   do     if [[ $(echo $FILE | xargs dirname) == $i* ]]         then           its_chart=true           target_helm_chart=$i           break         fi   done  # Непосредственно проверка в зависимости от типа ресурса if $its_chart   then     echo "$FILE - It's a part of Helm chart"     helm template $target_helm_chart | kube-score score -    else     echo "$FILE - It's a Kubernetes raw manifest"     kube-score score $FILE   fi

Соглашусь с тем, что данный скрипт имеет определенные недостатки, но для проверки работы pre-commit подходит неплохо. Само применение настроек и hook происходит командой pre-commit install в корне репозитория (это единственное действие, которое необходимо совершить инженеру после клонирования репозитория и установки pre-commit и линтера для включения проверок). Теперь при попытке закоммитить невалидный манифест в систему контроля версий мы будем получать ошибку и информацию о причинах. 

Если не пытаться идти по граблям, то у утилиты kubelinter уже есть готовая pre-commit конфигурация, позволяющая использовать данную утилиту при shift-left подходе.

Таким образом, мы можем применять различные способы валидации конфигураций Kubernetes и использовать их ещё до внесения в систему контроля версий. Однако серебряной пулей данный способ также не является – команда git commit —no-verify позволяет сделать commit без какой-либо валидации, и это не есть плохо, так как невозможно заставить человека делать всё правильно. 

Если провести краткое сравнение приведенных инструментов между собой, то образуется примерно такая картина:

Выводы

Все приведенные инструменты и способы призваны лишь снизить риск появления мисконфигураций в ваших кластерах и помочь администраторам и разработчикам разобраться в том, как делать всё правильно и убрать из головы тот самый страх, о котором было написано в начале нашего путешествия. Каждый из приведенных в статье инструментов имеет свои плюсы и минусы, работа над каждым из них активно ведется компаниями и сообществами, появляются новые. 

Не стоит списывать со счетов и проверенные временем инструменты, например, yamllint. Порой не совсем корректно написанный YAML может повлиять на работу линтера (передаю пламенный привет kube-score и ошибке [CRITICAL] networking.k8s.io/v1/Ingress: (/) No service match was found, эти два часа были незабываемы).

От себя дам краткую характеристику по всем инструментам:

• Kubeconform – удобное средство проверки синтаксиса.

• Polaris – удобное и бесплатное решение для реализации “самозащиты” кластера.

• Kubelinter, Kubescape и Kube-score — наиболее въедливые утилиты по поиску плохих практик.

• Datree — централизованное, пусть и не бесплатное средство для централизованной проверки как в CI, так и в самом Kubernetes.

Наиболее интересный вариант использования получился с использованием сразу нескольких утилит подряд, например yamllint + Kubeconform + Kube-score. Таким образом покрывается большая площадь возможных проблем, а манифесты становятся «чистыми и мягкими». 

Буду рад комментариям о вашем опыте использования валидаторов для Kubernetes и решения проблем с некорректными конфигурациями. Всё же вся наша жизнь – это школа и перестать учиться значит потерять себя. 

Спасибо за внимание!

Полезные материалы о полном цикле разработки и методологии DevOps мы также публикуем в наших соцсетях – ВКонтакте и Telegram.