Как прикрутить авторизацию кластеру

Подход к организации авторизации в Kubernetes кластере

При "прикручивании" авторизации к Kubernetes кластеру речь идет о настройке механизма Authentication (аутентификация) и Authorization (авторизация). Это фундаментальные компоненты безопасности, которые контролируют, кто может получить доступ к кластеру и какие операции разрешено выполнять. Процесс состоит из нескольких ключевых этапов:

1. Выбор и настройка механизма аутентификации

Аутентификация отвечает на вопрос "Кто вы?". Kubernetes не управляет пользователями самостоятельно, а делегирует эту задачу внешним системам.

Основные методы аутентификации:

• X.509 клиентские сертификаты - классический метод, где пользователи предоставляют SSL/TLS сертификат

1. Создаем корневой CA (Certificate Authority):

openssl genrsa -out ca.key 2048
openssl req -new -x509 -key ca.key -out ca.crt -days 365

1. Генерируем клиентский сертификат для пользователя:

openssl genrsa -out user.key 2048
openssl req -new -key user.key -out user.csr -subj "/CN=alice/O=developers"
openssl x509 -req -in user.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out user.crt -days 365

1. Добавляем CA сертификат в kube-apiserver:

# /etc/kubernetes/manifests/kube-apiserver.yaml
apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
spec:
  containers:
  - command:
    - kube-apiserver
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    # ... другие параметры

• Статические токены - простой, но небезопасный метод для тестирования

• ServiceAccount токены - для автоматизации и сервисов внутри кластера -h2 OIDC (OpenID Connect) - интеграция с внешними провайдерами (Keycloak, Google, Azure AD)

  # Конфигурация kube-apiserver для OIDC
  - --oidc-issuer-url=https://keycloak.example.com/auth/realms/master
  - --oidc-client-id=kube-cluster
  - --oidc-username-claim=preferred_username
  - --oidc-groups-claim=groups
  

• Webhook Token Authentication - кастомная проверка токенов через внешний сервис

2. Настройка авторизации (RBAC - Role-Based Access Control)

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

RBAC - наиболее распространенный и рекомендуемый подход:

1. Создаем ServiceAccount для пользователя/приложения:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: developer-sa
  namespace: development

1. Определяем Roles/RoleBindings (namespace-scoped) или ClusterRoles/ClusterRoleBindings (cluster-scoped):

# Role с разрешениями на чтение в namespace development
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-reader
rules:
. apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

1. Привязываем Role к ServiceAccount:

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

3. Интеграция с внешними системами (Enterprise-решения)

Для production-сред часто требуется интеграция с корпоративными системами:

Варианты интеграции:

• Keycloak + OIDC + RBAC - гибкое решение с централизованным управлением пользователями
• Dex как Identity broker с поддержкой LDAP, SAML, OIDC
• OpenUnison - специализированный шлюз для Kubernetes с SSO
• Azure AD / AWS IAM для облачных окружений

4. Практический пример: настройка OIDC с Keycloak

Последовательность действий:

1. Устанавливаем и настраиваем Keycloak
2. Создаем realm, клиента и пользователей в Keycloak
3. Настраиваем kube-apiserver на использование OIDC
4. Создаем ClusterRoleBindings, привязывающие группы из OIDC к ролям Kubernetes:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admins-binding
subjects:
- kind: Group
  name: "cluster-admins"  # Группа из токена OIDC
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

5. Дополнительные меры безопасности

Обязательные практики:

• Регулярная ротация сертификатов и токенов
• Аудит логов kube-apiserver (--audit-log-path)
• Pod Security Policies/Admission Controllers для дополнительного контроля
• Network Policies для изоляции трафика
• Интеграция с SIEM-системами для мониторинга подозрительной активности

6. Инструменты для управления доступом

Популярные инструменты:

• kubectl с контекстами и kubeconfig файлами .

# ~/.kube/config
apiVersion: v1
clusters:
-
cluster:
    certificate-authority-data: <ca.crt в base64>
    server: https://api.k8s.example.com:6443
  name: production
contexts:
- context:
    cluster: production
    user: alice
  name: alice-production
current-context: alice-production
users:
- name: alice
  user:
    client-certificate-data: <user.crt в base64>
    client-key-data: <user.key в base64>

• Rancher - UI с встроенной авторизацией
• Lens IDE - с поддержкой множества контекстов
• kubeadm для автоматической настройки базовой аутентификации при развертывании

Критические рекомендации

Принципы безопасной настройки:

1. Принцип минимальных привилегий - давать только необходимые права
2. Разделение обязанностей - разные роли для разработчиков, операторов, администраторов
3. Регулярный пересмотр прав - аудит RBAC правил
4. Использование namespaces для изоляции окружений
5. Блокировка анонимного доступа (--anonymous-auth=false в kube-apiserver)

Авторизация в Kubernetes - это не единовременная настройка, а непрерывный процесс, требующий мониторинга, аудита и адаптации под меняющиеся требования безопасности. Начинайте с простых схем (ServiceAccount + RBAC), постепенно переходя к интеграции с корпоративными системами при росте кластера и команды.