Практический разбор · Kubernetes
Kubernetes RBAC: найдите избыточные права пользователей и сервисов
Проверьте RBAC не только по ролям, но и по привязкам, namespace и service accounts. Права чтения Secrets, запуска Pod и выдачи ролей могут открыть путь к повышению привилегий; начните с минимальных разрешений.
Кому нужно проверить
Администраторам Kubernetes и владельцам платформенных команд. Важна не только марка продукта, но и конкретная версия, способ установки, операционная система и конфигурация.
В чём риск
RBAC складывает полномочия через привязки к пользователю, группе или service account. Широкая ClusterRoleBinding может предоставить доступ во всех namespaces. Роль edit позволяет читать Secrets и запускать Pod от имени service account в namespace, а bind, escalate и impersonate требуют особой осторожности.
Затронутые версии
Практическое руководство для Kubernetes-кластеров с RBAC authorization. Фактический доступ определяется API server, Role/ClusterRole, RoleBinding/ClusterRoleBinding, группами, service accounts и дополнительными механизмами авторизации.
Исправленные версии
Универсального исправленного выпуска нет. Удалите ненужные широкие привязки, ограничьте роли namespace и ресурсами, избегайте wildcard-разрешений и особо проверяйте secrets, pods/exec, bind, escalate, impersonate и создание привилегированных workloads.
Что сделать
- 1Составьте карту users, groups, service accounts, RoleBindings и ClusterRoleBindings. Сначала сохраните описания RBAC и согласуйте владельцев; не публикуйте токены.
- 2Найдите роли с wildcard-ресурсами или verbs и широкие привязки на уровне кластера. Отдельно проверьте secrets, pods/exec, workloads, serviceaccounts/token, bind, escalate и impersonate.
- 3Замените широкие разрешения минимальными Role и RoleBinding в нужных namespaces. Для автоматизации создайте отдельную service account и не используйте cluster-admin для обычных приложений.
- 4Проверьте права субъектов через kubectl auth can-i для конкретного verb, ресурса и namespace. Учитывайте группы, impersonation и косвенные пути через workloads.
- 5Сначала примените изменения в тестовой среде. Убедитесь, что легитимные контроллеры работают, запрещённые операции отклоняются, а доступ администратора для восстановления сохранён.
- 6После выкладки проверьте bindings и аудит API server. Удаляйте старые привязки только после подтверждения зависимостей; при подозрении на злоупотребление сохраните журналы и замените credentials.
- 7Назначьте регулярный пересмотр RBAC после изменения команд, workloads и операторов.
Примеры конфигурации и проверки
kubectl auth can-i list secrets --namespace=productionЗапускайте с kubeconfig проверяемой учётной записи и замените namespace. Команда спрашивает authorization review, не читает Secret и не меняет кластер. Ответ относится только к указанной операции и namespace; отдельно проверьте другие verbs и ресурсы. Не публикуйте kubeconfig или полный вывод. Откат не нужен.
Как не подпустить ботов к сайту
BotProtection принимает запросы перед вашим сайтом и фильтрует автоматизированные обращения. Поэтому ботам сложнее добраться до уязвимого компонента и начать его проверять или атаковать, а вероятность успешной автоматизированной атаки становится значительно ниже. Это дополнительный слой защиты: обновление уязвимых компонентов, проверка журналов и реагирование на инциденты остаются обязательными.
Первоисточники
Снизьте шанс атаки до того, как бот дойдёт до сайта
Подключите BotProtection как фильтр перед сайтом: подозрительные автоматизированные запросы отсекаются до обращения к вашему серверу. Это значительно снижает вероятность автоматизированной атаки, но не исправляет саму уязвимость, поэтому обновление и настройка компонентов остаются обязательными.