C’est 2h du mat’. Le dashboard clignote en rouge : 300 alertes qui débarquent en même temps sur le réseau, la base, les applis, la sécu. Le tech de garde passe trois heures à jongler entre six dashboards pour découvrir qu’une règle de pare-feu a foutu le bordel. Un agent IA qui automatise tout ça va tirer des métriques réseau, interroger les logs, checker les bases, croiser les alertes de sécu. Et pour ça, il faut qu’il s’authentifie partout, en live, dans le cluster Kubernetes de prod.
Ce bazar, c’est ni un microservice ni un job batch. Son graphe de dépendances, son empreinte de credentials, son chemin d’exécution, tout est dynamique. InfoQ publie un article qui décrit les patterns d’infrastructure développés pour faire tourner ce genre de bestiole : isolation, containment des secrets, confiance graduée, et observabilité. La conclusion, c’est que les modèles de sécu Kubernetes actuels sont morts.
Pourquoi les agents IA pètent tout
Un microservice classique, on sait quels appels il va faire. On règle les network policies en conséquence, on limite les credentials, on dimensionne les ressources. L’agent IA autonome, lui, décide à l’exécution quelles API appeler. Parfois il va juste causer à un agrégateur de logs, parfois il va enchaîner réseau, métriques, logs, topologie, événements de sécu. Impossible de prévoir, impossible de cloisonner.
Résultat : les hypothèses de base de la sécu Kubernetes
Credentials : le rêve d’un hacker
Un agent qui raisonne sur le réseau, les bases, les applis et la sécu a besoin de creds pour les quatre. Si un seul container se fait compromettre, c’est le jackpot : le gars a accès à tout le périmètre. Les équipes plates-formes déploient un modèle de confiance graduée en quatre phases (shadow, read-only, limited write, autonomous) pour élargir les permissions petit à petit, mais ça reste un pansement.
Observabilité : le cauchemar
Les traces request/response classiques, c’est mort. Le parcours d’un agent est non-déterministe : il émet des hypothèses, les teste, ajuste. Un cycle d’évaluation permanent qu’aucun dashboard standard ne capture. Résultat : on peut pas tracer une panne comme avant. Et devoir débugger un agent qui s’est planté à 2h du mat’ sans savoir quels chemins il a pris, c’est la recette du burn-out.
Le fond du problème
On balance des agents autonomes dans des clusters qui sont déjà des usines à gaz en termes de sécu. Les patterns proposés sont intelligents — isolation via Jobs Kubernetes par exécution, secrets management repensé — mais on applique des rustines. Les agents cassent le modèle, et on recollé les morceaux avec du scotch barbapapa. Le temps que les béhémoths du cloud sortent des solutions natives, on va devoir bricoler. Et comme d’hab’, ce sera les équipes ops qui trinqueront.
Comments are closed