Практический разбор · Kubernetes
Kubernetes service account: ограничьте права и срок действия токена
Токен service account даёт Pod возможность обращаться к Kubernetes API от имени этой учётной записи. Проверьте права, автоматическое монтирование, аудиторию и срок действия токена; не копируйте bearer-токены в логи.
Кому нужно проверить
Администраторам кластера и разработчикам workload, которым требуется доступ к Kubernetes API. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
Pod может получить смонтированный токен service account и использовать его полномочия через API. Если токен долгоживущий или роль имеет избыточные права, компрометация контейнера может расширить доступ. Короткий срок и audience уменьшают область использования, но не заменяют RBAC.
Затронутые версии
Руководство относится к Kubernetes workloads, использующим service accounts и токены API. Доступность projected short-lived tokens, автоматического монтирования и выдачи токенов зависит от версии кластера и конфигурации поставщика.
Исправленные версии
Универсальной исправленной версии нет. Используйте отдельную service account с минимальными RBAC-правами, отключайте автоматическое монтирование там, где API не нужен, и предпочитайте короткоживущие привязанные токены штатного механизма Kubernetes.
Что сделать
- 1Определите, каким Pod действительно нужен Kubernetes API. Инвентаризируйте service accounts и bindings, не извлекая и не печатая токены.
- 2Проверьте RBAC каждой service account на чтение Secrets, изменение workloads и кластерные разрешения. Удалите ненужные bindings.
- 3Для workload без API задайте automountServiceAccountToken: false на Pod или service account и проверьте, что приложение не зависит от токена. Не применяйте настройку вслепую к системным компонентам.
- 4Для необходимого API используйте projected short-lived tokens с подходящей audience. Не создавайте постоянные Secret с вручную скопированными bearer-токенами без обоснованной необходимости.
- 5Проверьте манифесты, Helm charts и шаблоны контроллеров, чтобы конфигурация переживала пересоздание Pod.
- 6Разверните изменение на тестовой workload и проверьте ожидаемый отказ для Pod без доступа и успешные нужные операции для ограниченной service account. Не выводите токен в CI-лог.
- 7После применения проверьте новые Pod и bindings. Если токен мог раскрыться, замените credentials, изучите аудит API и оцените затронутые данные.
Примеры конфигурации и проверки
kubectl get pods -n production -o custom-columns='NAME:.metadata.name,SERVICEACCOUNT:.spec.serviceAccountName,AUTOMOUNT:.spec.automountServiceAccountToken'Запускайте с read-only правами просмотра Pod и замените production. Выводит имя Pod, service account и локальное значение automount, но не показывает токены и не меняет кластер. Пустое значение automount требует проверки настроек service account и поведения версии. Не публикуйте вывод без необходимости. Откат не нужен.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.