Miten RBAC toimii ServiceAccountien kanssa, ja miten turvaat Kubernetes-klusterin?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** hallitsee *kuka voi tehdä mitä* API:ssa. Oikeudet myönnetään **subjekteille** (käyttäjät, ryhmät, **ServiceAccountit**) **sitomalla** ne **Roleihin**, jotka listaavat sallitut verbit resursseihin. RBAC on yksi kerros laajemmassa klusterin kovennusstrategiassa.

## RBAC-malli

```text
SUBJECT (user / group / ServiceAccount)
   │  bound by
   ▼
RoleBinding ───────► Role         (namespaced: permissions within ONE namespace)
ClusterRoleBinding ► ClusterRole  (cluster-wide, or reusable across namespaces)

Role/ClusterRole = a set of RULES: "these VERBS on these RESOURCES"
Bindings are ADDITIVE and there is NO deny — you grant only what's needed.
```

## Role + RoleBinding -esimerkki

```yaml
# Role: vain-luku-pääsy Podeihin "app"-namespacessa
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# Sido tuo Role ServiceAccountiin
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
```

## ServiceAccountit: identiteetti Podeille

```text
A ServiceAccount is the IDENTITY a Pod uses to talk to the API server.
  → Every Pod gets one (the namespace "default" SA if unspecified).
  → A projected token is mounted into the Pod; RBAC decides what that token can do.
Best practice: give each workload its OWN SA with least-privilege RBAC,
and set automountServiceAccountToken: false when the Pod doesn't need API access.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # jätä pois jos API-kutsuja ei tarvita
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # aja Podit tällä identiteetillä
```

## Puolustus syvyyssuunnassa — RBAC:n tuolla puolen

```text
AUTH        → least-privilege RBAC; per-workload ServiceAccounts; audit access
NETWORK     → default-deny NetworkPolicies (Pods can't talk unless allowed)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities
              seccomp profiles; Pod Security Admission (restricted) to enforce
SECRETS     → encryption at rest for etcd; external secret managers; tight RBAC on secrets
IMAGES      → scan images, use trusted registries, enforce with admission (e.g. policy engines)
API/etcd    → restrict & encrypt etcd; TLS everywhere; limit anonymous & cluster-admin access
SUPPLY CHAIN→ signed images, 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          # mitä nykyinen käyttäjä voi tehdä?
```

## Miksi se on tärkeää

Klusterin turvaaminen on senior-vastuu, ja RBAC ServiceAccountien kanssa on sen perusta, joten molempien ymmärtäminen on olennaista tietoturvatietoa. RBAC-malli on tyylikäs ja sisäistämisen arvoinen: oikeudet ovat **puhtaasti additiivisia ilman kieltoa**, myönnettyinä **sitomalla subjekteja** (käyttäjät, ryhmät ja erityisesti **ServiceAccountit**) **Roleihin** (namespace-kohtaiset) tai **ClusterRoleihin** (klusterinlaajuiset), jotka luettelevat sallitut **verbit resursseihin** — mikä tarkoittaa, että hyvä turvallisuus syntyy myöntämällä vain sen mitä kukin työkuorma tarvitsee (**vähimmän oikeuden periaate**) sen sijaan että nojattaisiin kieltoihin. Sen ymmärtäminen, että **ServiceAccount on identiteetti, jota Pod käyttää API:n kutsumiseen** — että jokainen Pod saa tokenin, että `default`-SA on yleinen ylioikeutusansa, ja että kullekin työkuormalle tulisi antaa oma vähimmän oikeuden SA (ja poistaa tokenin automaattinen liittäminen kun API-pääsyä ei tarvita) — on suoraan käytännöllistä ja usein toistuva todellisen väärinkonfiguroinnin lähde. Kriittisesti senior-insinööri tietää, että RBAC on vain yksi kerros **puolustusta syvyyssuunnassa**: default-deny-**NetworkPolicyt**, kovennetut **securityContext**-asetukset (non-root, vain-luku-juuritiedostojärjestelmä, pudotetut capabilityt, seccomp), **Pod Security Admission**, **encryption at rest** ja ulkoiset managerit Secreteille, kuvien skannaus ja allekirjoitus, admission controllerit (OPA/Gatekeeper, Kyverno) ja lukittu etcd/API-pääsy yhdistyvät kaikki suojatakseen klusterin. Koska Kubernetes-klusteri on arvokas kohde, jossa yksi ylioikeutettu ServiceAccount tai avoin NetworkPolicy voi johtaa täyteen kompromissiin, RBAC:n ja laajemman kovennustyökalupakin hallinta on perustavaa klustereiden turvalliselle operoinnille tuotannossa.

RBAC-malli

Role + RoleBinding -esimerkki

ServiceAccountit: identiteetti Podeille

Puolustus syvyyssuunnassa — RBAC:n tuolla puolen

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset