Основные рекомендации RBAC для обеспечения безопасности кластеров Kubernetes

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

Это руководство объясняет основные объекты RBAC, показывает рабочие примеры и дает вам привычки проверки, которые предотвращают дрейф доступа с течением времени.

Понимание основ RBAC в Kubernetes

RBAC в Kubernetes — это механизм авторизации, который регулирует доступ к ресурсам Kubernetes на основе ролей отдельных пользователей или сервисных аккаунтов. Это критически важный уровень защиты, гарантирующий, что только авторизованные субъекты могут выполнять определенные действия над определенными ресурсами.

В своей основе RBAC опирается на четыре основных типа объектов Kubernetes:

• Role: Role — это набор разрешений, который применяется в пределах определенного пространства имен. Он определяет, какие действия (глаголы, такие как get, list, create, update, delete) могут выполняться над какими ресурсами (например, pods, deployments, services, secrets). Например, Role может предоставлять разрешение на чтение pods и deployments в пространстве имен development.
• ClusterRole: Аналогично Role, но ClusterRole определяет разрешения, которые применяются кластерно или к ресурсам, не принадлежащим пространствам имен (например, nodes, persistentvolumes). ClusterRole также может определять разрешения для ресурсов в пространствах имен во всех пространствах имен. Например, ClusterRole может разрешать перечисление всех nodes в кластере.
• RoleBinding: RoleBinding предоставляет разрешения, определенные в Role (или ClusterRole, применяемом в пространстве имен), пользователю, группе или сервисному аккаунту. Он всегда действует в пределах определенного пространства имен.
• ClusterRoleBinding: ClusterRoleBinding предоставляет разрешения, определенные в ClusterRole, пользователю, группе или сервисному аккаунту, применяя эти разрешения во всем кластере.

Вместе эти объекты позволяют администраторам построить надежную и детализированную систему контроля доступа. Когда пользователь или приложение (представленное сервисным аккаунтом) пытается выполнить действие, Kubernetes оценивает существующие RoleBindings и ClusterRoleBindings, чтобы определить, разрешено ли запрашиваемое действие.

Реализация принципа наименьших привилегий с помощью RBAC

Центральный принцип информационной безопасности — принцип наименьших привилегий. Пользователь, программа или процесс должны получать только те разрешения, которые необходимы для выполнения их работы. В Kubernetes чрезмерно разрешительные роли — это распространенный способ, когда небольшая компрометация перерастает в проблему масштаба всего кластера.

Определение детализированных разрешений

При создании политик RBAC подумайте о точных действиях и ресурсах, которые требуются:

• Глаголы: Вместо предоставления * (все глаголы) укажите точно, какие действия необходимы (get, list, watch, create, update, delete, patch, exec).
• Ресурсы: Будьте конкретны в отношении ресурсов (pods, deployments, secrets, configmaps). Избегайте предоставления доступа к * для ресурсов, если это абсолютно необходимо и только для хорошо обоснованных административных ролей.
• Имена ресурсов: Для очень чувствительных ресурсов, таких как secrets, вы можете ограничить некоторые глаголы, например get, конкретными resourceNames в рамках типа ресурса. Не полагайтесь на resourceNames для доступа типа списка, поскольку list и watch не ограничиваются одним именованным объектом таким же образом.
• Группы API: Большинство ресурсов Kubernetes принадлежат к группе API (например, apps, rbac.authorization.k8s.io, "" для основных ресурсов). Укажите правильную группу API, чтобы еще больше сузить область действия.

Ограничение пространства имен

Для большинства приложений и команд разработчиков разрешения должны быть ограничены конкретными пространствами имен. Такая сегрегация гарантирует, что компрометация в среде одного приложения или команды не приведет автоматически к доступу ко всему кластеру. Всегда предпочитайте Role и RoleBinding вместо ClusterRole и ClusterRoleBinding, когда это возможно.

Практическая реализация RBAC: примеры

Давайте рассмотрим несколько практических примеров создания и привязки политик RBAC.

Пример 1: Доступ разработчика к определенному пространству имен

Представьте, что разработчику нужно управлять развертываниями и просматривать логи в своем выделенном пространстве имен dev-team-a. У него не должно быть доступа к другим пространствам имен или ресурсам всего кластера.

Сначала определите Role для разработчика в пространстве имен dev-team-a:

# dev-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team-a
  name: dev-deployer
rules:
- apiGroups: ["apps"] # Для Deployments
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "delete", "patch"]
- apiGroups: [""] # Основная группа API для Pods и логов Pods
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

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

kubectl apply -f dev-role.yaml

Затем привяжите эту Role к конкретному пользователю (например, [email protected] через внешнего провайдера удостоверений) или сервисному аккаунту в пространстве имен dev-team-a:

# dev-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev-team-a
  name: john-dev-deployer-binding
subjects:
- kind: User
  name: [email protected] # Имя чувствительно к регистру
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-deployer
  apiGroup: rbac.authorization.k8s.io

Примените эту привязку:

kubectl apply -f dev-role-binding.yaml

Теперь [email protected] может только управлять развертываниями и просматривать логи в пределах пространства имен dev-team-a. Он не может, например, создавать секреты в kube-system или перечислять все узлы.

Пример 2: Доступ сервисного аккаунта приложения к секретам

Приложению, работающему как ServiceAccount, необходимо прочитать определенный секрет в своем собственном пространстве имен.

Сначала убедитесь, что сервисный аккаунт существует, или создайте его:

# app-sa.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: my-app-namespace
  name: my-app-service-account

Примените этот сервисный аккаунт:

kubectl apply -f app-sa.yaml

Затем определите Role, которая разрешает чтение определенного секрета:

# secret-reader-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: my-app-namespace
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["my-app-db-credentials"]
  verbs: ["get"]

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

kubectl apply -f secret-reader-role.yaml

Наконец, привяжите эту Role к my-app-service-account:

# app-secret-reader-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: my-app-namespace
  name: my-app-secret-reader-binding
subjects:
- kind: ServiceAccount
  name: my-app-service-account
  namespace: my-app-namespace
roleRef:
  kind: Role
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Примените эту привязку:

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

Теперь приложение сможет только читать указанный секрет и ничего больше.

Пример 3: Роль администратора кластера (с осторожностью)

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

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

Примените этот ClusterRole:

kubectl apply -f node-viewer-clusterrole.yaml

Затем привяжите его к сервисному аккаунту мониторинга с помощью ClusterRoleBinding:

# monitoring-node-viewer-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: monitoring-node-viewer-binding
subjects:
- kind: ServiceAccount
  name: monitoring-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: rbac.authorization.k8s.io

Примените эту привязку:

kubectl apply -f monitoring-node-viewer-binding.yaml

Предупреждение: Будьте предельно осторожны с ClusterRole и ClusterRoleBinding для пользователей-людей. Ограничьте их использование настоящими администраторами кластера и конкретными сервисными аккаунтами инфраструктуры.

Основные рекомендации RBAC

Соблюдение этих рекомендаций значительно повысит уровень безопасности вашего кластера:

1. Применяйте принцип наименьших привилегий (PoLP):

   • Предоставляйте только минимально необходимые разрешения. Тщательно проверяйте каждое разрешение.
   • Избегайте подстановочных знаков (*) для resources и verbs, когда это возможно. Если они используются, обоснуйте это и старайтесь максимально сузить их область действия.
   • Ограничьте доступ к чувствительным ресурсам (например, secrets), используя resourceNames в ролях.

2. Используйте пространства имен для сегрегации:

   • Организуйте свои приложения и команды в отдельные пространства имен.
   • По умолчанию используйте Role и RoleBinding для предоставления разрешений в этих пространствах имен.

3. Предпочитайте Roles вместо ClusterRoles:

   • Используйте ClusterRole и ClusterRoleBinding только тогда, когда разрешения действительно должны быть кластерными (например, управление узлами, определения пользовательских ресурсов, определенные агенты мониторинга).
   • Большинство разрешений, специфичных для приложений, должны быть ограничены пространством имен.

4. Регулярно проверяйте и пересматривайте политики RBAC:

   • Политики RBAC могут дрейфовать со временем. Периодически проверяйте, у кого какой доступ.
   • Используйте такие инструменты, как kubectl auth can-i, для проверки разрешений для конкретных пользователей/сервисных аккаунтов.

   # Проверьте, может ли '[email protected]' получать pods в 'dev-team-a'
   kubectl auth can-i get pods --namespace=dev-team-a [email protected]
   
   # Проверьте, может ли 'monitoring-sa' перечислять узлы (кластерно)
   kubectl auth can-i list nodes --as=system:serviceaccount:monitoring:monitoring-sa
   

   • Рассмотрите сторонние инструменты или пользовательские скрипты для всестороннего аудита RBAC.

5. Разделяйте административные роли:

   • Никогда не предоставляйте разработчикам или сервисным аккаунтам приложений привилегии cluster-admin.
   • Создавайте конкретные административные ClusterRoles только с необходимыми повышенными разрешениями (например, cluster-reader, node-reader).

6. Используйте сервисные аккаунты для приложений:

   • Приложения, работающие внутри кластера, должны использовать ServiceAccounts для взаимодействия с API Kubernetes.
   • Каждое приложение или микросервис в идеале должны иметь свой собственный выделенный ServiceAccount с минимальными разрешениями.
   • Установите automountServiceAccountToken: false для подов, которым не требуется доступ к API Kubernetes, либо на поде, либо на сервисном аккаунте.

7. Интегрируйтесь с внешним управлением удостоверениями:

   • Для пользователей-людей интегрируйте Kubernetes с внешним провайдером удостоверений (например, OIDC, LDAP, Active Directory) для аутентификации и управления группами.
   • Сопоставляйте внешние группы с RoleBindings или ClusterRoleBindings Kubernetes для упрощения управления.

8. Автоматизируйте управление RBAC с помощью GitOps:

   • Относитесь к своим политикам RBAC как к коду. Храните их в репозитории с контролем версий (Git).
   • Используйте принципы GitOps для управления и развертывания конфигураций RBAC, обеспечивая согласованность, отслеживаемость и более легкий откат.

9. Мониторьте события RBAC через журналы аудита:

   • Включите и настройте ведение журнала аудита Kubernetes для отслеживания запросов API, включая то, кто выполнил какое действие и когда.
   • Регулярно просматривайте журналы аудита для обнаружения несанкционированных попыток доступа или подозрительных действий, связанных с RBAC.

10. Регулярно обновляйте Kubernetes:

    • Следите за актуальностью версий Kubernetes, чтобы пользоваться исправлениями безопасности и улучшениями, включая усовершенствования RBAC.

Распространенные ошибки и как их избежать

• Чрезмерно разрешительные подстановочные знаки: Предоставление apiGroups: ["*"], resources: ["*"] или verbs: ["*"] представляет собой серьезный риск для безопасности. Всегда будьте явными.
• Использование cluster-admin по умолчанию: Не используйте группу system:masters или ClusterRole cluster-admin для повседневных операций и не назначайте их неадминистративным пользователям. Любой из них дает широкий контроль над кластером.
• Игнорирование automountServiceAccountToken: Во многих кластерах поды получают токен сервисного аккаунта, если вы не отключите автоматическое монтирование. Если поду не нужно взаимодействовать с API Kubernetes, установите automountServiceAccountToken: false в спецификации пода или определении сервисного аккаунта, чтобы уменьшить его поверхность атаки.
• Отсутствие аудита: Без регулярного пересмотра политики RBAC могут устареть или стать чрезмерно разрешительными по мере развития потребностей кластера. Внедрите процесс пересмотра.
• Путаница между Role и ClusterRole: Неправильное понимание области действия может привести к предоставлению доступа ко всему кластеру, когда предполагался доступ только в пределах пространства имен.

Вывод

RBAC работает лучше всего, когда вы сохраняете его скучным и конкретным: роли в пространствах имен для команд приложений, узкие разрешения сервисных аккаунтов, никаких подстановочных знаков без проверки и регулярные проверки kubectl auth can-i. Относитесь к каждой привязке как к производственному коду, потому что в кластере Kubernetes это фактически так и есть.