Как настроить RBAC в Kubernetes

~ 40 минут

В современных распределённых системах, таких как Kubernetes, управление доступом к ресурсам играет критически важную роль в обеспечении безопасности и стабильности всей инфраструктуры. Там, где многие пользователи и сервисы взаимодействуют с распределёнными системами, без чёткого разграничения прав доступа высок риск утечек данных и случайных изменений.

Чтобы участники не получали избыточных привилегий, хорошо подходит модель управления доступом на основе ролей — RBAC (Role-Based Access Control). Эта система позволяет назначать права доступа в зависимости от ролей пользователей и сервисов, а ещё предоставляет гибкий и детализированный контроль над тем, кто и какие действия может выполнять в кластере. Применение RBAC помогает минимизировать риски, связанные с избыточными привилегиями, и упрощает управление доступом в условиях масштабируемых распределённых систем.

Кейс компании HomeGuard

В этом уроке вы рассмотрите реализацию RBAC в среде Kubernetes на примере стартапа HomeGuard.

HomeGuard предлагает комплексную систему для страхования жилья с использованием умных устройств. Само страхование выполняется партнёром компании, датчики для умного дома производятся тоже другой компанией. У HomeGuard основная задача — интегрировать возможности партнеров в единое предложение для клиентов, обеспечивать контроль и управление умными датчиками, а также собирать данные для страховых компаний.

Для компании крайне важно, чтобы все собранные клиентские данные были защищены, а доступ к системам управления был чётко разделён. Для управления доступом к различным ресурсам в Kubernetes-кластере (в котором сохраняются и обрабатываются данные от устройств) HomeGuard применяет систему ролевого управления доступом (RBAC).

Основные компоненты

В RBAC Kubernetes используется четыре основных компонента: Role, ClusterRole, RoleBinding и ClusterRoleBinding. Их различие основывается на области применения: одни компоненты работают в рамках кластера, а другие локализуются в неймспейсе. Неймспейсы в Kubernetes, как папки в пределах одного кластера, помогают разделять проекты, команды или окружения.

Итак, компоненты RBAC:

Role (роль) — набор разрешений, который определяет, какие действия можно выполнять над ресурсами в определённом неймспейсе.
ClusterRole аналогичен Role, но применяется ко всему кластеру. Используется для управления ресурсами, которые не привязаны к определённому неймспейсу, например nodes или persistentvolumes.
RoleBinding связывает пользователя, группу или сервисный аккаунт с ролью (Role) в конкретном неймспейсе и предоставляет разрешения, которые определены в роли.
ClusterRoleBinding аналогичен RoleBinding, но применяется ко всему кластеру. Связывает пользователя, группу или сервисный аккаунт с кластерной ролью (ClusterRole).

Кейс компании HomeGuard

HomeGuard использует Kubernetes для управления данными, которые поступают с умных устройств, установленных в домах клиентов. И использование RBAC становится неотъемлемой частью управления доступом к данным и ресурсам кластера.

Неймспейсы для изоляции данных В рамках каждого объекта (дома или группы домов) создаётся отдельный неймспейс, в котором операторы могут работать только с данными, относящимися к этому объекту. Использование Role и RoleBinding позволяет операторам системы просматривать только информацию, относящуюся к конкретному дому (например, данные о протечках или задымлении), без доступа к другим неймспейсам. Такой подход обеспечивает изоляцию данных и позволяет минимизировать риски, связанные с утечками или несанкционированным доступом.
Разграничение доступа с помощью ClusterRole Для задач, связанных с управлением всей инфраструктурой, например мониторинг состояния узлов или сетевой конфигурации, используются ClusterRole и ClusterRoleBinding. Это позволяет управлять ресурсами всего кластера, не затрагивая данные клиентов. Важно использовать ClusterRole только для тех задач, которые требуют доступа к общекластерным ресурсам, чтобы избежать избыточных привилегий для пользователей, которые работают с отдельными компонентами.
Принцип минимальных привилегий Операторы имеют доступ только к тем ресурсам, которые необходимы для выполнения их задач, а инженеры — только к системным компонентам кластера, которые они поддерживают. Этот подход помогает минимизировать риски случайных изменений и улучшить безопасность системы.
Мониторинг и логирование HomeGuard использует инструменты вроде Prometheus, Grafana. Это позволяет не только отслеживать состояние системы в реальном времени, но и настраивать оповещения в случае аномалий или инцидентов.
Изоляция и отказоустойчивость Изоляция неймспейсов тоже помогает при сбоях: ошибки в одном неймспейсе не влияют на другие объекты, что повышает отказоустойчивость системы.

Настройка RBAC: практика

⚙️ В этом разделе содержится практический пример по настройке RBAC в Kubernetes. В начале работы убедитесь, что у вас есть доступ к работающему кластеру Kubernetes и инструменту командной строки kubectl.

Этап 1. Подготовка окружения

Для практической части потребуется доступ к работающему кластеру Kubernetes и настроенный kubectl для управления кластером.

Проверьте, что у вас есть доступ к кластеру:

BASH

kubectl get nodes

Эта команда выведет список узлов в кластере. Если список узлов получен, это подтверждает, что доступ к кластеру настроен и можно переходить к практическим шагам по настройке RBAC.

Вместо использования kubectl для визуального управления кластером и мониторинга ресурсов можно использовать OpenLens — удобный инструмент с графическим интерфейсом для работы с Kubernetes. Для пользователей, предпочитающих графический интерфейс вместо командной строки, OpenLens может стать более наглядным и простым способом взаимодействия с кластером.

Этап 2. Создание Role

При определении полномочий роли (role) Kubernetes оперирует глаголом (verb) и выделяет две категории глаголов:

Для права на запись (write) — create, update, patch
Для права на чтение (read) — get, list, watch

Создадим роль, которая разрешит выполнение только операций чтения над ресурсами pods в определённом неймспейсе (например, development):

YAML

# role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Применим эту роль в кластере:

BASH

kubectl apply -f role.yaml

Теперь в неймспейсе development существует роль pod-reader, ограничивающая действия пользователя или сервисного аккаунта операциями чтения.

Кейс компании HomeGuard

В HomeGuard при мониторинге датчиков, установленных в домах клиентов, операторы имеют ограниченные права доступа. Для этого создаются роли, подобные pod-reader, которые разрешают операторам только просматривать состояние подов (pods) в соответствующем неймспейсе. Это помогает поддерживать безопасность и минимизировать риски, связанные с несанкционированными изменениями конфигураций системы.

Этап 3. Создание RoleBinding

Теперь свяжем созданную роль с конкретным пользователем или сервисным аккаунтом. В данном случае связываем роль pod-reader с пользователем developer:

YAML

# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: development
subjects:
- kind: User
  name: developer
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Применим RoleBinding:

BASH

kubectl apply -f rolebinding.yaml

Теперь пользователь developer имеет права на просмотр подов (pods) в неймспейсе development.

Кейс компании HomeGuard

В HomeGuard роль, например pod-reader, используется для мониторинга данных с датчиков, установленных в домах. Однако просто создания роли недостаточно — необходимо связать её с конкретным пользователем или сервисным аккаунтом, который будет выполнять эти задачи. Это позволяет точно контролировать, кто имеет доступ к данным и ресурсам в каждом отдельном доме.

Для этого в HomeGuard создаются RoleBinding для каждой группы операторов или инженеров, работающих с данными. Пример привязки роли pod-reader к сервисному аккаунту home-operator в неймспейсе:

YAML

# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: home-namespace
subjects:
- kind: ServiceAccount
  name: home-operator
  namespace: home-namespace
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RoleBinding в HomeGuard контролирует доступ к данным по дому и минимизирует риски.

Важно, чтобы каждый оператор имел доступ только к тем данным, которые относятся к определённому дому или группе домов. RoleBinding связывает роль с конкретным сервисным аккаунтом или пользователем, который имеет право только на чтение данных в рамках своего неймспейса. Это помогает поддерживать высокий уровень безопасности и разграничивать права доступа между разными операторами.

Используя RoleBinding, HomeGuard избегает ситуации, когда один оператор может получить доступ к данным других клиентов или внести изменения в критически важные системы. Каждый оператор или инженер работает только с теми данными, которые ему разрешены, что минимизирует риск случайных или преднамеренных действий, которые могут нарушить работу системы.

💡 На что обратить внимание

Точное соответствие субъекта и роли Убедитесь, что каждый RoleBinding связывает только нужные роли с конкретными сервисными аккаунтами или пользователями. Это гарантирует, что пользователи не получат лишние права доступа.
Ограничение действий в пределах одного неймспейса Каждый RoleBinding должен быть нацелен на конкретный неймспейс. Это помогает поддерживать изоляцию данных между клиентами и обеспечивает безопасность обработки информации.
Регулярный аудит привязок Проводите регулярный аудит всех RoleBinding, чтобы быть уверенным в том, что старые или неиспользуемые привязки отсутствуют, а новые добавляются с учётом текущих задач и ролей.

Этап 4. Сетевые политики

Для обеспечения безопасности в кластере Kubernetes важно не только управлять доступом к данным через RBAC, но и контролировать сетевые взаимодействия между подами. Сетевые политики (network policies) позволяют ограничивать и настраивать сетевую активность в кластере, задавая правила для входящего и исходящего трафика.

Настроим сетевую политику, которая позволит взаимодействовать подам с метками app: front-end и role: back-end-api.

YAML

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      role: back-end-api
  policyTypes:
  - Ingress
  ingress:
  - from:
      - podSelector:
          matchLabels:
            app: front-end

Теперь политика разрешает подам с меткой app: front-end взаимодействовать с подами, у которых метка role: back-end-api. Это позволяет более строго контролировать доступ между разными компонентами системы.

Кейс компании HomeGuard

В HomeGuard сетевые политики используются для разграничения сетевого доступа между сервисами. Например, сервисы, отвечающие за сбор данных с умных датчиков, имеют доступ только к необходимым внутренним сервисам, таким как аналитические или логистические сервисы, и не могут взаимодействовать с другими компонентами кластера. Это помогает защитить систему от потенциальных атак и снизить вероятность нежелательных сетевых соединений.

Этап 5. Создание ClusterRole

ClusterRole позволяет управлять разрешениями на уровне всего кластера — создадим роль, которая разрешает чтение всех подов во всех неймспейсах:

YAML

# clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

И применим эту роль:

BASH

kubectl apply -f clusterrole.yaml

Кейс компании HomeGuard

В системе HomeGuard поддержка и обслуживание системы умного дома включают множество узлов и распределённых ресурсов. Поэтому ClusterRole необходим для управления инфраструктурой на уровне всего кластера. Например, доступ к данным о состоянии узлов или управление хранилищами может быть необходим, чтобы обеспечивать бесперебойную работу всех систем мониторинга.

Пример ClusterRole, которая предоставляет доступ только на чтение для подов во всём кластере:

YAML

# clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Мы создаём ClusterRole под названием cluster-pod-reader, которая позволяет инженерам читать данные о подах во всех неймспейсах кластера. Такая роль может быть полезна для мониторинга состояния подов на всех уровнях инфраструктуры, что критично для стабильности всей системы HomeGuard.

Особенности создания ClusterRole для HomeGuard

Доступ к кластерным ресурсам В HomeGuard команда DevOps работает с инфраструктурными компонентами, такими как узлы и сети, которые не привязаны к конкретным неймспейсам. ClusterRole даёт возможность получить доступ к этим ресурсам, что позволяет DevOps-инженерам следить за стабильностью всей системы и управлять всеми необходимыми компонентами, не ограничиваясь одним неймспейсом. Однако стоит ограничивать действия: инженеры должны иметь доступ только на чтение, чтобы они не могли случайно изменять критические ресурсы.
Мониторинг инфраструктуры В HomeGuard критически важно, чтобы вся инфраструктура оставалась в рабочем состоянии. Для этого инженеры получают права на чтение данных о состоянии узлов и подов через ClusterRole, что позволяет оперативно реагировать на проблемы и обеспечивать высокую доступность всех компонентов.

💡На что обратить внимание

Минимизация прав Хотя ClusterRole предоставляет доступ ко всем неймспейсам и ресурсам кластера, важно ограничить права только теми действиями, которые действительно необходимы.
Централизованный мониторинг Доступ через ClusterRole используется для централизованного мониторинга всей инфраструктуры. Это помогает поддерживать контроль над всей системой.

Этап 6. Создание ClusterRoleBinding

После создания ClusterRole необходимо связать её с конкретным пользователем, группой или сервисным аккаунтом, чтобы предоставить им доступ к кластерным ресурсам. Для этого используется ClusterRoleBinding, который связывает ClusterRole с субъектами на уровне всего кластера. Это позволяет обеспечить доступ ко всем неймспейсам или специфическим кластерным ресурсам.

Свяжем ClusterRole с пользователем:

YAML

# clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-read-pods
subjects:
- kind: User
  name: developer
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-pod-reader
  apiGroup: rbac.authorization.k8s.io

Применим ClusterRoleBinding:

BASH

kubectl apply -f clusterrolebinding.yaml

Теперь пользователь developer имеет права на просмотр подов во всех неймспейсах кластера.

Кейс компании HomeGuard

В компании HomeGuard доступ к кластерным ресурсам необходим для инженеров, которые обеспечивают стабильность инфраструктуры и следят за всеми компонентами кластера. ClusterRoleBinding связывает роль cluster-pod-reader с конкретными группами инженеров или сервисными аккаунтами, давая им возможность мониторить состояние всех узлов и подов кластера.

Пример манифеста ClusterRoleBinding для связи роли cluster-pod-reader с сервисным аккаунтом infrastructure-operator:

YAML

# clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-read-pods
subjects:
- kind: ServiceAccount
  name: infrastructure-operator
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: cluster-pod-reader
  apiGroup: rbac.authorization.k8s.io

Так мы связываем ClusterRole cluster-pod-reader с сервисным аккаунтом infrastructure-operator, который используется командой DevOps для мониторинга подов во всех неймспейсах. Теперь этот сервисный аккаунт может получать данные о подах по всему кластеру.

Особенности создания ClusterRoleBinding

Централизованный доступ В HomeGuard инженеры нуждаются в доступе к кластерным ресурсам, таким как состояние узлов или мониторинг подов во всех неймспейсах. ClusterRoleBinding позволяет централизовать этот доступ, связывая одну роль с несколькими сервисными аккаунтами или группами инженеров.
Разделение обязанностей В HomeGuard важна ясность в разграничении ролей и привязок. Например, ClusterRoleBinding может быть настроен так, чтобы инженеры инфраструктуры могли мониторить состояние системы, но не могли изменять или удалять ресурсы. Это гарантирует соблюдение принципа минимальных привилегий и предотвращает ошибки, которые могут негативно повлиять на стабильность кластера.

💡На что обратить внимание

Точность привязок Важно, чтобы ClusterRoleBinding был настроен с учётом ролей, которые действительно нужны каждой группе.
Мониторинг использования Создавая ClusterRoleBinding, важно отслеживать использование кластерных ресурсов через журналы доступа. Это позволяет быстро реагировать на любые несанкционированные действия или ошибки.

Практические сценарии

1. Ограничение доступа к конфигурационным данным

Доступ необходимо разрешить только к секретам (secrets) одной группе пользователей и в определённом неймспейсе. Создадим Role и RoleBinding для этого сценария:

YAML

# secret-reader-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: secure-space
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]

YAML

# secret-reader-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-secrets
  namespace: secure-space
subjects:
- kind: User
  name: secure-operator
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Применим эти манифесты:

BASH

kubectl apply -f secret-reader-role.yaml
kubectl apply -f secret-reader-binding.yaml

Теперь secure-operator имеет доступ к секретам в неймспейсе secure-space.

2. Ограничение доступа к конфиденциальным данным

Чтобы предоставить DevOps-команде доступ к управлению развертыванием подов без возможности изменять другие ресурсы, создадим Role и RoleBinding, которые предоставляют только необходимые разрешения:

YAML

# devops-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: devops-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create", "delete", "list"]

YAML

# devops-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: devops-access
  namespace: development
subjects:
- kind: Group
  name: devops-group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: devops-role
  apiGroup: rbac.authorization.k8s.io

Применение этих манифестов даст группе devops-group права только на управление подами в неймспейсе development.

Кейс компании HomeGuard

HomeGuard работает с несколькими партнёрами, включая производителей датчиков и страховые компании, поэтому ключи API и данные для взаимодействия с внешними системами нужно надёжно защищать. Для этого используется отдельный неймспейс, где хранятся секреты (secrets) и другие чувствительные данные.

HomeGuard применяет роли, например secret-manager, которые позволяют инженерам безопасности, просматривать и управлять секретами. Эти роли создаются с учётом минимальных привилегий. А сами данные сегментируются по неймспейсам и предоставляются только тем группам или сервисным аккаунтам, которым это действительно необходимо для работы.

Например, операторы системы могут иметь доступ только к информации о состоянии подов и конфигурации в пределах своего неймспейса, а инженеры безопасности управляют ключами API только в том неймспейсе, где требуется взаимодействие с партнёрами.

Особенности для HomeGuard

Изоляция конфиденциальных данных Каждый неймспейс чётко разделяет данные, чтобы инженеры и операторы могли работать только с той информацией, которая необходима для выполнения их задач.
Роли для управления секретами Использование роли secret-manager ограничивает доступ только к секретам и ключам API, минимизируя риск утечек или несанкционированного доступа.

Типичные ошибки

Назначение широких привилегий Использование ролей с разрешениями ` (например, "*" в поле verbs`) создает риск несанкционированного доступа. Это открывает больше возможностей для атак и утечек данных.
Отсутствие аудитных процессов Пренебрежение регулярным аудитом настроек RBAC может привести к наличию устаревших или избыточных ролей, которые могут использовать злоумышленники.
Неправильное использование ClusterRole для конкретных неймспейсов Использование ClusterRole вместо Role в ситуациях, когда роль нужна только для одного неймспейса, может привести к излишне широкому доступу. Используйте ClusterRole только тогда, когда роль должна охватывать весь кластер или взаимодействовать с кластерными ресурсами.

Лучшие практики

Помните про принцип минимальных привилегий (Least Privilege) Предоставляйте роли только те разрешения, которые действительно необходимы. Например, если пользователь должен только читать логи подов, назначьте разрешение "get" для ресурса pods/log вместо более широких прав доступа.
Используйте группы Вместо назначения прав каждому пользователю индивидуально, объединяйте пользователей в группы. Это упрощает управление доступом и снижает риск ошибки. Например, создайте группу developers, чтобы контролировать права всех разработчиков единым образом.
Разграничивайте доступ Разделяйте роли по типу деятельности. Создавайте отдельные роли для разработчиков, администраторов баз данных, DevOps-инженеров, сетевых администраторов и т. д. Это поможет избежать несанкционированного доступа к ресурсам и упростит управление.
Проводите периодический аудит Регулярно проводите аудит ролей и привязок. Пересматривайте и удаляйте неиспользуемые роли и привязки. Используйте команду kubectl get roles,rolebindings --all-namespaces для получения списка всех настроек RBAC в кластере.
Используйте неймспейсы для сегментации доступа Связывайте роли с неймспейсами через Role и RoleBinding, чтобы ограничить влияние действиями только в рамках конкретного пространства имен.

Кейс компании HomeGuard

HomeGuard придерживается строгого принципа минимальных привилегий при назначении прав доступа. Это означает, что каждый сотрудник или сервисный аккаунт получает только те права, которые необходимы для выполнения конкретных задач. Например, разработчики, работающие над внедрением новых функций взаимодействия с датчиками, могут просматривать логи и состояние подов в тестовой среде, но не имеют прав доступа к продакшен-кластерам или управлению конфиденциальными данными.

Задание 1

Компания SafeHome разрабатывает систему для управления умными устройствами в домах клиентов. В их Kubernetes-кластере настроена система RBAC для ограничения доступа к различным ресурсам. В компании работает несколько команд: операторы, инженеры DevOps и аналитики данных. Каждый пользователь или сервисный аккаунт должен иметь доступ только к необходимым для его работы ресурсам.

Текущая задача — настроить RBAC так, чтобы:

Операторы могли только просматривать состояние подов в неймспейсе operations.
Инженеры DevOps — разворачивать новые поды в неймспейсе devops
Аналитики данных имели доступ только к конфигурационным файлам в неймспейсе analytics.

Какую роль следует назначить операторам, чтобы они могли только просматривать поды в неймспейсе operations?

ClusterRole с правами на просмотр всех ресурсов

Это слишком широкие права. Операторам нужен доступ только к подам в одном неймспейсе, поэтому следует использовать более узкий набор прав.

Role с правами на просмотр подов

Role с правами на просмотр подов ограничит доступ только к операциям чтения в пределах указанного неймспейса, что соответствует принципу минимальных привилегий.

RoleBinding с правами на управление конфигурациями

RoleBinding используется для привязки ролей к пользователям или сервисам, а не для задания самих прав. К тому же, операторам нужен доступ к подам, а не к конфигурациям.

ClusterRoleBinding с полными правами администратора

Это слишком широкие полномочия. Операторам не нужно иметь административный доступ к кластеру, их задачи связаны только с просмотром состояния подов.

Задание 2

Компания TechGuard управляет большим количеством распределённых сервисов в своём кластере Kubernetes. В кластер интегрированы сторонние решения по мониторингу, CI/CD, а также есть несколько команд: разработчики, инженеры поддержки и специалисты по безопасности.

Необходимо настроить RBAC таким образом, чтобы:

Разработчики могли развертывать приложения и удалять поды, но только в своих собственных неймспейсах.
Инженеры поддержки могли мониторить поды и ресурсы кластера, но не вносить изменений.
Специалисты по безопасности имели доступ только к конфиденциальным данным (секретам) и могли просматривать их исключительно в защищённом неймспейсе.

Какие действия и настройки помогут вам достичь этих целей? Выберите все правильные ответы.

Создать ClusterRole для инженеров поддержки с правами на чтение подов и других ресурсов во всех неймспейсах, и связать её через ClusterRoleBinding

ClusterRole необходима для того, чтобы инженеры поддержки могли мониторить состояние ресурсов по всему кластеру без возможности вносить изменения.

Связать разработчиков через ClusterRoleBinding с ролью, которая предоставляет права на создание и удаление подов во всех неймспейсах

ClusterRoleBinding предоставляет слишком широкие права. Разработчики должны работать только в своих неймспейсах, поэтому нужно использовать RoleBinding и ограничить их доступ.

Создать Role для разработчиков с правами на управление подами в каждом из их неймспейсов и связать её через RoleBinding

Разработчикам нужен ограниченный доступ к ресурсам только в их неймспейсах, поэтому Role с правами на управление подами в рамках конкретного неймспейса — правильный выбор.

Создать ClusterRole с правами на управление секретами и привязать её через ClusterRoleBinding к специалистам по безопасности

Специалисты по безопасности работают с чувствительными данными на уровне всего кластера, поэтому нужна ClusterRole с привязкой через ClusterRoleBinding.

Настроить RoleBinding для инженеров поддержки с привязкой к роли, ограничивающей их права только на просмотр подов в их неймспейсе

RoleBinding с ограничением на просмотр подов для инженеров поддержки должен быть на уровне кластера, поскольку им нужно мониторить ресурсы по всему кластеру.

Создать Role для специалистов по безопасности, которая предоставляет доступ только к секретам в конкретном неймспейсе, и связать её через RoleBinding

Role ограничивает доступ специалистов по безопасности только к конфиденциальным данным в определённом неймспейсе, что соответствует принципу минимальных привилегий.

Задание 3

Вы обнаружили, что одному из разработчиков в компании HomeGuard были случайно предоставлены слишком широкие привилегии, позволяющие ему изменять кластерные ресурсы. Какой из следующих шагов будет лучшим для минимизации прав доступа и улучшения безопасности кластера?

Создать новую роль с минимально необходимыми правами и применить её через RoleBinding

Создание новой роли с минимальными правами — это хороший шаг, но сначала необходимо провести аудит текущих ролей и привязок, чтобы выявить все избыточные права.

Создать новую ClusterRole с доступом ко всем ресурсам и назначить её только администраторам

Создание новой ClusterRole с доступом ко всем ресурсам может ещё больше усложнить ситуацию, так как она может дать избыточные права администраторам. Это не решает проблему минимизации прав.

Назначить роль admin каждому разработчику для упрощения управления

Назначение роли admin каждому разработчику создаст слишком широкий доступ и повысит риски для безопасности кластера. Это противоречит принципу минимальных привилегий.

Провести аудит всех ролей и привязок в кластере и удалить неиспользуемые или слишком широкие роли

Проведение аудита ролей и привязок помогает выявить и устранить излишне широкие привилегии, что минимизирует риски несанкционированных изменений и утечек данных.

Дополнительные материалы

Официальная документация Kubernetes по RBAC
Руководство по управлению доступом в Kubernetes
Kubernetes Security Best Practices — лучшие практики по безопасности Kubernetes.

Итоги

В Kubernetes система управления доступом реализована через механизм Role-Based Access Control (RBAC). Компоненты Role, RoleBinding, ClusterRole и ClusterRoleBinding помогают определить, кто и что может делать в среде. Правильная настройка RBAC обеспечивает баланс между безопасностью и удобством использования кластера.
Role — это набор разрешений, которые описывают, какие действия можно выполнять над конкретными ресурсами в пределах одного неймспейса. Например, можно создать роль, которая разрешает пользователю читать конфигурационные карты и секреты, но не позволяет изменять их. RoleBinding связывает эту роль с конкретными пользователями, группами или сервисными аккаунтами, предоставляя им те разрешения, которые указаны в Role.
ClusterRole и ClusterRoleBinding работают по тому же принципу, но расширяют функциональность RBAC до уровня всего кластера. ClusterRole позволяет задавать набор разрешений, которые могут применяться ко всем неймспейсам сразу или даже к ресурсам кластера. В отличие от Role, которая ограничена одним неймспейсом, ClusterRole может использоваться для управления более глобальными ресурсами.
Лучшие практики реализации RBAC в Kubernetes включают использование принципа минимальных привилегий, при котором предоставляются только те разрешения, которые необходимы для выполнения задач. Рекомендуется разделять роли по типам деятельности, создавая отдельные роли для разработчиков, администраторов баз данных, DevOps-инженеров и других специалистов. Регулярный аудит ролей и привязок позволяет своевременно удалять неиспользуемые разрешения и поддерживать актуальную настройку доступа. Для сегментации прав доступа полезно применять неймспейсы и связывать роли через Role и RoleBinding для ограничения влияния на конкретные пространства имён.