RBAC hufanyaje kazi na ServiceAccounts, na unalindaje cluster ya Kubernetes?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** hutawala *nani anaweza kufanya nini* kwenye API. Ruhusa hutolewa kwa **subjects** (users, groups, **ServiceAccounts**) kwa ku-**bind** na **Roles** zinazoorodhesha verbs zinazoruhusiwa kwenye resources. RBAC ni tabaka moja la mkakati mpana wa cluster-hardening.

## Modeli ya RBAC

```text
SUBJECT (user / group / ServiceAccount)
   │  imefungwa na
   ▼
RoleBinding ───────► Role         (namespaced: ruhusa ndani ya namespace MOJA)
ClusterRoleBinding ► ClusterRole  (cluster-wide, au inayotumika tena kwenye namespaces)

Role/ClusterRole = seti ya RULES: "hizi VERBS kwenye hizi RESOURCES"
Bindings ni ZA KUONGEZA na HAKUNA deny — hutoa tu kinachohitajika.
```

## Mfano wa Role + RoleBinding

```yaml
# Role: ufikiaji wa read-only kwa Pods kwenye namespace ya "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"]
---
# Funga Role hiyo kwa 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
```

## ServiceAccounts: utambulisho kwa Pods

```text
ServiceAccount ni UTAMBULISHO ambao Pod hutumia kuongea na API server.
  → Kila Pod hupata moja (SA ya namespace "default" ikiwa haijabainishwa).
  → Token iliyoprojectiwa huwekwa ndani ya Pod; RBAC huamua token hiyo inaweza kufanya nini.
Tabia bora: mpe kila workload SA YAKE yenye RBAC ya least-privilege,
na weka automountServiceAccountToken: false wakati Pod haihitaji ufikiaji wa API.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # jitoe ikiwa hakuna simu za API zinazohitajika
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # endesha Pods chini ya utambulisho huu
```

## Defense in depth — zaidi ya RBAC

```text
AUTH        → RBAC ya least-privilege; ServiceAccounts kwa kila workload; kagua ufikiaji
NETWORK     → NetworkPolicies za default-deny (Pods haziwezi kuongea isipokuwa zimeruhusiwa)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, angusha capabilities
              seccomp profiles; Pod Security Admission (restricted) kutekeleza
SECRETS     → encryption at rest kwa etcd; external secret managers; RBAC kali kwa secrets
IMAGES      → chunguza images, tumia registries za kuaminika, tekeleza kwa admission (mfano policy engines)
API/etcd    → zuia na fanya encrypt etcd; TLS kila mahali; punguza anonymous na cluster-admin access
SUPPLY CHAIN→ images zilizosainiwa, 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          # mtumiaji wa sasa anaweza kufanya nini?
```

## Kwa nini ni muhimu

Kulinda cluster ni jukumu la ngazi ya juu, na RBAC na ServiceAccounts ni msingi wake, hivyo kuelewa vyote viwili ni maarifa muhimu ya usalama. Modeli ya RBAC ni ya kifahari na inafaa kuifahamu ndani: ruhusa ni **za kuongeza tu bila deny**, zinazotolewa kwa ku-**bind subjects** (users, groups, na hasa **ServiceAccounts**) na **Roles** (namespaced) au **ClusterRoles** (cluster-wide) zinazoorodhesha **verbs zinazoruhusiwa kwenye resources** — ambayo humaanisha usalama mzuri hutoka kwa kutoa tu kile kila workload inahitaji (**least privilege**) badala ya kutegemea denials. Kuelewa kwamba **ServiceAccount ni utambulisho ambao Pod hutumia kuita API** — kwamba kila Pod hupata token, kwamba SA ya `default` ni mtego wa kawaida wa ruhusa kupita kiasi, na kwamba unapaswa kumpa kila workload SA yake ya least-privilege (na kuzima automounting ya token wakati hakuna ufikiaji wa API unaohitajika) — ni jambo la kivitendo moja kwa moja na chanzo cha mara kwa mara cha usanidi mbaya wa ulimwengu halisi. Muhimu, mhandisi wa ngazi ya juu hujua RBAC ni tabaka moja tu la **defense in depth**: NetworkPolicies za default-deny, mipangilio ya **securityContext** iliyoimarishwa (non-root, read-only root filesystem, capabilities zilizoangushwa, seccomp), **Pod Security Admission**, **encryption at rest** na external managers kwa Secrets, uchunguzaji na usainiaji wa images, admission controllers (OPA/Gatekeeper, Kyverno), na ufikiaji uliofungwa wa etcd/API vyote huungana kulinda cluster. Kwa kuwa cluster ya Kubernetes ni shabaha ya thamani kubwa ambapo ServiceAccount moja yenye ruhusa kupita kiasi au NetworkPolicy iliyo wazi inaweza kusababisha uvunjaji kamili, kumudu RBAC na zana pana za hardening ni msingi wa kuendesha clusters kwa usalama kwenye production.

Modeli ya RBAC

Mfano wa Role + RoleBinding

ServiceAccounts: utambulisho kwa Pods

Defense in depth — zaidi ya RBAC

Kwa nini ni muhimu

Maswali yanayohusiana