Kubernetes RBAC

Роль описывает разрешённые действия: например, читать Pods или менять Deployments. Привязка определяет, кто получит эти разрешения. Один аккаунт может иметь несколько привязок, поэтому фактические права нужно проверять в совокупности.

RBAC отвечает на вопрос «можно ли выполнить этот запрос к API?». Он не фильтрует сетевые соединения контейнеров и не проверяет автоматически безопасность запускаемого образа.

Role действует в пространстве имён. ClusterRole может описывать права на ресурсы всего кластера и использоваться повторно. RoleBinding выдаёт права в одном namespace, в том числе из ClusterRole; ClusterRoleBinding выдаёт их на уровне кластера.

Командам выпуска и сервисным аккаунтам назначают только необходимые действия. Отдельно проверяют доступ к Secrets и возможность расширять права через bind или escalate. Правила RBAC складываются: добавление узкой роли не отменяет разрешений из других привязок.

Например, группе поддержки нужно просматривать состояние Pods только в namespace staging. Администратор создаёт Role с get, list и watch для pods и связывает её с этой группой через RoleBinding. Право читать Secrets или менять workloads в эту роль не включают.

Затем проверяют разрешённый запрос и запрещённые действия, например через kubectl auth can-i get pods -n staging. Для проверки от имени другого субъекта нужны права на impersonation; без них тест выполняют с учётными данными самого проверяемого пользователя.

• АутентификацияУстанавливает, какой субъект отправил запрос. RBAC оценивает разрешения уже определённого пользователя или сервисного аккаунта.
• NetworkPolicyОграничивает сетевой трафик Pods при поддержке выбранного сетевого плагина. RBAC управляет обращениями к API, а не соединениями приложений.
• Облачная IAMУправляет доступом к ресурсам и API облачного провайдера. Права внутри Kubernetes требуют отдельной проверки, даже если вход в кластер связан с облачной учётной записью.

1. Описать задачуВыбирают субъект, namespace, ресурсы API и необходимые действия. Чтение Pods и чтение Secrets рассматривают отдельно.
2. Создать рольЗаписывают точные ресурсы и verbs. Не используют wildcard и cluster-admin там, где хватает узкого набора разрешений.
3. Привязать субъектВыбирают RoleBinding или ClusterRoleBinding с нужной областью действия. Проверяют уже существующие привязки этого субъекта.
4. Проверить праваТестируют нужные и лишние действия через kubectl auth can-i и реальные запросы. Повторяют проверку после изменения ролей.

• Курсы DevSecOps: безопасность инфраструктуры и выпускаКурсы

• Виртуальная частная облачная сеть (VPC)