Какие знаешь абстракции в Kubernetes, которые разделяют доступ к функционалу?

Абстракции Kubernetes для разделения доступа к функционалу

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

Основные абстракции для контроля доступа

1. Namespaces (Пространства имён)

Это фундаментальная абстракция для логического разделения ресурсов в одном кластере. Каждый namespace создаёт виртуальный изолированный контур.

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    environment: prod

• Изоляция ресурсов: Поды, сервисы, конфигурации внутри namespace изолированы от других.
• Квотирование: Возможность установки лимитов на ресурсы (CPU, память) для каждого namespace.
• Сетевые политики: Базовый уровень для разделения сетевого трафика между namespace.

2. RBAC (Role-Based Access Control)

Система управления доступом на основе ролей — ключевой механизм для разделения функционала.

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

Компоненты RBAC:

• Role/ClusterRole: Определяют разрешения в пределах namespace или всего кластера
• RoleBinding/ClusterRoleBinding: Связывают роли с пользователями, группами или ServiceAccounts
• ServiceAccount: Аккаунты для внутрикластерной аутентификации

3. Network Policies

Абстракции для контроля сетевого трафика между ресурсами Kubernetes.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-isolation
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 80

Дополнительные механизмы разделения доступа

4. Resource Quotas

Ограничивают суммарное потребление ресурсов в namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: production
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
    limits.cpu: "4"
    limits.memory: 8Gi
    pods: "10"

5. LimitRanges

Устанавливают ограничения по умолчанию для отдельных ресурсов в namespace:

apiVersion: v1
kind: LimitRange
metadata:
  name: resource-limits
spec:
  limits:
  - default:
      memory: 512Mi
      cpu: 500m
    defaultRequest:
      memory: 256Mi
      cpu: 250m
    type: Container

6. Pod Security Policies/Standards (PSP/PSS)

Хотя PSP устарели в пользу Pod Security Standards, они представляют важную абстракцию для контроля security context подов:

# Пример использования Pod Security Standards через labels
apiVersion: v1
kind: Namespace
metadata:
  name: secure-ns
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: latest

Практические паттерны использования

Многоуровневое разделение доступа:

1. Владелец кластера (ClusterRole: cluster-admin)

   • Полный доступ ко всем ресурсам

2. Разработчик команды (RoleBinding в конкретном namespace)

   # Разработчик может управлять подами только в dev namespace
   - verbs: ["create", "update", "patch", "delete"]
     resources: ["pods", "deployments"]
   

3. CI/CD система (ServiceAccount с ограниченными правами)

   • Автоматическое развертывание только в определённых namespace
   • Ограниченные права на чтение конфигураций

4. Мониторинг (ClusterRole: view)

   • Только чтение метрик и логов
   • Запрет на модификацию ресурсов

Особенности реализации:

• Иерархичность: Абстракции можно комбинировать (namespace + RBAC + NetworkPolicy)
• Декларативность: Все политики описываются YAML-манифестами
• Атомарность: Изменения применяются сразу ко всем ресурсам, соответствующим селекторам
• Аудит: Все операции логируются через Kubernetes Audit Logging

Ключевые принципы эффективного разделения доступа:

1. Принцип наименьших привилей — предоставлять минимально необходимые права
2. Разделение окружений — dev/stage/prod через разные namespace
3. Командная изоляция — каждая команда работает в своём namespace
4. Защита от горизонтального перемещения — ограничение доступа между namespace
5. Регулярный аудит — проверка актуальности RBAC правил

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