RBAC trop large, secrets en clair : quand votre config expose les modèles du client

Un cluster Kubernetes classique héberge des applications. Un cluster ML, lui, concentre deux trésors que les autres n'ont pas, et c'est ce qui change tout en matière de sécurité.

Le premier, ce sont les modèles eux-mêmes. Un modèle entraîné représente parfois des mois de R&D et des centaines de milliers d'euros de calcul GPU. Stocké dans un model registry (MLflow, un bucket monté via KServe, un PVC), il est exfiltrable comme un simple fichier. Le voler, c'est voler la propriété intellectuelle du client.

Le second, ce sont les données d'entraînement. Très souvent, elles contiennent des données personnelles : historiques clients, images, transactions, dossiers de santé. Elles transitent dans des feature stores, des volumes, des jobs Argo. Une fuite ici n'est plus seulement un incident technique : c'est une violation de données au sens du RGPD.

Le consultant MLOps qui configure les accès à ce cluster manipule donc, sans toujours en avoir conscience, le périmètre de conformité réglementaire de son client. Une erreur de RBAC n'est pas un détail d'admin : c'est potentiellement le point de départ d'une notification CNIL.

La grande majorité des incidents de sécurité sur cluster ML ne vient pas d'attaques sophistiquées, mais de configurations par défaut laissées trop ouvertes. Trois reviennent systématiquement.

1. Le RBAC trop large

Donner le rôle cluster-admin à un ServiceAccount « pour que ça marche », ou monter un token monté automatiquement dans tous les pods, revient à donner les clés du cluster à n'importe quel pod compromis. Un notebook Jupyter exposé devient alors un pivot vers le model registry entier. Le principe du moindre privilège n'est pas une bonne pratique optionnelle : c'est la base attendue d'un professionnel.

2. Les secrets mal gérés

Les Secrets Kubernetes sont encodés en base64, pas chiffrés. Sans chiffrement au repos (encryption at rest) activé sur etcd, ou sans solution externe (External Secrets, Vault, KMS du cloud), une clé d'API ou un identifiant de base de données est lisible en clair par quiconque accède à etcd ou à un backup. C'est l'une des fautes les plus reprochables car la parade est connue et documentée.

3. Les endpoints et dashboards exposés

Un dashboard Kubeflow, une UI Argo, un endpoint KServe ou un Ray dashboard exposés sans authentification ni network policy, c'est une porte ouverte sur Internet. Plusieurs fuites majeures de modèles sont parties d'une simple interface laissée accessible publiquement le temps d'une démo… puis oubliée.

Ces trois fautes ont un point commun redoutable : elles ne déclenchent aucune alerte et ne gênent personne au quotidien. Le cluster fonctionne, les modèles servent, les équipes livrent. La faille reste dormante jusqu'au jour où un attaquant — ou un simple scan automatisé d'Internet — la trouve. C'est précisément cette latence qui les rend dangereuses sur le plan juridique : au moment où le sinistre éclate, votre configuration tourne peut-être depuis des mois, et le lien avec votre intervention initiale est limpide. D'où l'importance, dès la livraison, de durcir ces trois points et de le documenter.

Dès qu'une faille expose des données personnelles, on quitte le terrain purement technique pour entrer dans le droit. Le RGPD impose au client, en tant que responsable de traitement, des obligations strictes.

• Notification à la CNIL sous 72 heures (article 33) dès qu'une violation est susceptible d'engendrer un risque pour les personnes concernées.
• Information des personnes (article 34) si le risque est élevé : un travail de communication lourd et coûteux.
• Sanctions pouvant atteindre 4 % du chiffre d'affaires annuel mondial en cas de manquement caractérisé à l'obligation de sécurité (article 32).

L'article 32 du RGPD impose des mesures de sécurité « adaptées au risque », citant explicitement le chiffrement et la limitation des accès. Un RBAC laxiste ou des secrets en clair sont l'exemple type d'un manquement à cet article.

Le client supporte ces obligations en première ligne. Mais s'il établit que la faille provient d'une faute de votre configuration, il peut se retourner contre vous pour récupérer le coût de la gestion de crise, les sanctions et le préjudice subi. Votre statut de prestataire ne vous met pas à l'abri : il vous place souvent en sous-traitant au sens RGPD, avec des obligations propres de sécurité.

Face à une faille de sécurité dont vous seriez à l'origine, deux garanties se complètent et il faut bien comprendre leur partage des rôles.

La RC Pro couvre votre faute professionnelle : l'erreur de configuration, le mauvais conseil, l'omission. Si le client vous réclame le préjudice causé par une faille issue de votre RBAC, c'est elle qui indemnise les dommages et finance votre défense.

L'assurance Cyber, elle, intervient sur la gestion de l'incident lui-même : frais de notification CNIL, expertise forensic pour déterminer l'étendue de la fuite, communication de crise, et parfois la prise en charge des conséquences directes de la violation. Sur un cluster qui manipule des données personnelles, elle n'est pas un luxe : c'est le complément logique de la RC Pro.

Le découpage à retenir :

Sans option Cyber, vous risquez de devoir absorber des frais de gestion d'incident qui sortent du strict cadre de la responsabilité civile.

Au-delà de l'assurance, ce sont vos pratiques documentées qui démontreront que vous avez agi en professionnel diligent. Voici les points que tout consultant MLOps devrait livrer et tracer.

1. Moindre privilège systématique. Chaque ServiceAccount avec des Roles et RoleBindings au plus juste, jamais de cluster-admin par défaut, automountServiceAccountToken: false quand le token n'est pas nécessaire.
2. Secrets chiffrés et externalisés. Encryption at rest sur etcd, et gestion des secrets via Vault, External Secrets ou le KMS du cloud. Plus aucun secret sensible en clair dans un manifeste versionné.
3. Network policies par défaut deny. Aucun pod ne communique sauf autorisation explicite. Les dashboards et endpoints d'inférence derrière une authentification et jamais exposés publiquement.
4. Cartographie des données personnelles. Identifiez avec le client quels jobs et volumes touchent des données RGPD, et isolez-les. C'est aussi une exigence de l'article 32.
5. Documentez vos recommandations refusées. Si le client refuse une mesure de sécurité (pour des raisons de coût ou de délai), faites-le écrire. Cette trace transfère la responsabilité du risque vers lui.

Une configuration sécurisée, documentée, adossée à une RC Pro avec option Cyber : c'est la posture qui vous évite de transformer une mission technique en contentieux RGPD. Vous trouverez le détail des garanties pensées pour votre activité sur notre page consultant MLOps Kubernetes.

Un réflexe complémentaire mérite d'être souligné : le scan de sécurité automatisé. Intégrer dans la chaîne CI/CD du client des outils d'analyse des manifestes (politiques OPA/Gatekeeper, scanners d'images, vérification des RBAC) transforme la sécurité d'un audit ponctuel en garde-fou permanent. C'est aussi, sur le plan assurantiel, la preuve que vous avez livré un dispositif de prévention, et non une simple configuration figée que le client dégrade ensuite sans contrôle.