Yaya RBAC ke aiki da ServiceAccounts, kuma yaya kake tabbatar da tsaron cluster na Kubernetes?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** yana shiryar da *wa zai iya yin me* a kan API. Ana ba da izini ga **subjects** (users, groups, **ServiceAccounts**) ta hanyar **binding** su zuwa **Roles** waɗanda ke jera verbs da aka ba da izini a kan resources. RBAC layer ɗaya ne na dabarar tsauta cluster mai faɗi.

## Tsarin RBAC

```text
SUBJECT (user / group / ServiceAccount)
   │  an ɗaure ta
   ▼
RoleBinding ───────► Role         (na namespace: izini cikin namespace ƊAYA)
ClusterRoleBinding ► ClusterRole  (fadin cluster, ko mai sake amfani a fadin namespaces)

Role/ClusterRole = tarin DOKOKI: "waɗannan VERBS a kan waɗannan RESOURCES"
Bindings suna KARƁUWA kuma babu deny — kana ba da abin da ake buƙata kawai.
```

## Misalin Role + RoleBinding

```yaml
# Role: damar read-only zuwa Pods a 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"]
---
# Ɗaure wannan Role zuwa 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: tantancewa ga Pods

```text
ServiceAccount shine TANTANCEWA da Pod ke amfani da ita don magana da API server.
  → Kowane Pod yana samun ɗaya (SA na namespace "default" idan ba a ƙayyade ba).
  → Ana ɗora token da aka tsara cikin Pod; RBAC yana yanke abin da wannan token zai iya yi.
Mafi kyawun aiki: ba kowane workload NASA SA da RBAC na ƙaramin-izini,
kuma saita automountServiceAccountToken: false lokacin da Pod ba ya buƙatar damar API.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # ficewa idan ba a buƙatar kiran API
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # gudanar da Pod ƙarƙashin wannan tantancewa
```

## Defense in depth — fiye da RBAC

```text
AUTH        → RBAC na ƙaramin-izini; ServiceAccounts ga kowane workload; audit damar shiga
NETWORK     → NetworkPolicies na default-deny (Pod ba za su iya magana sai an bari)
WORKLOAD    → securityContext: runAsNonRoot, readOnlyRootFilesystem, drop capabilities
              seccomp profiles; Pod Security Admission (restricted) don tilastawa
SECRETS     → encryption at rest ga etcd; managers na secret na waje; RBAC matsattse a kan secrets
IMAGES      → scan images, yi amfani da registries masu aminci, tilasta da admission (misali policy engines)
API/etcd    → ƙuntata & ɓoye etcd; TLS ko'ina; iyakance damar anonymous & cluster-admin
SUPPLY CHAIN→ images da aka sa hannu, 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          # me mai amfani na yanzu zai iya yi?
```

## Me ya sa yake da muhimmanci

Tabbatar da tsaron cluster alhakin senior ne, kuma RBAC da ServiceAccounts shine tushensa, don haka fahimtar dukansu ilimin tsaro ne mai mahimmanci. Tsarin RBAC yana da kyakkyawa kuma ya cancanci fahimta: izini suna **karɓuwa kawai ba tare da deny ba**, ana ba da su ta hanyar **binding subjects** (users, groups, kuma musamman **ServiceAccounts**) zuwa **Roles** (na namespace) ko **ClusterRoles** (fadin cluster) waɗanda ke lissafta verbs da aka ba da izini a kan resources — wanda ke nufin kyakkyawan tsaro ya fito daga ba da abin da kowane workload ke buƙata kawai (**ƙaramin izini**) maimakon dogara ga hane-hane. Fahimtar cewa **ServiceAccount shine tantancewa da Pod ke amfani don kiran API** — cewa kowane Pod yana samun token, cewa `default` SA tarko ne na yawan-izini na yau da kullum, kuma cewa ya kamata ka ba kowane workload nasa SA na ƙaramin-izini (kuma kashe automounting na token lokacin da ba a buƙatar damar API ba) — mai amfani ne kai tsaye kuma tushen saita ba daidai ba na ainihin duniya na yawaita. Mafi muhimmanci, injiniya na senior ya san RBAC layer ɗaya ne kawai na **defense in depth**: NetworkPolicies na default-deny, saitunan **securityContext** masu ƙarfi (non-root, read-only root filesystem, capabilities da aka jefar, seccomp), **Pod Security Admission**, **encryption at rest** da managers na waje ga Secrets, scanning da sa hannun image, admission controllers (OPA/Gatekeeper, Kyverno), da damar etcd/API da aka kulle duk suna haɗuwa don kare cluster. Saboda cluster na Kubernetes maƙasudi ne mai daraja inda ServiceAccount guda mai wuce-izini ko NetworkPolicy a buɗe zai iya kaiwa ga cikakkiyar lalacewa, ƙware RBAC da faɗin kayan aikin tsauta na tushe ne don gudanar da clusters cikin aminci a production.

Tsarin RBAC

Misalin Role + RoleBinding

ServiceAccounts: tantancewa ga Pods

Defense in depth — fiye da RBAC

Me ya sa yake da muhimmanci

Tambayoyi masu alaƙa