RBAC trop large : la faille d'architecture qui engage votre responsabilité

Dans la course au delivery, le RBAC (Role-Based Access Control) est souvent la première victime. On distribue un cluster-admin « le temps de débloquer », on monte un ServiceAccount avec des droits larges « pour que le CI passe », on laisse un Role avec un wildcard verbs: ["*"]. Chaque raccourci paraît anodin. Mis bout à bout, ils dessinent une surface d'attaque béante.

Le problème est structurel : Kubernetes ne vous force pas au moindre privilège. Un ServiceAccount surprivilégié monté dans un pod exposé devient, en cas de compromission applicative, un tremplin vers l'API server, puis vers les secrets, puis vers les identités cloud sous-jacentes (IRSA sur EKS, Workload Identity sur GKE). De la faille applicative à la prise de contrôle du compte cloud du client, il n'y a parfois que trois sauts.

Pour l'architecte, le RBAC n'est pas un détail d'exploitation : c'est un livrable d'architecture. Et un livrable engage celui qui le conçoit.

Par défaut, les Secrets Kubernetes ne sont pas chiffrés : ils sont simplement encodés en base64 et stockés dans etcd. Quiconque accède à etcd ou dispose des droits de lecture sur les secrets lit en clair les mots de passe de base de données, les clés d'API, les tokens cloud.

Un architecte qui livre une plateforme sans chiffrement au repos d'etcd (EncryptionConfiguration), sans gestion externalisée des secrets (Vault, External Secrets Operator, KMS cloud), et sans RBAC restreignant la lecture des secrets, prend une décision lourde de conséquences. Le jour où un attaquant accède au cluster, il ne trouve pas une porte fermée mais un trousseau de clés posé sur la table.

Encoder en base64 n'est pas chiffrer. C'est l'une des confusions les plus dangereuses du débutant Kubernetes — et l'une des plus scrutées en cas de litige.

Le bon réflexe d'architecture : secrets externalisés, chiffrement etcd activé, RBAC en lecture seule strictement nominatif, et rotation automatisée. Chacun de ces choix doit figurer dans votre dossier d'architecture.

Tout incident de sécurité n'engage pas l'architecte. La responsabilité se cristallise quand trois conditions se réunissent : une faute (un choix s'écartant des règles de l'art, comme un cluster-admin distribué sans justification), un préjudice (compromission, exfiltration, paralysie), et un lien de causalité entre les deux.

L'architecte est tenu à une obligation de moyens renforcée par son expertise : plus vous êtes présenté comme le spécialiste sécurité K8s, plus le standard attendu est élevé. Le juge confrontera vos choix aux référentiels reconnus :

• Les CIS Benchmarks Kubernetes, référence de durcissement.
• Les Pod Security Standards et le principe de moindre privilège.
• Les bonnes pratiques OWASP et NSA/CISA sur le hardening de cluster.

Si vous avez recommandé par écrit le durcissement RBAC, le chiffrement des secrets, l'usage d'OPA Gatekeeper — et que le client a refusé pour des raisons de budget ou de planning — la responsabilité bascule vers lui. À l'inverse, un livrable silencieux sur la sécurité vous expose pleinement. Une RC Pro couvre alors votre défense et le préjudice immatériel.

Une compromission de cluster qui expose des données personnelles ne se gère pas que sur le plan technique. Le RGPD impose un cadre strict, et l'architecte est souvent en première ligne pour aider le client (responsable de traitement) à l'honorer :

1. Notification à la CNIL sous 72 heures après la prise de connaissance de la violation, si elle présente un risque pour les personnes.
2. Information des personnes concernées en cas de risque élevé (exfiltration de données sensibles).
3. Documentation de la violation dans le registre interne, même si elle n'est pas notifiée.

Ces obligations ont un coût réel : investigation forensic pour qualifier l'étendue de la fuite, frais juridiques, communication de crise, parfois sanctions CNIL. C'est exactement ce que prend en charge une assurance Cyber : coûts d'investigation, accompagnement à la notification, gestion de crise et indemnisation. Pour un architecte intervenant sur de la production critique, coupler RC Pro et option Cyber n'est pas un luxe, c'est la cohérence du risque réellement porté.

Face à une réclamation post-compromission, ce qui vous protège n'est pas votre talent technique mais votre traçabilité. Constituez systématiquement, pour chaque mission, un dossier qui montre que vous avez agi dans les règles de l'art :

• Le schéma RBAC documenté, avec justification du moindre privilège par rôle.
• La politique de gestion des secrets (externalisation, chiffrement etcd, rotation).
• Les policies de sécurité appliquées (Pod Security, OPA Gatekeeper, Network Policies).
• Le rapport de conformité CIS Benchmark au moment de la livraison.
• Les recommandations refusées par le client, datées et tracées par écrit.

Ce dossier transforme un débat d'experts en un constat factuel. Combiné à une RC Pro avec option Cyber, il vous permet d'aborder un incident — toujours stressant — sans que votre activité ne soit en jeu.