Conas a oibríonn RBAC le ServiceAccounts, agus conas a dhéanann tú cnuasach Kubernetes a dhaingniú?

Question

IT Interview Practice · Accepted Answer

Rialaíonn **RBAC (Role-Based Access Control)** *cé a fhéadann cad a dhéanamh* ar an API. Deonaítear ceadanna do **subjects** (úsáideoirí, grúpaí, **ServiceAccounts**) trí iad a **bhinding** le **Roles** a liostaíonn verbs ceadaithe ar acmhainní. Is sraith amháin é RBAC de straitéis daingnithe cnuasaigh níos leithne.

## An tsamhail 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.
```

## Sampla Role + RoleBinding

```yaml
# Role: rochtain léamh-amháin ar Pods sa 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"]
---
# Bind an Role sin le 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: aitheantas do Pods

```text
Is é ServiceAccount an tAITHEANTAS a úsáideann Pod chun labhairt leis an API server.
  → Faigheann gach Pod ceann (an SA "default" den namespace mura sonraítear).
  → Feistítear token projected isteach sa Phod; cinneann RBAC cad a fhéadann an token sin a dhéanamh.
Dea-chleachtas: tabhair a SA FÉIN le RBAC íos-phribhléide do gach workload,
agus socraigh automountServiceAccountToken: false nuair nach dteastaíonn rochtain API ón bPod.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # roghnaigh amach mura dteastaíonn glaonna API
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # rith Pods faoin aitheantas seo
```

## Cosaint i ndoimhne — thar RBAC

```text
AUTH        → RBAC íos-phribhléide; ServiceAccounts in aghaidh gach workload; iniúchtú rochtain
NETWORK     → NetworkPolicies default-deny (ní féidir le Pods labhairt mura gceadaítear)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, scaoil capabilities
              seccomp profiles; Pod Security Admission (restricted) chun forfheidhmiú
SECRETS     → encryption at rest do etcd; bainisteoirí secret seachtracha; RBAC docht ar secrets
IMAGES      → scan images, úsáid registries iontaofa, forfheidhmigh le admission (m.sh. policy engines)
API/etcd    → srianaigh & criptigh etcd; TLS i ngach áit; teorannaigh rochtain anaithnid & cluster-admin
SUPPLY CHAIN→ images sínithe, 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          # cad is féidir leis an úsáideoir reatha a dhéanamh?
```

## Cén fáth a bhfuil sé tábhachtach

Is freagracht shinsearach é cnuasach a dhaingniú, agus is é RBAC le ServiceAccounts a bhunús, mar sin is eolas slándála riachtanach é an dá cheann a thuiscint. Tá an tsamhail RBAC galánta agus is fiú í a inmheánú: tá ceadanna **breiseach amháin gan diúltú**, deonaithe trí **subjects a bhinding** (úsáideoirí, grúpaí, agus go háirithe **ServiceAccounts**) le **Roles** (namespaced) nó **ClusterRoles** (ar fud an chnuasaigh) a áiríonn na **verbs ceadaithe ar acmhainní** — rud a chiallaíonn go dtagann dea-shlándáil ó chomh amháin a theastaíonn ó gach workload a dheonú (**íos-phribhléid**) seachas a bheith ag brath ar dhiúltuithe. Tá tuiscint gurb é **ServiceAccount an t-aitheantas a úsáideann Pod chun an API a ghlaoch** — go bhfaigheann gach Pod token, gur gaiste ró-phribhléide coitianta é an SA `default`, agus gur cheart duit a SA íos-phribhléide féin a thabhairt do gach workload (agus token automounting a dhíchumasú nuair nach dteastaíonn rochtain API) — praiticiúil go díreach agus foinse mhinic mí-chumraíochta san fhíorshaol. Go ríthábhachtach, tá a fhios ag innealtóir sinsearach nach bhfuil in RBAC ach sraith amháin de **chosaint i ndoimhne**: comhcheanglaíonn **NetworkPolicies** default-deny, socruithe **securityContext** daingnithe (neamh-root, comhadchóras root léamh-amháin, capabilities scaoilte, seccomp), **Pod Security Admission**, **encryption at rest** agus bainisteoirí seachtracha do Secrets, scanadh agus síniú images, admission controllers (OPA/Gatekeeper, Kyverno), agus rochtain etcd/API faoi ghlas — go léir chun cnuasach a chosaint. Toisc gur sprioc ard-luacha é cnuasach Kubernetes ina bhféadfadh aon ServiceAccount ró-cheadaithe nó NetworkPolicy oscailte amháin a bheith ina chúis le comhréiteach iomlán, tá máistreacht ar RBAC agus an bosca uirlisí daingnithe níos leithne bunúsach chun cnuasaigh a oibriú go sábháilte i production.

An tsamhail RBAC

Sampla Role + RoleBinding

ServiceAccounts: aitheantas do Pods

Cosaint i ndoimhne — thar RBAC

Cén fáth a bhfuil sé tábhachtach

Ceisteanna gaolmhara