Как настроить авторизацию в Kubernetes-кластере?

«Как настроить авторизацию в Kubernetes-кластере?» — вопрос из категории Kubernetes, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

В Kubernetes авторизация (управление правами доступа) настраивается в основном через RBAC (Role-Based Access Control). Вот как я это делаю:

1. Определение субъектов доступа:

  • ServiceAccount — для внутрикластерных компонентов (подов, операторов).
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: my-app-sa
      namespace: production
  • Пользователи — для разработчиков и администраторов, аутентифицируемых через клиентские сертификаты, токены или внешние провайдеры (OIDC). Их идентификаторы задаются в конфигурации kubeconfig.

2. Создание ролей (Role/ClusterRole): Роль определяет набор правил (правило = ресурсы + операции). Role — для конкретного namespace, ClusterRole — для всего кластера.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""] # Ядро API
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

3. Привязка ролей к субъектам (RoleBinding/ClusterRoleBinding):

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: ServiceAccount
  name: my-app-sa
  namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

4. Интеграция с внешними системами (для пользователей): Для централизованного управления доступом команды я настраиваю интеграцию с OIDC-провайдером (например, Keycloak или Dex). В конфигурации API-сервера (kube-apiserver) указываются параметры OIDC, а роли привязываются к группам пользователей из токена.

Проверка прав: Перед применением конфигураций всегда проверяю, какие права будут у субъекта:

kubectl auth can-i create deployments --as=system:serviceaccount:production:my-app-sa