Kif jaħdem l-RBAC mas-ServiceAccounts, u kif tissikura cluster ta' Kubernetes?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** jiggverna *min jista' jagħmel xiex* fuq l-API. Il-permessi jingħataw lil **subjects** (users, groups, **ServiceAccounts**) billi jitrabbtu (**binding**) ma' **Roles** li jelenkaw il-verbs permessi fuq ir-riżorsi. RBAC huwa layer wieħed ta' strateġija usa' ta' tisħiħ tal-cluster.

## Il-mudell RBAC

```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.
```

## Eżempju ta' Role + RoleBinding

```yaml
# Role: aċċess read-only għall-Pods fin-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"]
---
# Orbot dak ir-Role ma' 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: identità għall-Pods

```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   # oħroġ jekk mhux meħtieġ aċċess għall-API
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # ħaddem il-Pods taħt din l-identità
```

## Difiża fil-fond — lil hinn mill-RBAC

```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          # x'jista' jagħmel l-utent kurrenti?
```

## Għaliex huwa importanti

Li tissikura cluster hija responsabbiltà senior, u l-RBAC bis-ServiceAccounts huwa l-pedament tagħha, għalhekk li tifhem it-tnejn huwa għarfien essenzjali tas-security. Il-mudell RBAC huwa eleganti u ta' min jinternalizzah: il-permessi huma **purament additivi mingħajr deny**, mogħtija billi **jorbtu s-subjects** (users, groups, u speċjalment **ServiceAccounts**) ma' **Roles** (namespaced) jew **ClusterRoles** (cluster-wide) li jenumeraw il-**verbs permessi fuq ir-riżorsi** — li jfisser li security tajba tiġi milli tagħti biss dak li jeħtieġ kull workload (**least privilege**) minflok ma toqgħod fuq id-denials. Li tifhem li **ServiceAccount hija l-identità li Pod juża biex isejjaħ l-API** — li kull Pod jieħu token, li s-SA `default` hija nassa komuni ta' over-privilege, u li għandek tagħti lil kull workload SA tiegħu stess b'least-privilege (u tiddiżattiva l-automounting tat-token meta mhux meħtieġ aċċess għall-API) — huwa direttament prattiku u sors frekwenti ta' konfigurazzjoni ħażina fid-dinja reali. B'mod kruċjali, inġinier senior jaf li RBAC huwa biss layer wieħed ta' **difiża fil-fond**: **NetworkPolicies** default-deny, settings ta' **securityContext** imsaħħa (non-root, root filesystem read-only, capabilities imwaqqgħa, seccomp), **Pod Security Admission**, **encryption at rest** u managers esterni għas-Secrets, image scanning u signing, admission controllers (OPA/Gatekeeper, Kyverno), u aċċess magħluq għal etcd/API kollha jingħaqdu biex jipproteġu cluster. Peress li cluster ta' Kubernetes huwa mira ta' valur għoli fejn ServiceAccount wieħed over-permissioned jew NetworkPolicy miftuħa jistgħu jwasslu għal kompromess sħiħ, li tqabbad l-RBAC u l-għodda usa' ta' tisħiħ huwa fundamentali biex topera clusters b'mod sikur fil-produzzjoni.

Il-mudell RBAC

Eżempju ta' Role + RoleBinding

ServiceAccounts: identità għall-Pods

Difiża fil-fond — lil hinn mill-RBAC

Għaliex huwa importanti

Mistoqsijiet relatati