Секреты в Kubernetes

Base64 — это кодирование, а не шифрование

Это самое дорогое заблуждение в безопасности Kubernetes, поэтому скажу прямо: base64 — это обратимое перекодирование без ключа. Кто угодно и где угодно может выполнить base64 -d и получить исходные байты обратно. В декодировании не участвует никакого секретного материала — в этом весь смысл base64: он существует, чтобы двоичные данные пережили текстовый канал, а не чтобы их защитить. Называть секрет «зашифрованным» из-за того, что в YAML показано aHVudGVyMg== вместо hunter2, — всё равно что называть окно «запертым», потому что вы заклеили его бумагой.

Что Secret в Kubernetes реально даёт по сравнению с ConfigMap — это операционные, а не криптографические свойства: он помечен так, что по умолчанию не печатается в открытых логах; его можно смонтировать как tmpfs-том (в памяти), а не писать на диск; доступ к нему управляется через RBAC как к отдельному типу ресурса. Это реальные, полезные свойства. Ни одно из них не является конфиденциальностью на диске. Байты лежат в etcd, и по умолчанию они лежат там открытым текстом.

Кто на самом деле может прочитать ваш секрет

Зрелый вопрос — никогда «это base64?», а «какова поверхность чтения?». Секрет открыт удивительно широкому радиусу поражения, и каждый путь — это реальная атака, которую мы видели в постмортемах:

Два пути удивляют людей сильнее всего: etcd на диске и RBAC list secrets. По умолчанию kube-apiserver пишет объекты Secret в etcd без шифрования — поэтому бэкап etcd в S3-бакете или украденный снимок тома — это полный дамп учётных данных. А глагол list для секретов в RBAC катастрофичен именно потому, что возвращает содержимое, а не только имена: единственная слишком широкая Role с list по секретам в неймспейсе отдаёт каждую учётку этого неймспейса тому, кто ею владеет. Это верхняя позиция в OWASP Kubernetes Top 10 не просто так.

Шифрование на диске: включаем замок

Фикс для пути через etcd — это шифрование на диске (encryption at rest), настраиваемое на API-сервере через EncryptionConfiguration. Урок здесь в том, какого провайдера вы выбираете, потому что очевидный вариант — это ловушка.

Ловушка — это провайдеры aescbc/aesgcm с ключом в файле конфигурации: да, они шифруют etcd, но ключ шифрования лежит на узле control-plane открытым текстом, поэтому атакующий, способный прочитать данные etcd, обычно может прочитать и файл ключа. Это шаг вбок, а не фикс. Сильный выбор — KMS-провайдер, выполняющий envelope-шифрование: каждый секрет шифруется ключом данных (DEK), DEK шифруется ключом шифрования ключей (KEK), который живёт только внутри внешнего KMS (AWS KMS, GCP KMS, Vault), и API-сервер обязан сделать сетевой вызов к KMS для разворачивания. Теперь украденный снимок etcd — это инертный шифртекст. Учтите одну ловушку: включение шифрования шифрует только секреты, записанные после включения, — вы должны переписать каждый существующий секрет (kubectl get secrets -A -o json | kubectl replace -f -), чтобы реально запечатать то, что уже лежит.

Расползание секретов: настоящий операционный сбой

Даже при включённом шифровании на диске и плотном RBAC сбой, который реально кусает команды, — это расползание (sprawl): один и тот же секрет скопирован в десять неймспейсов, вшит в три Docker-образа, вставлен в два хранилища переменных CI и закоммичен один раз в Git «просто чтобы разблокировать деплой». Расползание — вот что превращает одну ротацию в недельные археологические раскопки, а одну утечку — в инцидент масштаба всего парка, потому что вы больше не можете ответить «где живёт эта учётка?».

Зрелый паттерн — единый источник истины вне кластера плюс синхронизация внутрь, а не копирование внутрь. Канонический секрет вы держите в выделенном хранилище (Vault, AWS Secrets Manager, GCP Secret Manager), а контроллер — External Secrets Operator (ESO) или Secrets Store CSI Driver — подтягивает его в кластер как нативный Secret по требованию. Манифесты ссылаются на ExternalSecret, указывающий на хранилище; сама учётка никогда не лежит в Git, никогда в образе, а ротация происходит в одном месте и распространяется. Секрет в кластере становится кэшем, а не базой-источником записи.