როგორ მუშაობს RBAC ServiceAccount-ებთან და როგორ დაიცავთ Kubernetes-ის კლასტერს?

Question

IT Interview Practice · Accepted Answer

**RBAC (Role-Based Access Control)** არეგულირებს, *ვის რა შეუძლია* API-ზე. ნებართვები ენიჭება **სუბიექტებს** (მომხმარებლები, ჯგუფები, **ServiceAccount-ები**) **Role-ებთან მიბმით (binding)**, რომლებიც ჩამოთვლიან რესურსებზე დაშვებულ verb-ებს. RBAC უფრო ფართო კლასტერის გამკვრივების სტრატეგიის ერთი ფენაა.

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

## Role + RoleBinding მაგალითი

```yaml
# Role: read-only წვდომა Pod-ებზე "app" namespace-ში
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# ამ Role-ის მიბმა 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
```

## ServiceAccount-ები: იდენტობა Pod-ებისთვის

```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   # უარი, თუ API გამოძახებები არ სჭირდება
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # Pod-ების გაშვება ამ იდენტობით
```

## თავდაცვა სიღრმეში — 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          # რა შეუძლია მიმდინარე მომხმარებელს?
```

## რატომ არის ეს მნიშვნელოვანი

კლასტერის დაცვა senior-ის პასუხისმგებლობაა, ხოლო RBAC ServiceAccount-ებთან ერთად მისი საფუძველია, ამიტომ ორივეს გაგება არსებითი უსაფრთხოების ცოდნაა. RBAC მოდელი ელეგანტურია და ღირს მისი გათავისება: ნებართვები **წმინდად დამატებადია, deny-ს გარეშე**, ენიჭება **სუბიექტების** (მომხმარებლების, ჯგუფებისა და განსაკუთრებით **ServiceAccount-ების**) **Role-ებთან (namespaced) ან ClusterRole-ებთან (მთელ კლასტერზე) მიბმით**, რომლებიც ჩამოთვლიან რესურსებზე დაშვებულ **verb-ებს** — რაც ნიშნავს, რომ კარგი უსაფრთხოება მოდის მხოლოდ იმის მინიჭებით, რაც თითოეულ workload-ს სჭირდება (**least privilege**), და არა უარყოფებზე დაყრდნობით. იმის გაგება, რომ **ServiceAccount არის იდენტობა, რომელსაც Pod იყენებს API-ს გამოსაძახებლად** — რომ თითო Pod token-ს იღებს, რომ `default` SA გავრცელებული ზედმეტი-პრივილეგიის ხაფანგია და რომ თითოეულ workload-ს საკუთარი least-privilege SA უნდა მისცეთ (და token-ის ავტომატური მიმაგრება გამორთოთ, როცა API წვდომა არ სჭირდება) — პირდაპირ პრაქტიკულია და რეალურ სამყაროში არასწორი კონფიგურაციის ხშირი წყაროა. კრიტიკულად, senior ინჟინერმა იცის, რომ RBAC **თავდაცვა სიღრმეში**-ს მხოლოდ ერთი ფენაა: default-deny **NetworkPolicy-ები**, გამკვრივებული **securityContext** პარამეტრები (non-root, read-only root ფაილური სისტემა, გაუქმებული capability-ები, seccomp), **Pod Security Admission**, **encryption at rest** და გარე manager-ები Secret-ებისთვის, image-ების სკანირება და ხელმოწერა, admission controller-ები (OPA/Gatekeeper, Kyverno) და ჩაკეტილი etcd/API წვდომა — ყველა ერთად კლასტერს იცავს. რადგან Kubernetes-ის კლასტერი მაღალღირებულებიანი სამიზნეა, სადაც ერთმა ზედმეტად-პრივილეგირებულმა ServiceAccount-მა ან ღიად დარჩენილმა NetworkPolicy-მ შეიძლება სრულ კომპრომეტირებამდე მიგვიყვანოს, RBAC-ისა და უფრო ფართო გამკვრივების ხელსაწყოთა ნაკრების დაუფლება ფუნდამენტურია კლასტერების production-ში უსაფრთხოდ ოპერირებისთვის.

RBAC მოდელი

Role + RoleBinding მაგალითი

ServiceAccount-ები: იდენტობა Pod-ებისთვის

თავდაცვა სიღრმეში — RBAC-ის მიღმა

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები