Какие основные механизмы в Kubernetes используются для управления доступом и изоляции ресурсов?

Ответ

В Kubernetes для управления доступом и изоляции используются несколько ключевых абстракций, работающих на разных уровнях:

Namespaces (Пространства имен)
- Что это: Логическое разделение кластера на изолированные виртуальные среды (например, dev, staging, prod).
- Зачем: Предоставляют область видимости для имен ресурсов (поды, сервисы не могут иметь одинаковые имена в одном namespace) и являются основой для применения политик, таких как RBAC и ResourceQuotas.
RBAC (Role-Based Access Control)
- Что это: Механизм для гранулярной настройки прав доступа пользователей и сервисов к API Kubernetes.
- Компоненты:
  - Role и ClusterRole: Определяют набор разрешений (verbs: get, list, create) на ресурсы (resources: pods, services). Role действует в рамках одного Namespace, а ClusterRole — на уровне всего кластера.
  - RoleBinding и ClusterRoleBinding: Связывают роли (Role/ClusterRole) с субъектами (subjects: User, Group, ServiceAccount).
- Пример Role:
```
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" означает core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
```
ServiceAccounts (Сервисные аккаунты)
- Что это: Учетные записи, предназначенные для процессов, работающих внутри подов, чтобы они могли аутентифицироваться в API-сервере Kubernetes.
NetworkPolicies (Сетевые политики)
- Что это: Правила, управляющие сетевым трафиком между подами на уровне L3/L4. Позволяют реализовать принцип "zero-trust", когда по умолчанию весь трафик запрещен, а разрешается только необходимый.
ResourceQuotas (Квоты на ресурсы)
- Что это: Ограничения на совокупное потребление ресурсов (CPU, память, хранилище) в рамках одного Namespace.
- Зачем: Помогают предотвратить проблему "шумного соседа", когда один проект потребляет все ресурсы кластера.

Эти абстракции в совокупности позволяют создавать безопасные, мульти-tenantные среды.