Почему base64-кодирование в Kubernetes Secret не является шифрованием, и какие есть практические способы защитить секреты в кластере?

Короткий ответ

Base64 — это обратимая кодировка без ключа, а не шифрование; реальная защита Secret в Kubernetes складывается из нескольких независимых слоёв: шифрования etcd at rest (encryption provider), строгого RBAC на чтение Secret, и, при более высоких требованиях, внешних систем управления секретами (Vault, облачный Secret Manager) с синхронизацией в кластер.

Как это работает подробнее

по умолчанию Kubernetes хранит Secret в etcd в виде base64 без какого-либо шифрования на диске — доступ к файлам etcd или снапшоту бэкапа даёт прямой доступ к значениям секретов. Encryption at rest (настраивается через EncryptionConfiguration на API сервере) шифрует значения Secret перед записью в etcd, но не защищает от легитимного доступа через Kubernetes API — для этого нужен именно RBAC.

Пример кода

Команды и выводКопировать

kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d

Что использовать на практике

• Практика. минимальный защищённый контур включает: включённое шифрование etcd at rest, RBAC-правила, ограничивающие get/list на Secret только необходимым сервисным аккаунтам и людям, и отключение automountServiceAccountToken там, где он не нужен. Для организаций с повышенными требованиями к аудиту и ротации секретов используют внешние хранилища (HashiCorp Vault, AWS/GCP Secret Manager) с оператором (External Secrets Operator) или CSI-драйвером Secrets Store, который подтягивает секреты напрямую в под, минуя постоянное хранение в etcd.

Подводные камни

• Риски. считать base64 достаточной защитой и хранить Secret-манифесты с реальными значениями в Git без дополнительного шифрования (например, sealed-secrets, SOPS); включать шифрование etcd at rest, но забывать ограничить RBAC — зашифрованные на диске данные всё равно доступны через API любому, у кого есть права на чтение Secret.