Jak funguje RBAC se ServiceAccounty a jak zabezpečit Kubernetes cluster?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** řídí, *kdo smí co* na API. Oprávnění se udělují **subjektům** (uživatelé, skupiny, **ServiceAccounty**) tak, že se **navážou (binding)** na **Role**, které vyjmenovávají povolené verby na resources. RBAC je jedna vrstva širší strategie zpevňování clusteru.

## Model RBAC

```text
SUBJECT (uživatel / skupina / ServiceAccount)
   │  navázán přes
   ▼
RoleBinding ───────► Role         (namespacovaná: oprávnění v JEDNOM namespace)
ClusterRoleBinding ► ClusterRole  (celoclusterová nebo znovupoužitelná napříč namespaces)

Role/ClusterRole = sada PRAVIDEL: "tyto VERBY na těchto RESOURCES"
Bindingy jsou ADITIVNÍ a NEexistuje deny — udělujete jen to, co je potřeba.
```

## Příklad Role + RoleBinding

```yaml
# Role: jen pro čtení Podů v 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"]
---
# Naváže tuto Role na 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
```

## ServiceAccounty: identita pro Pody

```text
ServiceAccount je IDENTITA, kterou Pod používá ke komunikaci s API serverem.
  → Každý Pod nějaký dostane (SA "default" v namespace, pokud není určeno jinak).
  → Do Podu se připojí projected token; RBAC rozhoduje, co ten token smí.
Best practice: dejte každému workloadu VLASTNÍ SA s RBAC podle least-privilege
a nastavte automountServiceAccountToken: false, když Pod nepotřebuje přístup k API.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # odhlaste se, pokud nejsou potřeba volání API
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # spouští Pody pod touto identitou
```

## Defense in depth — za hranicí RBAC

```text
AUTH        → RBAC podle least-privilege; ServiceAccounty per workload; audit přístupů
NETWORK     → default-deny NetworkPolicies (Pody spolu nemluví, pokud to není povoleno)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, zahození capabilities
              seccomp profily; Pod Security Admission (restricted) pro vynucení
SECRETS     → šifrování v klidu pro etcd; externí správci secretů; těsné RBAC na secrety
IMAGES      → skenování imagů, důvěryhodné registry, vynucení přes admission (např. policy engines)
API/etcd    → omezit a šifrovat etcd; TLS všude; omezit anonymní a cluster-admin přístup
SUPPLY CHAIN→ podepsané imagy, 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          # co smí aktuální uživatel?
```

## Proč je to důležité

Zabezpečení clusteru je seniorní zodpovědnost a RBAC se ServiceAccounty je jeho základ, takže pochopení obojího je nezbytná bezpečnostní znalost. Model RBAC je elegantní a stojí za zvnitřnění: oprávnění jsou **čistě aditivní bez deny**, udělují se **navázáním subjektů** (uživatelé, skupiny a zejména **ServiceAccounty**) na **Role** (namespacované) nebo **ClusterRole** (celoclusterové), které vyjmenovávají povolené **verby na resources** — což znamená, že dobrá bezpečnost pochází z udělení jen toho, co každý workload potřebuje (**least privilege**), místo spoléhání na zákazy. Pochopení, že **ServiceAccount je identita, kterou Pod používá k volání API** — že každý Pod dostane token, že SA `default` je běžnou pastí nadměrných oprávnění a že byste měli dát každému workloadu vlastní SA podle least-privilege (a vypnout automatické připojení tokenu, když není potřeba přístup k API) — je přímo praktické a častý zdroj chybných konfigurací v praxi. Zásadně, seniorní inženýr ví, že RBAC je jen jedna vrstva **defense in depth**: default-deny **NetworkPolicies**, zpevněná nastavení **securityContext** (non-root, read-only root filesystem, zahozené capabilities, seccomp), **Pod Security Admission**, **šifrování v klidu** a externí správci pro Secrety, skenování a podepisování imagů, admission controllery (OPA/Gatekeeper, Kyverno) a uzamčený přístup k etcd/API se společně kombinují k ochraně clusteru. Protože Kubernetes cluster je vysoce hodnotný cíl, kde jediný nadměrně oprávněný ServiceAccount nebo otevřená NetworkPolicy může vést k plné kompromitaci, zvládnutí RBAC a širší sady nástrojů pro zpevňování je základem pro bezpečný provoz clusterů v produkci.

Model RBAC

Příklad Role + RoleBinding

ServiceAccounty: identita pro Pody

Defense in depth — za hranicí RBAC

Proč je to důležité

Související otázky