В контексте описанной выше интеграции критически важно правильно разграничить доступ к Kubernetes-кластеру. Аутсорсинговая команда не должна иметь полный доступ ко всем неймспейсам — это риск безопасности. Используем ClusterRoleBinding и RoleBinding в связке с ServiceAccount или внешними identity-провайдерами (OIDC).

Сценарий

• Есть аутсорсинговая DevOps-команда, которая управляет CI/CD, мониторингом и слаботочной инфраструктурой (IoT Hub).
• Им нужен доступ только к определённым неймспейсам (monitoring, iot-hub, ci-cd) с возможностью просмотра подов, логов, запуска отладки.
• Доступ к нодам, secrets (кроме их собственных) и критическим компонентам (kube-system) — запрещён.

Решение: ClusterRole + ClusterRoleBinding (для глобальных прав) и RoleBinding (для неймспейс-специфичных)

Создадим ClusterRole с минимальными правами для чтения ресурсов во всём кластере (например, просмотр нод, storage classes — это бывает нужно для понимания топологии, но без права изменять). А затем через RoleBinding дадим более широкие (например, CRUD подов) только в нужных неймспейсах.
(далее…)