Управление секретами при деплое в k8s

В определенный момент мы приходим к понимаю, что процесс, который работает «хорошо», должен начать работать «правильно», особенно, если речь зашла про секреты приложений.

Дано: gitlab(onprem), облако (в моем случае Yandex Cloud), 10+ сервисов, которые нужно активно и часто деплоить (с возможностью быстрого наращивания кол-ва сервисов)

Требования к решению: деплои должны происходить без участия вмешательства инженера непосредственно в процессе деплоя, процесс прозрачен для разработчика и отвечает принятым в компании требованиям к качеству и безопасности.

Решение: Оговорюсь сразу — мое решение построено на Yandex Cloud, но справедливо для любого облачного или onprem решения.

Пропускаю путь от деплоя файлом локально через kubectl до Helm (можно в отдельную тему)

Итак есть репозитории с кодом, в них размещаем файлы .{environment}.values.yaml
При деплое указываем —values=/path/to/file

Возникает главный вопрос — если configmap хранить в репозитории (через helm переменные — это правильно), то как быть с секретами?

Вариант 1: использовать helm-secrets, sops и другие решения

Получаем в репозитории зашифрованные файлы с секретами. При деплое указываем путь к файлу, helm дефишрует и деплоит вместе с секретами приложение. Однако тут же прилетают накладные расходы в виде системы для передачи ключа с которым шифровали, обязательно не забыть в gitignore добавить *.dec, иначе в какой то момент секреты утекают в репозиторий и какой был смысл тогда? Ну и велик риск потерять ключ и секреты заодно. Главный минус подхода — при изменении секрета нужно заново пройти весь pipeline, а значит и проверки, и валидацию кода, и тесты — долго.

Вариант 2: использование управление секретами через внешние системы.

Дополнительно нам понадобится:

• Место для хранения секретов. Я использую Yandex Cloud Lockbox, можно использовать например Vault или похожие системы
• External secret operator, как инструмент для синхронизации секретов
• Kyverno, как инструмент для выполнения политик к кластере k8s

Выбор хранилища секретов ложиться на плечи системного инженера или архитектора. По опыту скажу — я использовал vault и lockbox. Первый, конечно более мощный, но для небольшого энтерпрайза хватит второго решения.

Далее разворачиваем в кластере External Secret Operator.

Создаем сервисный аккаунт с ролью lockbox.editor

export HELM_EXPERIMENTAL_OCI=1 && \ helm pull oci://cr.yandex/yc-marketplace/yandex-cloud/external-secrets/chart/external-secrets \   --version 0.5.5 \   --untar && \ helm install \   --namespace external-secret-operator \   --create-namespace \   --set-file auth.json=sa-key.json \   external-secrets ./external-secrets/ 

Для работы с секретами так же развернем secretstore. Стоит обратить внимание, что secretstore работает в режиме namespace и изолирует секреты в рамках одного ns, ClusterSecretStore позволяет делить секреты между разными ns. Это следует помнить и не шарить лишний раз секреты, которые не будут использоваться в двух и более ns.

Предварительно создайте секрет ( в примере yc-auth) c ключами от сервисного аккаунта созданного ранее. Затем установите secretstore в нужный namespace

apiVersion: external-secrets.io/v1alpha1 kind: SecretStore metadata:   name: secret-store spec:   provider:     yandexlockbox:       auth:         authorizedKeySecretRef:           name: yc-auth           key: authorized-key'

На данном этапе подготовительные работы выполнены.

В чарт приложения можно добавить шаблон для external-secret (или измените пример для использования, как обычный манифест)

 apiVersion: external-secrets.io/v1alpha1 kind: ExternalSecret metadata:   namespace: {{.Values.namespace }}   name: {{ include "helm-chart.name" . }} spec:   refreshInterval: {{ .Values.secretRefreshInterval }}   secretStoreRef:     name: secret-store     kind: SecretStore   target:     name: {{ include "helm-chart.name" . }}   data:   - secretKey: DATABASE_URL     remoteRef:       key: {{ .Values.secretRemote }}       property: DATABASE_URL

В данном примере создается external-secret ресурс, который называется по названию чарта, вызывает создание одноименного k8s секрета из внешнего секрета.

Обратим внимание на два параметра:

• secretRefreshInterval — интевал с которым secret-operator будет опрашивать lockbox на предмет изменения секрета (по умолчанию 1h0m0s)
• secretRemote — идентификатор секрета в lockbox (будет захвачена последняя актуальная версия секрета)

После применения манифеста убедитесь, что ресурс перешел в состояние synced

На этом моменте мы получили управляемые секреты в к8s, меняем в lockbox — через какое то время — меняется в кубернетес. Но этого мало, деплоймент не узнает о том, что вы поменяли секрет или добавили новую переменную в него.

Тут на сцену выходит инструмент Kyverno (если будет необходимость — о настройке я напишу отдельный материал). В данный момент предположим, что он у вас уже стоит.

 apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata:   name: deployment-restart-policy   namespace: test-ns   annotations:     policies.kyverno.io/title: Restart Deployment On Secret Change     policies.kyverno.io/category: Other     policies.kyverno.io/severity: medium     policies.kyverno.io/subject: Deployment     kyverno.io/kyverno-version: 1.9.0     policies.kyverno.io/minversion: 1.7.0     kyverno.io/kubernetes-version: "1.27" spec:   schemaValidation: false   rules:   - name: update-secret     match:       any:       - resources:           kinds:           - Secret           names:           - test-database-adapter           namespaces:           - sup     preconditions:       all:       - key: "{{request.operation || 'BACKGROUND'}}"         operator: Equals         value: UPDATE     mutate:       targets:         - apiVersion: apps/v1           kind: Deployment           name: test-database-adapter           namespace: test-ns       patchStrategicMerge:         spec:           template:             metadata:               annotations:                 ops.corp.com/triggerrestart: "{{request.object.metadata.resourceVersion}}" 

Данная политика не претендует на эталон, но она выполняет свою задачу — а именно выполнить restart деплоймента, если изменится контрольная сумма указанного секрета.

В итоге, какое решение мы получили.

При деплое приложения создается external secret, который занимается обновлением секрета k8s. Изменение последнего служит триггером для перезапуска приложения.