Tag Archives: Mimboloverole
В контексте описанной выше интеграции критически важно правильно разграничить доступ к 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 подов) только в нужных неймспейсах.
(далее…)
Ресурс Role определяет, какие действия можно предпринимать и на каких ресурсах (или какие типы HTTP-запросов можно выполнять и на каких ресурсах RESTful). В следующем ниже листинге определяется роль, которая позволяет пользователям получать и выводить список служб в пространстве имен boo.
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: boo name: service-reader rules: - apiGroups: [""] verbs: ["get", "list"] resources: ["services"]
0