Практический разбор · Kubernetes
Kubernetes Secrets: ограничьте доступ к паролям и ключам
Проверьте, какие пользователи и приложения могут читать Kubernetes Secrets, и кто вправе создавать Pod в namespace. Секреты Kubernetes по умолчанию не следует считать зашифрованными в etcd только потому, что значение показано в Base64.
Кому нужно проверить
Администраторам Kubernetes, владельцам приложений и командам, которые управляют доступом разработчиков и сервисных учётных записей. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
Пользователь с правом читать Secret может получить содержащиеся в нём пароли и токены. Даже без прямого права читать Secret возможность создавать Pod или менять workload в некоторых конфигурациях может дать путь к использованию доступных Pod секретов. Base64 — это кодирование, а не шифрование. Доступ к резервной копии etcd также может раскрыть данные, если копия не защищена отдельно.
Затронутые версии
Руководство относится к Kubernetes-кластерам, в которых конфиденциальные значения хранятся в объектах Secret. Точное состояние шифрования в хранилище зависит от конфигурации API server и управляемого поставщика кластера; права определяются RBAC, admission-политиками, namespace и полномочиями создавать или изменять workloads.
Исправленные версии
Универсальной исправленной версии нет. Ограничьте чтение Secrets конкретными ролями и namespace, включите и проверьте encryption at rest для данных API в соответствии с версией и документацией поставщика, защитите резервные копии etcd и не храните манифесты с секретами в общедоступном коде.
Что сделать
- 1Составьте перечень namespaces, Secrets, потребителей и ответственных команд. Не выводите значения Secrets в терминал или отчёт; сохраните конфигурацию RBAC и проверьте резервное восстановление кластера перед изменениями.
- 2Проверьте, кому разрешены get, list и watch для ресурсов secrets, отдельно в каждом namespace и на уровне всего кластера. Учитывайте права создавать Pods, Deployments и другие workloads, а также доступ к exec и изменению service accounts.
- 3Сократите роли до нужных операций и namespace. Разделите права чтения секретов и управления workload; тщательно проверяйте сторонние интеграции, которым требуется доступ ко всем Secrets.
- 4Проверьте состояние шифрования данных API в etcd и настройте encryption at rest по документации вашей версии Kubernetes и облачного поставщика. Защитите резервные копии etcd шифрованием и контролем доступа.
- 5Не храните манифесты с реальными секретами в репозитории или общей папке. Base64 не скрывает содержимое; используйте утверждённый процесс управления секретами и ограничивайте, каким контейнерам конкретный Secret монтируется.
- 6Изменения ролей и политик сначала протестируйте на staging либо отдельной тестовой учётной записи. Проверьте, что нужные приложения продолжают работать, а запрещённое чтение не разрешено; сохраните предыдущие манифесты для отката. Если секрет мог раскрыться, замените его и оцените доступ по журналам.
Где защищать Kubernetes Secret
Статичная схема показывает точки контроля от хранилища до приложения.
- 1Ограничьте, кто может читать Secret через API
- 2Проверьте права создавать Pod и назначать service account
- 3Ограничьте, каким контейнерам монтируется значение
- 4Шифруйте данные API и резервные копии etcd
- 5Ротируйте секрет после подтверждённого или возможного раскрытия
Примеры конфигурации и проверки
kubectl auth can-i get secrets --all-namespacesЗапускайте с той же конфигурацией kubectl, которой пользуется проверяемая учётная запись. Команда не читает значения Secret и не меняет кластер; она проверяет только право get для всех namespaces. Ответ yes означает наличие такого разрешения, но не показывает его источник и не проверяет list, watch, создание Pod, права контроллеров или доступ через облачную панель. Не публикуйте конфигурацию kubectl и контекст кластера. Откат не требуется.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.