Лучшие практики управления секретами и конфиденциальными данными в кластерах Kubernetes

Секреты Kubernetes удобны, но они не являются автоматически безопасными только потому, что объект называется Secret. Если ваш RBAC слишком широк или etcd не зашифрован, утекший токен может раскрыть пароли баз данных, ключи API и частные сертификаты по всему кластеру.

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

Понимание секретов Kubernetes: механизм по умолчанию

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

Поведение по умолчанию и оговорки

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

Предупреждение: Никогда не полагайтесь только на объект Secret Kubernetes по умолчанию для высокочувствительных данных без применения мер шифрования.

Кодирование Base64 против шифрования

Распространенное заблуждение, что кодирование Base64 обеспечивает безопасность. Base64 — это схема кодирования, а не шифрования. Она легко обратима:

# Пример декодирования значения секрета Kubernetes
echo 'c3VwZXItc2VjcmV0Cg==' | base64 -d
# Вывод: super-secret

Слой 1: Обеспечение безопасности секретов в покое (шифрование etcd)

Самый фундаментальный шаг в защите секретов — гарантировать их шифрование на уровне хранения (etcd). Это защищает данные, даже если база данных доступна напрямую.

Включение шифрования в покое

Шифрование в покое настраивается через API-сервер Kubernetes с использованием объекта EncryptionConfiguration. Эта конфигурация определяет, какие провайдеры должны использоваться для шифрования различных типов данных, хранящихся в etcd, включая secrets.

Ключевые компоненты конфигурации шифрования:

1. kind: EncryptionConfiguration: Объявляет тип ресурса.
2. resources: Указывает, какие ресурсы API должны быть зашифрованы.
3. providers: Определяет механизм шифрования. Распространенные провайдеры включают aescbc, aesgcm и провайдеры KMS (например, AWS KMS или GCP KMS).

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

Слой 2: Обеспечение безопасности секретов при передаче и использовании

Хотя шифрование etcd решает проблему «в покое», секреты все равно расшифровываются Kubelet при монтировании в Pod. Мы должны контролировать как и где эти секреты появляются.

Стратегия 1: Монтирование секретов как томов

Стандартный способ внедрения данных секретов в контейнер — монтирование их как тома (часто в результате получается файл в файловой системе контейнера).

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/config/db"
      readOnly: true
  volumes:
  - name: secret-volume
    secret:
      secretName: my-sensitive-secret

Соображения безопасности: Смонтированные тома секретов обычно поддерживаются tmpfs на узлах Linux, но значения все равно видны процессу контейнера и любому, у кого есть достаточный доступ к узлу или Pod. Используйте readOnly: true, избегайте вывода переменных окружения или файлов конфигурации в логи и ограничьте доступ к оболочке в production Pod.

Стратегия 2: Переменные окружения (не рекомендуется для высокой чувствительности)

Хотя это удобно, использование переменных окружения, полученных из секретов, обычно не рекомендуется для ценных секретов. Переменные окружения могут быть легко раскрыты через:

• Логи контейнера, создаваемые плохо настроенными приложениями.
• Чтение /proc/1/environ из контейнера или других привилегированных контейнеров.
• Инструменты инспекции контейнеров.

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

Слой 3: Расширенное управление с внешними хранилищами секретов

Наиболее безопасный шаблон предполагает хранение конфиденциальных данных полностью вне плоскости управления Kubernetes (etcd) и их динамическое получение во время выполнения с помощью специализированных инструментов.

Использование операторов внешних секретов

Операторы внешних секретов устраняют разрыв между секретом, безопасно хранящимся в выделенном хранилище (например, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), и нативным объектом Secret Kubernetes.

1. Хранилище: Фактический секрет живет только во внешнем хранилище.
2. Синхронизация/Внедрение: Оператор отслеживает пользовательский ресурс (например, ExternalSecret) и извлекает данные из хранилища.
3. Создание: Затем оператор создает стандартный объект Secret Kubernetes локально, который может быть смонтирован в Pod.

Преимущество: Источник истины остается вне кластера, что улучшает ротацию и аудит. Однако синхронизированный секрет Kubernetes все еще существует в кластере, поэтому вам все равно нужны RBAC, шифрование etcd и изоляция пространств имен.

Использование драйвера CSI для хранилища секретов

Для приложений, которым нужен прямой, эфемерный доступ без хранения секрета локально в etcd, драйвер CSI для хранилища секретов является лучшим выбором.

• Драйвер использует провайдера (например, провайдер Vault, провайдер Azure).
• Он монтирует секрет непосредственно из внешнего хранилища в файловую систему Pod как временный том, минуя необходимость когда-либо записывать данные секрета в etcd.

Это обеспечивает наивысший уровень безопасности, полностью исключая секрет из базы данных etcd.

Операционные лучшие практики управления секретами

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

1. Принцип наименьших привилегий (PoLP)

Убедитесь, что сервисный аккаунт, связанный с Pod, имеет разрешения только на чтение конкретного секрета, который ему нужен, и никаких других. Используйте управление доступом на основе ролей (RBAC) для строгого ограничения разрешений.

2. Частая ротация секретов

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

3. Аудит и мониторинг доступа

Настройте журнал аудита для отслеживания того, кто читает или изменяет объекты Secret. Инструменты, интегрированные с внешними хранилищами (например, агенты Vault или драйверы CSI), также должны регистрировать попытки доступа к внешнему хранилищу.

4. Никогда не фиксируйте секреты в Git

Это основополагающее правило. Никогда не храните сырые или даже закодированные в Base64 секреты в репозиториях Git, даже частных. Используйте такие инструменты, как git-secrets, или инструменты шаблонизации управления конфигурацией (например, Helm или Kustomize) в сочетании с внешними механизмами внедрения секретов для управления манифестами развертывания.

Пример использования Kustomize (внешняя ссылка):

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

Сравнение стратегий управления

Стратегия	Уровень безопасности	Воздействие на etcd?	Сложность	Лучше всего для
Стандартный секрет K8s (без шифрования etcd)	Очень низкий	Да (открытый текст)	Низкая	Только временное тестирование
Секрет K8s с шифрованием etcd	Средний	Да (зашифровано)	Средняя	Общие данные конфигурации
Оператор внешних секретов	Высокий	Да (секрет, управляемый оператором)	Высокая	Стандартизация управления секретами
Драйвер CSI для хранилища секретов	Наивысший	Нет (прямое монтирование)	Высокая	Высокочувствительные учетные данные и токены

Начните с включения шифрования etcd и ужесточения RBAC. Затем решите, может ли каждая рабочая нагрузка использовать синхронизированные секреты, прямые монтирования CSI или динамические учетные данные из внешнего хранилища. Лучшая настройка — та, которая ограничивает, кто может читать секрет, где он хранится и как долго он остается полезным после раскрытия.