В этой статье рассмотрим, как можно организовать простое управление секретами для приложений в Kubernetes при использовании GitOps-подхода. Храним секреты в git безопасно и управляем ими из Helm Chart приложения.
Рассмотрим приложение, которое развертывается в кластере Kubernetes с использованием Helm Chart и GitOps. Согласно принципам GitOps все данные, необходимые для развертывания приложения, должны храниться в git-репозитории. Артефакты: docker-образы, Helm-чарты и т.п., могут храниться в отдельных реестрах или репозиториях, но должны быть однозначно идентифицированы, например, с помощью версионирования. Таким образом, git-репозиторий является единым источником истины для развертывания приложения. Однако складывать секреты в git в открытом виде, или, как предлагают стандартные средства Kubernetes и Helm, просто в base64, совершенно не безопасно.
Конечно, для хранения секретов можно воспользоваться специальными инструментами, вроде HashiCorp Vault, когда это оправдано масштабом проекта. В этой статье я хочу остановиться на простом решении, почти не требующем дополнительных внешних зависимостей и дополнительных усилий при эксплуатации. Оно вполне применимо для небольших систем и простых политик безопасности.
Для решения задачи будем использовать следующие инструменты:
Универсальный Helm Chart от Nixys
Flux CD в качестве GitOps инструментария
Sealed Secrets для шифрования секретов
Аналогичную конструкцию можно реализовать для любого Helm Chart и другой GitOps-системы, например, ArgoCD.
Sealed Secrets представляет собой решение от Bitnami, специально предназначенное для организации хранения секретов в git-репозитории и работы в связке с GitOps-системами. Секрет предварительно зашифровывается и может быть сохранен в git в виде объекта типа SealedSecret. Контроллер Sealed Secrets расшифровывает секреты и предоставляет их приложениям обычным способом. Он довольно легковесный, не требует настройки и практически не потребляет ресурсы кластера. Шифрование секретов производится с помощью консольной команды kubeseal. При стандартной способе использования она создает готовый манифест для объекта SealedSecret.
Но тут кроется одно неудобство. Если размещать секрет в виде отдельного манифеста, он становится недоступен для управления из Helm Chart приложения. Например, затруднительно отслеживать его изменения для рестарта приложения, а также гарантировать наличие секрета до запуска пода. Одним из решений может быть включение зашифрованного секрета непосредственно в Helm Chart приложения.
Реализация
Для удобства использования нашего решения добавим в универсальный Helm Chart темплейт и хелпер для Sealed Secrets.
{{- range $sName, $val := .Values.sealedSecrets -}}
---
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
name: {{ include "helpers.app.fullname" (dict "name" $sName "context" $) }}
namespace: {{ $.Release.Namespace | quote }}
labels:
{{- include "helpers.app.labels" $ | nindent 4 }}
{{- with $val.labels }}{{- include "helpers.tplvalues.render" (dict "value" . "context" $) | nindent 4 }}{{ end }}
annotations:
{{- include "helpers.app.hooksAnnotations" $ | nindent 4 }}
{{- with $val.annotations }}{{- include "helpers.tplvalues.render" (dict "value" . "context" $) | nindent 4 }}{{ end }}
spec:
encryptedData:
{{- include "helpers.sealedSecrets.render" (dict "value" $val.encryptedData) | indent 4 }}
template:
metadata:
name: {{ include "helpers.app.fullname" (dict "name" $sName "context" $) }}
namespace: {{ $.Release.Namespace | quote }}
labels:
{{- include "helpers.app.labels" $ | nindent 8 }}
{{- with $val.labels }}{{- include "helpers.tplvalues.render" (dict "value" . "context" $) | nindent 8 }}{{ end }}
annotations:
{{- with $val.annotations }}{{- include "helpers.tplvalues.render" (dict "value" . "context" $) | nindent 8 }}{{ end }}
{{- end }}{{- define "helpers.sealedSecrets.render" -}}
{{- $v := dict -}}
{{- if kindIs "string" .value -}}
{{- $v = fromYaml .value }}
{{- else -}}
{{- $v = .value }}
{{- end -}}
{{- range $key, $value := $v }}
{{ printf "%s: %s" $key $value }}
{{- end -}}
{{- end -}}Наш темплейт будет создавать секреты из раздела .Values.sealedSecrets, добавлять к ним лейблы и аннотации, определенные, как для приложения, так и для самого ресурса. Зашифрованные данные помещаются в encryptedData в виде стандартного словаря.
Стоит обратить внимание на то, что здесь используются хуки, с помощью которых Helm создает объект SealedSecret до создания и запуска подов приложения. Этот подход используется в Helm Chart от Nixys для объектов типа ConfigMap и Secret. Он гарантирует, что приложение при запуске получит правильную версию конфигурации, однако при этом ресурс не будет автоматически удален, когда перестанет использоваться. Аналогичным образом можно определить темплейт и без хуков, если такое поведение неудобно.
Если нужно, чтобы приложение рестартовало автоматически при изменении секрета, к его подам можно добавить аннотацию с контрольной суммой всех секретов.
checksum/secrets: '{{ include "helpers.workload.checksum" (printf "%s" $.Values.sealedScrets) }}'Теперь мы можем зашифровать секрет, например так:
kubeseal --raw --scope=namespace-wide --namespace=yournamespace --from-file=yoursecret.txtТаким образом мы получаем строку содержащую контент файла yoursecret.txt в зашифрованном виде. Мы указали тут скоуп namespace-wide для того, чтобы не привязываться к имени ресурса, которое может генерировать Helm при рендеринге чарта.
Полученную строку мы добавим в Values следующим образом:
sealedSecrets:
yoursecretname:
annotations:
sealedsecrets.bitnami.com/namespace-wide: "true"
encryptedData:
FOO: "encrypted-secret-string"Стоит обратить внимание, что здесь мы дополнительно добавляем аннотацию sealedsecrets.bitnami.com/namespace-wide: "true", чтобы скоуп ресурса соответствовал нашим зашифрованным данным.
Проверка
Опишем наше приложение через values универсального чарта. Для примера возьмем тестовый микросервис podinfo, который не требует какой-либо конфигурации, но позволит нам протестировать правильную передачу секрета.
Для начала зашифруем наш секрет. Для удобства передадим его прямо из командной строки:
echo -n 'very-secret-string' | \
kubeseal --raw --scope=namespace-wide --namespace=podinfo --from-file=/dev/stdinДля деплоя приложения через Flux CD создадим описание объекта HelmRelease, содержащее минимально необходимые параметры values для деплоя podinfo с помощью универсального чарта. Мы определим deployment, service, ingress и SealedSecret. Полученную ранее зашифрованную строку вставим в sealedSecrets.app-secret.encryptedData.
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: podinfo
namespace: podinfo
spec:
interval: 10m
chart:
spec:
chart: universal-chart
version: '>=2.8.0'
sourceRef:
kind: HelmRepository
name: your-helm-repository
namespace: your-repository-namespace
interval: 10m
values:
deployments:
app:
containers:
- name: podinfo
image: stefanprodan/podinfo
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 9898
envSecrets:
- app-secret
services:
app:
type: ClusterIP
ports:
- name: http
protocol: TCP
port: 9898
ingresses:
app:
hosts:
- hostname: podinfo.example.com
paths:
- serviceName: app
servicePort: 9898
path: "/"
sealedSecrets:
app-secret:
annotations:
sealedsecrets.bitnami.com/namespace-wide: "true"
encryptedData:
SECRET_VARIABLE: <your-encrypted-string>После деплоя проверим, правильно ли передался секрет в приложение. Для podinfo достаточно выполнить команду:
curl -X 'GET' 'https://podinfo.example.com/env'В ответ мы должны получить массив переменных, содержащий и наш секрет:
[
...
"SECRET_VARIABLE=very-secret-string",
...
]Аналогично можно добавить темплейт для SealedSecret в любой другой "библиотечный" Chart, например генерируемый helm create. При этом отличаться будут только используемые внутри хелперы и структура values-файла.