Управление секретами в Kubernetes

Секреты Kubernetes позволяют безопасно хранить конфиденциальную информацию. Использование секрета устраняет необходимость запекать конфиденциальные данные в определения манифеста или простые образы контейнеров.

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

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

Создание секрета

Секреты создаются так же, как и любой другой ресурс API Kubernetes. Вы можете использовать команды Kubectl или манифест YAML, который затем примените к своему кластеру. В этом руководстве мы предоставим примеры файлов YAML.

Вот как определить секрет, созданный пользователем:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: demo-secret
data:
  SECRET_USERNAME: dXNlcm5hbWUK
  SECRET_PASSWORD: cGFzc3dvcmQK

Секреты состоят из типа и простого объекта данных. Пример секрета определяет два отдельных поля данных: SECRET_USERNAME и SECRET_PASSWORD. Значения должны быть закодированы в формате Base64 — показанные выше значения изначально были username и password.

Если вы работаете с шаблоном Helm, вы можете определить свои секретные значения в файле values.yaml. Передайте их через b64enc в манифесте, чтобы Helm закодировал их как Base64.

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: demo-secret
data:
  SECRET_PASSWORD: {{ .Values.SecretPassword | b64enc }}

Если вы не хотите кодировать свои значения с помощью Base64, вместо этого вы можете использовать поле stringData. Как и data, stringData представляет собой карту пар ключ-значение, но значения будут обрабатываться дословно, без какой-либо кодировки.

Секретные типы

Секретный тип Opaque следует использовать для произвольных данных, которые вы определяете сами. Kubernetes определяет несколько других встроенных типов секретов, предназначенных для определенных сценариев использования.

Доступные типы включают service-account-token (служебный токен Kubernetes), dockerconfigjson (сериализованный файл Docker config.json для предоставления учетных данных Docker ) и ssh-auth (укажите учетные данные SSH). В дополнение к этим типам существуют решения для базовой аутентификации HTTP и данных сертификата TLS.

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

Вы можете создать свои собственные идентификаторы секретного типа, указав свою собственную строку в поле type. Полученный секрет будет функционально эквивалентен типу Opaque.

Предоставление секретов модулям

После того, как вы создали секрет, вам нужно сделать его доступным для ваших модулей. Вы можете вводить секретные данные как переменные среды или как файл, смонтированный на томе.

Вот манифест пода, который извлекает данные секрета в переменные среды:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-secret
spec:
  containers:
    - name: demo-container
      image: my-image:latest
      envFrom:
        - secretRef:
            name: demo-secret

С помощью envFrom все пары ключ-значение, определенные в data секрета, будут преобразованы в переменные среды контейнера. В приведенном ранее примере secret в ваш контейнер будут внедрены переменные среды SECRET_USERNAME и SECRET_PASSWORD. Значения будут автоматически декодированы в формате Base64.

Иногда вам может понадобиться работать с файлами, а не с переменными среды. Вот как смонтировать секрет в том Kubernetes.

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-secret
spec:
  containers:
    - name: demo-container
      image: my-image:latest
      volumeMounts:
        - name: secret-volume
          mountPath: /secrets
  volumes:
    - name: secret-volume
      secret:
        secretName: demo-secret

Откройте каталог /secrets внутри контейнера, чтобы просмотреть секретные данные. Каждый ключ данных будет иметь свой собственный файл. Содержимое файла будет декодированным в Base64 значением этого ключа. В нашем примере секрет будет записан в файлы /secrets/SECRET_USERNAME и /secrets/SECRET_PASSWORD.

Подход работает путем создания тома Kubernetes с использованием источника secret. Этот источник заполняет том данными из именованного секрета. Затем том монтируется в контейнер по пути, указанному в volumeMounts.

Вопросы безопасности

Помещение данных в секрет не делает их автоматически безопасными. Кодировка Base64 обеспечивает поверхностную неясность, но не заблуждайтесь: это кодирование, а не шифрование. Любой, кто имеет доступ к вашему кластеру, будь то пользователь-человек или приложение с соответствующими правами доступа, может получить секретные значения в виде обычного текста.

Смысл секретов в том, чтобы снизить риск случайного раскрытия данных при создании и просмотре подов. Секреты предоставляются только модулям и узлам, которым они действительно нужны. Node уничтожит свои локальные копии секретов, когда Pod, который их использовал, прекратит работу.

Плоскость управления Kubernetes хранит секретные значения в своем экземпляре etcd. Это хранилище ключей и значений, которое поддерживает данные кластера Kubernetes. Если вы хотите добиться максимальной безопасности, вам следует настроить шифрование в состоянии покоя для вашего хранилища etcd. Это зашифрует ваши секреты в etcd.

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

Краткое содержание

Секреты Kubernetes позволяют хранить конфиденциальные данные и получать к ним доступ в кластере Kubernetes. Использование секретов дает вам больший контроль над раскрытием информации. Это также дает понять, что вы имеете дело с потенциально конфиденциальными значениями. Это может служить предупреждением для пользователей и администраторов кластера.

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