OpenKruise Agents v0.6.0 ajoute des contrôles de sécurité et de coûts pour les sandboxes

Le projet OpenKruise Agents de la Cloud Native Computing Foundation a publié la version 0.6.0, apportant des améliorations significatives en matière de sécurité, de gestion du cycle de vie et d'efficacité des coûts pour les charges de travail des agents IA. Publiée le 3 novembre 2026, cette mise à jour se concentre sur le renforcement des environnements sandbox et l'automatisation de l'utilisation des ressources pour les équipes exécutant des agents à grande échelle sur Kubernetes.

Ce qui s'est passé

OpenKruise Agents est un sous-projet d'OpenKruise qui gère le cycle de vie complet des Agent Sandboxes. Depuis la précédente version majeure, v0.3.0, le projet a fusionné 283 pull requests et accueilli 27 nouveaux contributeurs. La version 0.6.0 fait évoluer l'architecture d'une simple couche de charge de travail vers un système doté de son propre plan de données dédié, ajoutant deux nouveaux composants principaux : le traffic-control-plane et le traffic-proxy. Ce changement structurel permet une inspection plus approfondie du trafic réseau et un contrôle plus granulaire du comportement des sandboxes sans dépendre d'extensions externes.

Cette version répond à trois dimensions de valeur principales pour les équipes de plateforme et les ingénieurs IA : le durcissement de la sécurité, les capacités opérationnelles et l'optimisation des coûts. En intégrant l'inspection du trafic et la distribution des politiques dans des composants de premier ordre, le système peut désormais appliquer des règles réseau strictes, gérer les identifiants de manière sécurisée et mettre automatiquement en pause les sandboxes inactives pour économiser des ressources. La mise à jour étend également le nombre de Custom Resource Definitions (CRD) de six à douze, introduisant de nouveaux objets comme PoolAutoscaler et TrafficPolicy pour prendre en charge ces fonctionnalités avancées.

Comment ça fonctionne

La nouvelle architecture divise l'application des règles réseau en deux étapes pour équilibrer performance et sécurité. Le filtrage L4 côté nœud s'effectue dans le pod via le nouveau sidecar traffic-proxy, bloquant les destinations non autorisées avec une faible latence avant que le trafic ne quitte le nœud. L'inspection approfondie L4 centralisée se produit au niveau de la passerelle egress, où l'Egress Policy Enforcer applique des règles complexes, vérifie les listes blanches d'outils du Model Context Protocol et injecte les identifiants. Cela garantit que les clés API sensibles sont résolues côté proxy depuis les Kubernetes Secrets et pivotées sans redémarrer la sandbox, les gardant ainsi hors du code de l'agent.

L'optimisation des coûts est assurée par des mécanismes automatiques de pause et de reprise. Le système utilise des sondes pour détecter les sandboxes inactives et les met en pause pour arrêter la consommation CPU. Lorsqu'une tâche programmée approche ou qu'une nouvelle demande arrive, la sandbox se réveille automatiquement. La passerelle ingress gère le wake-on-traffic, ce qui signifie que la première demande authentifiée déclenche le processus de reprise. Si une sonde échoue ou expire, le système privilégie la sécurité en ne mettant ni en pause ni en réveil l'instance, évitant ainsi toute perte de données accidentelle ou interruption de service.

Détails clés

• Sécurité réseau : Implémente le filtrage par liste blanche L4, l'inspection des requêtes L7 et les listes de contrôle d'accès au niveau outil MCP avec des jetons JWT rotatifs à courte durée de vie.
• Gestion des identifiants : Résout les clés API amont depuis les Kubernetes Secrets au niveau du proxy, permettant leur rotation sans redémarrage de la sandbox.
• Opérations de cycle de vie : Prend en charge CheckpointRestore pour préserver le rootfs lors des mises à niveau et permet la mise à niveau par lots des flottes en pause sans intervention manuelle.
• Mise à l'échelle : Introduit PoolAutoscaler pour une capacité de pool chaud déclarative avec des seuils et des plans de mise à l'échelle basés sur cron.
• Détection d'inactivité : Utilise une logique pilotée par sondes pour mettre en pause les sandboxes inactives et les réveiller selon un planning ou à la première demande, réduisant les coûts de calcul inutiles.
• Croissance communautaire : Cette version inclut les contributions de 27 nouveaux développeurs et double le nombre de CRD gérées, passant à douze.

Pourquoi c'est important

Pour les équipes d'ingénierie développant des produits IA, la gestion des environnements sandbox implique souvent un compromis entre sécurité et commodité. Les versions précédentes nécessitaient des outils externes ou des processus manuels pour gérer les politiques réseau et l'injection d'identifiants, ce qui pouvait entraîner des failles de sécurité ou une surcharge opérationnelle. En intégrant directement ces contrôles dans le plan de données, la v0.6.0 permet aux équipes de plateforme d'appliquer des politiques egress strictes et de gérer les identités de manière centralisée. Cela réduit le risque de fuite d'identifiants et garantit que les agents n'accèdent qu'aux services approuvés, une exigence critique pour les déploiements en entreprise.

L'efficacité des coûts est une autre préoccupation majeure lors de l'exécution de grandes flottes de sandboxes d'agents. Les instances inactives consomment des ressources même lorsqu'elles ne traitent pas activement de tâches. Les nouvelles fonctionnalités automatiques de pause et de reprise, combinées à la mise à l'échelle déclarative des pools, permettent aux équipes d'ajuster dynamiquement leur infrastructure. Les sandboxes peuvent réduire leur taille pendant les heures creuses et se réveiller juste avant les tâches programmées, garantissant que les dépenses de calcul correspondent étroitement à l'utilisation réelle. Cette maturité opérationnelle rend viable l'exécution de charges de travail d'agents en production sans factures d'infrastructure prohibitives.

Ce que vous pouvez faire

• Passez à OpenKruise Agents v0.6.0 depuis GitHub Releases ou les principaux registres d'images pour accéder aux nouvelles fonctionnalités de sécurité et de mise à l'échelle.
• Définissez les ressources TrafficPolicy et SecurityProfile pour mettre en liste blanche des destinations spécifiques et appliquer des règles réseau L4/L7 à vos sandboxes.
• Configurez PoolAutoscaler avec des plans cron pour ajuster automatiquement la capacité du pool chaud en fonction des pics d'utilisation prévus.
• Activez la pause et la reprise automatiques en définissant des politiques de cycle de vie pour mettre en pause en cas de timeout et reprendre automatiquement en cas de trafic ou de planification.
• Migrez la gestion des identifiants pour utiliser les Kubernetes Secrets avec résolution côté proxy afin d'éviter d'intégrer les clés API dans le code de l'agent.
• Rejoignez la réunion communautaire le jeudi à 19:30 GMT+8 ou ouvrez des issues sur GitHub pour contribuer aux éléments de roadmap à venir.