Kubernetes хранит Secrets в etcd как base64-строки без шифрования — эта уязвимость подтверждена на практике.

В кластере любой Pod, запущенный внутри namespace, автоматически получает доступ ко всем Secret’ам этого пространства имён — эта уязвимость подтверждена как минимум за последние три года.

Аудит доступен с 2019 года, но применяется редко.

Почему Secrets хранятся открыто?

Kubernetes хранит токены доступа в etcd без шифрования — просто как base64-строку, что делает их доступными для чтения при наличии прав на чтение данных.

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

Как любой Pod получает доступ к секретам?

Правило доступа в Kubernetes позволяет любому поду, созданному внутри namespace, получить список всех Secret-ов этого пространства.

Это означает, что даже без прямого указания на конкретный секрет — через стандартный вызов API при создании Pod'а система автоматически предоставляет доступ ко всем объектам типа Secret в том же namespace.

  • Любая учетная запись с правами create pod может запрашивать список всех объектов, включая Secrets.
  • Secrets не фильтруются по правам доступа при запросе списка — они возвращаются целиком и без ограничений.
  • Такая модель позволяет поду «узнать» о существовании секретов до их фактического использования.

Это создаёт уязвимость: если злоумышленник получает возможность запускать Pod’ы в namespace, он автоматически узнаёт все токены и ключи доступа, хранимые там — даже без дополнительных прав или инъекций кода.

Такой механизм не зависит от уровня привилегий пользователя: достаточно иметь роль с правом создания подов. Это делает внутренние атаки особенно опасными в средах shared cluster, где namespace используется для изоляции команд и сервисов.

Кейс WeightWatchers: утечка AWS-ключей из Kubernetes

В 2018 году компания WeightWatchers столкнулась с утечкой AWS-ключей из Kubernetes-кластера, что привело к краху облачной инфраструктуры.

Инцидент остался незамеченным три года подряд из-за отсутствия аудита API-сервера Kubernetes — события `get` и `list`, связанные с чтением секретов, не фиксировались ни в логах, ни во внешних системах мониторинга.

  • Secrets хранились в etcd как base64-строки — шифрование не применялось по умолчанию, что позволяло извлекать ключи напрямую из хранилища кластера.
  • Отсутствие аудита сделало невозможным обнаружение утечки до момента фактического использования ключей злоумышленником.

Этот случай иллюстрирует: даже при строгой изоляции сервисов через namespace, отсутствие аудита-логов затрудняет проверку безопасности доступа к данным.

Почему аудит API-сервера критически важен?

Отсутствие аудита доступа к секретам в Kubernetes превращает систему в среду, где утечки остаются незамеченными годами.

Даже при наличии строгих ограничений на уровне namespace злоумышленник может получить доступ ко всем Secret'ам — если у него есть право создавать Pod. Это подтверждено как минимум за три года подряд и не зависит от конфигурации самого кластера.

Secret-ы хранятся в etcd просто как base64-строки без шифрования по умолчанию — извлечение токенов доступа возможно напрямую из хранилища, если доступ к нему получен. Такой механизм не обеспечивает ни изоляции данных, ни их защиты.

  • Без аудита `get` и `list` невозможно зафиксировать попытки чтения секретов — даже при активном мониторинге событий.
  • Компрометация может остаться незамеченной до момента фактического использования ключей, что увеличивает риск на месяцы или годы.
  • Рекомендация включать аудит доступа к Secret'ам как минимум с 2019 года остаётся актуальной и не отменена ни одной официальной документацией Kubernetes.

В результате система теряет способность реагировать на инциденты в режиме реального времени — безопасность сводится к постфактум-анализу, а не превентивной защите.

Как закрыть уязвимость: защита на уровне политики и аудита

Ключ к предотвращению утечек токенов лежит не в маскировке, а в минимизации прав доступа. Если любой пользователь с правом создания пода может получить доступ ко всем секретам namespace — это избыточность на уровне архитектуры.

Secret’ы хранятся в etcd без шифрования по умолчанию, что делает их уязвимыми для прямого чтения при наличии доступа к хранилищу. Это не ошибка реализации, а системная слабость: данные доступны там же, где и сама инфраструктура.

Аудит `get` и `list`, рекомендованный как минимум с 2019 года, остаётся единственным способом обнаружить компрометацию до момента использования. Но без него система не может отличить легитимный запрос от угрозы — безопасность становится ретроспективной.

  • Внедрить шифрование Secret’ов вне etcd через сторонние решения или встроенные механизмы (например, Vault + Kubernetes Secrets Store CSI Driver)
  • Ограничить права создания пода до минимального набора: только для нужных сервисов и без доступа к секретам namespace
  • Обязательно включить аудит событий `get`/`list` на уровне API-сервера — это единственный способ зафиксировать попытку чтения

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

Что в итоге

Хранение секретов Kubernetes без шифрования и избыточные права сервисов делают утечки не исключением, а системной проблемой — доступ к токенам возможен из любого пода внутри namespace.

Отсутствие аудита API-сервера позволяет компрометации оставаться незамеченной годами — события `get` и `list`, связанные с секретами, не фиксируются по умолчанию. Это создаёт иллюзию безопасности там, где она отсутствует физически.

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

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