Как работает RBAC с ServiceAccount, и как защитить кластер Kubernetes?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** управляет тем, *кто что может делать* с API. Разрешения выдаются **субъектам** (пользователям, группам, **ServiceAccount**) путём **привязки (binding)** их к **Role**, которые перечисляют разрешённые глаголы (verbs) над ресурсами. RBAC — один слой более широкой стратегии укрепления кластера.

## Модель RBAC

```text
SUBJECT (user / group / ServiceAccount)
   │  привязан через
   ▼
RoleBinding ───────► Role         (в namespace: разрешения внутри ОДНОГО namespace)
ClusterRoleBinding ► ClusterRole  (на весь кластер или переиспользуемо между namespace)

Role/ClusterRole = набор ПРАВИЛ: "эти VERBS над этими RESOURCES"
Привязки АДДИТИВНЫ, и запрета (deny) НЕТ — вы выдаёте только необходимое.
```

## Пример Role + RoleBinding

```yaml
# Role: доступ только на чтение к Pod в namespace "app"
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# Привязать эту Role к ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app
  name: read-pods
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: app
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```

## ServiceAccount: идентичность для Pod

```text
ServiceAccount — это ИДЕНТИЧНОСТЬ, которую Pod использует для общения с API server.
  → Каждый Pod получает одну (SA "default" в namespace, если не указано иное).
  → В Pod монтируется проецируемый токен; RBAC решает, что этот токен может делать.
Лучшая практика: давать каждой нагрузке СВОЮ SA с RBAC по принципу минимальных привилегий,
и ставить automountServiceAccountToken: false, когда Pod не нужен доступ к API.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # отказаться, если вызовы API не нужны
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # запускать Pod под этой идентичностью
```

## Эшелонированная защита — за пределами RBAC

```text
AUTH        → RBAC по минимальным привилегиям; ServiceAccount на каждую нагрузку; аудит доступа
NETWORK     → default-deny NetworkPolicies (Pod не общаются, пока не разрешено)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities
              seccomp профили; Pod Security Admission (restricted) для принуждения
SECRETS     → шифрование at rest для etcd; внешние менеджеры секретов; строгий RBAC на секреты
IMAGES      → сканирование образов, доверенные registries, принуждение через admission (напр. policy engines)
API/etcd    → ограничить и шифровать etcd; TLS везде; ограничить анонимный и cluster-admin доступ
SUPPLY CHAIN→ подписанные образы, admission control (OPA/Gatekeeper, Kyverno)
```

```bash
kubectl auth can-i list pods --as=system:serviceaccount:app:my-app -n app
kubectl auth can-i --list -n app          # что может текущий пользователь?
```

## Почему это важно

Защита кластера — ответственность уровня senior, а RBAC с ServiceAccount — её фундамент, поэтому понимание обоих — существенное знание о безопасности. Модель RBAC элегантна и стоит того, чтобы её усвоить: разрешения **чисто аддитивны, без запретов (deny)**, выдаются путём **привязки субъектов** (пользователей, групп и особенно **ServiceAccount**) к **Role** (в namespace) или **ClusterRole** (на весь кластер), которые перечисляют разрешённые **глаголы над ресурсами** — а значит, хорошая безопасность достигается выдачей только того, что нужно каждой нагрузке (**минимальные привилегии**), а не опорой на запреты. Понимание того, что **ServiceAccount — это идентичность, которую Pod использует для вызова API** — что каждый Pod получает токен, что SA `default` — распространённая ловушка избыточных привилегий, и что каждой нагрузке следует давать свою SA с минимальными привилегиями (и отключать автомонтирование токена, когда доступ к API не нужен) — напрямую практично и частый источник реальных ошибок конфигурации. Критически, senior-инженер знает, что RBAC — лишь один слой **эшелонированной защиты**: default-deny **NetworkPolicies**, укреплённые настройки **securityContext** (не root, read-only корневая файловая система, сброшенные capabilities, seccomp), **Pod Security Admission**, **шифрование at rest** и внешние менеджеры для Secret, сканирование и подпись образов, admission-контроллеры (OPA/Gatekeeper, Kyverno) и заблокированный доступ к etcd/API — всё вместе защищает кластер. Поскольку кластер Kubernetes — высокоценная цель, где единственная перепривилегированная ServiceAccount или открытая NetworkPolicy может привести к полной компрометации, овладение RBAC и более широким набором инструментов укрепления фундаментально для безопасной эксплуатации кластеров в production.

Модель RBAC

Пример Role + RoleBinding

ServiceAccount: идентичность для Pod

Эшелонированная защита — за пределами RBAC

Почему это важно

Похожие вопросы