Πώς λειτουργεί το RBAC με τα ServiceAccounts, και πώς ασφαλίζεις ένα cluster Kubernetes;

Question

IT Interview Practice · Accepted Answer

Το **RBAC (Role-Based Access Control)** διέπει το *ποιος μπορεί να κάνει τι* στο API. Τα δικαιώματα χορηγούνται σε **subjects** (users, groups, **ServiceAccounts**) με **binding** τους σε **Roles** που απαριθμούν τα επιτρεπόμενα verbs σε resources. Το RBAC είναι ένα επίπεδο μιας ευρύτερης στρατηγικής hardening του cluster.

## Το μοντέλο 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
# A Role: read-only access to Pods in the "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"]
---
# Bind that Role to a 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: ταυτότητα για τα 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   # opt out αν δεν χρειάζονται API calls
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # τρέξε τα Pods υπό αυτή την ταυτότητα
```

## Άμυνα σε βάθος — πέρα από το 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          # τι μπορεί να κάνει ο τρέχων χρήστης;
```

## Γιατί έχει σημασία

Η ασφάλιση ενός cluster είναι ευθύνη senior, και το RBAC με ServiceAccounts είναι το θεμέλιό της, οπότε η κατανόηση και των δύο είναι απαραίτητη γνώση ασφαλείας. Το μοντέλο RBAC είναι κομψό και αξίζει να το εσωτερικεύσεις: τα δικαιώματα είναι **καθαρά αθροιστικά χωρίς deny**, χορηγούμενα με **binding subjects** (users, groups, και ιδίως **ServiceAccounts**) σε **Roles** (namespaced) ή **ClusterRoles** (cluster-wide) που απαριθμούν επιτρεπόμενα **verbs σε resources** — που σημαίνει ότι η καλή ασφάλεια προέρχεται από τη χορήγηση μόνο ό,τι χρειάζεται κάθε workload (**least privilege**) αντί να στηρίζεται σε αρνήσεις. Το να καταλαβαίνεις ότι ένα **ServiceAccount είναι η ταυτότητα που χρησιμοποιεί ένα Pod για να καλέσει το API** — ότι κάθε Pod παίρνει ένα token, ότι το `default` SA είναι μια συχνή παγίδα υπερβολικών δικαιωμάτων, και ότι πρέπει να δίνεις σε κάθε workload το δικό του least-privilege SA (και να απενεργοποιείς το automounting του token όταν δεν χρειάζεται πρόσβαση στο API) — είναι άμεσα πρακτικό και συχνή πηγή ρεαλιστικών κακορυθμίσεων. Κρίσιμα, ένας senior μηχανικός ξέρει ότι το RBAC είναι μόνο ένα επίπεδο της **άμυνας σε βάθος**: default-deny **NetworkPolicies**, σκληρυμένες ρυθμίσεις **securityContext** (non-root, read-only root filesystem, dropped capabilities, seccomp), **Pod Security Admission**, **encryption at rest** και εξωτερικοί managers για τα Secrets, σάρωση και υπογραφή images, admission controllers (OPA/Gatekeeper, Kyverno), και κλειδωμένη πρόσβαση etcd/API συνδυάζονται όλα για να προστατεύσουν ένα cluster. Επειδή ένα cluster Kubernetes είναι στόχος υψηλής αξίας όπου ένα μόνο υπερ-προνομιούχο ServiceAccount ή ένα ανοιχτό NetworkPolicy μπορεί να οδηγήσει σε πλήρη παραβίαση, η κατάκτηση του RBAC και της ευρύτερης εργαλειοθήκης hardening είναι θεμελιώδης για τη λειτουργία clusters με ασφάλεια στο production.

Το μοντέλο RBAC

Παράδειγμα Role + RoleBinding

ServiceAccounts: ταυτότητα για τα Pods

Άμυνα σε βάθος — πέρα από το RBAC

Γιατί έχει σημασία

Σχετικές ερωτήσεις