Comment RBAC fonctionne-t-il avec les ServiceAccounts, et comment sécurise-t-on un cluster Kubernetes ?

Question

IT Interview Practice · Accepted Answer

Le **RBAC (Role-Based Access Control)** régit *qui peut faire quoi* sur l'API. Les permissions sont accordées à des **sujets** (utilisateurs, groupes, **ServiceAccounts**) en les **liant (binding)** à des **Roles** qui listent les verbes autorisés sur des ressources. Le RBAC est une couche d'une stratégie plus large de durcissement du cluster.

## Le modèle RBAC

```text
SUJET (user / group / ServiceAccount)
   │  lié par
   ▼
RoleBinding ───────► Role         (namespaced : permissions dans UN SEUL namespace)
ClusterRoleBinding ► ClusterRole  (cluster-wide, ou réutilisable entre namespaces)

Role/ClusterRole = un ensemble de RÈGLES : « ces VERBES sur ces RESSOURCES »
Les bindings sont ADDITIFS et il n'y a AUCUN deny — vous n'accordez que le nécessaire.
```

## Exemple de Role + RoleBinding

```yaml
# Un Role : accès en lecture seule aux Pods du 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"]
---
# Lier ce Role à un 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é pour les Pods

```text
Un ServiceAccount est l'IDENTITÉ qu'un Pod utilise pour parler à l'API server.
  → Chaque Pod en obtient un (le SA « default » du namespace si non spécifié).
  → Un token projeté est monté dans le Pod ; le RBAC décide ce que ce token peut faire.
Bonne pratique : donnez à chaque workload son PROPRE SA avec un RBAC least-privilege,
et mettez automountServiceAccountToken: false quand le Pod n'a pas besoin d'accéder à l'API.
```

```yaml
apiVersion: v1
kind: ServiceAccount
metadata: { name: my-app, namespace: app }
automountServiceAccountToken: false   # se désinscrire si aucun appel API n'est nécessaire
---
apiVersion: apps/v1
kind: Deployment
# ...
spec:
  template:
    spec:
      serviceAccountName: my-app       # faire tourner les Pods sous cette identité
```

## Défense en profondeur — au-delà du RBAC

```text
AUTH        → RBAC least-privilege ; ServiceAccounts par workload ; audit des accès
NETWORK     → NetworkPolicies default-deny (les Pods ne peuvent pas parler sauf autorisation)
WORKLOAD    → securityContext : runAsNonRoot, readOnlyRootFilesystem, drop des capabilities
              profils seccomp ; Pod Security Admission (restricted) pour imposer
SECRETS     → chiffrement au repos pour etcd ; gestionnaires de secrets externes ; RBAC serré sur les secrets
IMAGES      → scannez les images, utilisez des registries de confiance, imposez via admission (ex. policy engines)
API/etcd    → restreignez & chiffrez etcd ; TLS partout ; limitez l'accès anonyme & cluster-admin
SUPPLY CHAIN→ images signées, contrôle d'admission (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          # que peut faire l'utilisateur courant ?
```

## Pourquoi c'est important

Sécuriser un cluster est une responsabilité senior, et le RBAC avec les ServiceAccounts en est le fondement, donc comprendre les deux est une connaissance essentielle de sécurité. Le modèle RBAC est élégant et vaut la peine d'être intériorisé : les permissions sont **purement additives, sans deny**, accordées en **liant des sujets** (utilisateurs, groupes et surtout **ServiceAccounts**) à des **Roles** (namespaced) ou des **ClusterRoles** (cluster-wide) qui énumèrent les **verbes autorisés sur des ressources** — ce qui signifie qu'une bonne sécurité vient d'accorder uniquement ce dont chaque workload a besoin (**least privilege**) plutôt que de s'appuyer sur des refus. Comprendre qu'un **ServiceAccount est l'identité qu'un Pod utilise pour appeler l'API** — que chaque Pod obtient un token, que le SA `default` est un piège fréquent de sur-privilège, et que vous devriez donner à chaque workload son propre SA least-privilege (et désactiver l'automount du token quand aucun accès API n'est nécessaire) — est directement pratique et une source fréquente de mauvaise configuration en conditions réelles. Surtout, un ingénieur senior sait que le RBAC n'est qu'une couche d'une **défense en profondeur** : des **NetworkPolicies** default-deny, des réglages de **securityContext** durcis (non-root, système de fichiers racine en lecture seule, capabilities retirées, seccomp), la **Pod Security Admission**, le **chiffrement au repos** et des gestionnaires externes pour les Secrets, le scan et la signature d'images, les controllers d'admission (OPA/Gatekeeper, Kyverno) et un accès etcd/API verrouillé se combinent pour protéger un cluster. Parce qu'un cluster Kubernetes est une cible de grande valeur où un seul ServiceAccount sur-permissionné ou une NetworkPolicy ouverte peut mener à une compromission totale, maîtriser le RBAC et l'outillage de durcissement plus large est fondamental pour exploiter des clusters en toute sécurité en production.

Le modèle RBAC

Exemple de Role + RoleBinding

ServiceAccounts : identité pour les Pods

Défense en profondeur — au-delà du RBAC

Pourquoi c'est important

Questions connexes