Kubernetes хранит Secrets без шифрования — Base64 ситуацию не исправляет

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

Base64 кодирует значение для представления в объекте, но не скрывает пароль от того, кто прочитал запись. После защиты хранилища отдельно ограничьте права пользователей и служебных учётных записей, а также удалите действующие секретные значения из репозиториев. Эти меры закрывают разные пути получения одного и того же значения.

Проверьте, как хранятся секреты

Начните с настройки каждого сервера интерфейса управления. Параметр запуска --encryption-provider-config должен указывать на файл с правилом для секретов; в списке механизмов первым должен стоять шифрующий. Если параметра нет либо первым указан identity, новые объекты сохраняются без шифрования. Сравните файлы на всех узлах: различие ключей и порядка механизмов может сделать часть записей нечитаемой.

Файл показывает только режим последующих записей. Для проверки фактического состояния создайте временный секрет с заведомо несекретным значением и прочитайте соответствующую запись непосредственно из хранилища при помощи etcdctl. У зашифрованной записи есть служебный префикс и непрозрачное содержимое; выполните такую же проверку для давно существующего объекта, не выводя его действующее значение в журнал терминала.

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

Включите шифрование для новых записей

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

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

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

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

Перезапишите старые объекты и проверьте хранилище

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

С учётной записью, которой разрешены чтение и изменение секретов во всех пространствах имён, получите все такие объекты и передайте их без изменения значений команде kubectl replace. Сервер сохранит каждый объект заново, применив первый механизм текущей конфигурации. На большом кластере проходите пространства имён по очереди и учитывайте нагрузку на сервер.

Если объект параллельно изменился и возник конфликт, разберите ошибку и повторите запись затронутого объекта. Затем выборочно проверьте в хранилище секреты из разных пространств имён, особенно существовавшие до перехода. Удаляйте механизм чтения открытых записей только после подтверждения миграции всех объектов: оставшийся незашифрованным секрет иначе станет недоступен серверу. Снимки хранилища, созданные раньше, повторная запись не изменяет; их доступ и срок хранения контролируются отдельно.

Сократите права на чтение

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

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

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

Удалите секретные значения из репозиториев

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

Уберите значения из текущих файлов и подавайте их при развёртывании через механизм с контролем доступа. Если секрет уже был опубликован, замените пароль, отзовите токен или перевыпустите ключ в выдавшей его системе, а затем обновите объект в кластере. Очистка истории репозитория может сократить дальнейшее распространение, но не отменяет копии, уже полученные другими участниками.

Читайте также:

• NIST пересматривает XTS-AES — шифрование диска остаётся без проверки целостности
• AWS поручает ИИ писать сценарии исправления — проверка всё равно обязательна
• Директ в Instagram лишился сквозного шифрования: как пользоваться сообщениями