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

Настройка авторизации в Kubernetes включает в себя несколько компонентов:

• Аутентификация: Кто вы есть?
• Авторизация: Что вам разрешено делать?
• Admission Control: Дополнительные проверки перед применением изменений.

Аутентификация: Kubernetes поддерживает различные методы аутентификации:

• Сертификаты x509: Наиболее распространенный метод.
• Статические токены (Bootstrap Tokens).
• Относящиеся к сервисному аккаунту токены (Service Account Tokens).
• Различные плагины, такие как OpenID Connect (OIDC), Webhook Token Authentication и другие.

Пример создания сертификата для пользователя:

# Создание приватного ключа для пользователя alice
openssl genrsa -out alice.key 2048
# Создание запроса на подпись сертификата (CSR)
openssl req -new -key alice.key -out alice.csr -subj "/CN=alice/O=devs"
# Подпись CSR контрольным центром сертификации (CA)
# Требует доступа к приватному ключу и сертификату CA кластера
# В продакшене предпочтительнее использовать инструменты управления сертификатами
# или интегрироваться с существующей PKI

Авторизация: Наиболее широко используемый механизм авторизации в Kubernetes — Role-Based Access Control (RBAC). RBAC позволяет определять, какие действия (глаголы, verbs) пользователи или группы могут выполнять с определенными ресурсами в определенных пространствах имен или на уровне кластера.

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

• Role: Определяет набор правил доступа в пределах пространства имен.
• ClusterRole: Определяет набор правил доступа на уровне кластера.
• RoleBinding: Привязывает Role к пользователю, группе или ServiceAccount в пределах пространства имен.
• ClusterRoleBinding: Привязывает ClusterRole к пользователю, группе или ServiceAccount на уровне кластера.

Пример создания Role и RoleBinding:

# role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [""] # Означает "основной" API group (resources like pods, services)
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: default
subjects:
- kind: User
  name: alice # Имя пользователя из запроса на аутентификацию
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader # Имя Role из role.yaml
  apiGroup: rbac.authorization.k8s.io

Применение манифестов:

kubectl apply -f role.yaml
kubectl apply -f rolebinding.yaml

Admission Control: Admission Controllers перехватывают запросы к Kubernetes API-серверу после аутентификации и авторизации, но до сохранения объекта в etcd. Они могут выполнять дополнительные проверки, изменять запрошенные объекты или полностью их отклонять.

Важные Admission Controllers для безопасности:

• AlwaysPullImages: Гарантирует, что kubelet всегда загружает образ во время запуска независимо от того, существует ли уже локальный образ с тем же тегом.
• LimitRanger: Применяет ограничения на использование ресурсов (CPU, памяти, хранилища) для Pods и PersistentVolumeClaims в пространстве имен.
• ResourceQuota: Определяет максимальное потребление ресурсов для пространства имен.
• PodSecurityStandards: Применяет политики безопасности для пода. В более новых версиях Kubernetes используется Pod Security Admission.
• MutatingAdmissionWebhook: Позволяет внешним вебхукам изменять объекты перед их сохранением.
• ValidatingAdmissionWebhook: Позволяет внешним вебхукам проверять объекты перед их сохранением.

Настройка этих компонентов зависит от конкретных требований безопасности и инфраструктуры. Рекомендуется использовать менеджер секретов для управления сертификатами и ключами. Для централизованного управления пользователями и группами можно интегрировать Kubernetes с внешними провайдерами идентификации, такими как LDAP, Active Directory или IdP на базе OIDC.