Des access keys cuites dans les images. Des rôles sur-permissionnés. L'audit les trouvera avant vous.
La plupart des problèmes de sécurité Kubernetes ne sont pas exotiques — c'est une clé longue durée qui devait être temporaire, un rôle avec des permissions que personne n'a restreintes, et une network policy qui n'a jamais été écrite. Zeus corrige les defaults pour que vous ne découvriez pas ça pendant un incident ou un audit.
Chaque service obtient sa propre identité. Pas de clés statiques.
L'approche standard, c'est une access key longue durée dans l'image, ou un rôle partagé que chaque service utilise parce que les scoper individuellement est trop de travail. Les deux vont bien jusqu'à ce que ce ne soit plus le cas — une clé mal rotée, une breach qui pivote sur tout parce que le blast radius était le compte entier.
Zeus câble le workload identity pour chaque service : les pods assument des rôles IAM sur AWS via IRSA, ou s'authentifient comme comptes de service GCP via Workload Identity. Les credentials sont de courte durée, rotés automatiquement, et scopés exactement à ce dont le service a besoin. Rien n'est cuit dans l'image. Rien à rotater manuellement.
Vous choisissez le rôle dans l'onglet Identities du service. Zeus câble la relation de confiance et les annotations automatiquement. Le tout est visible sur chaque cluster en un seul endroit — pas reconstruit depuis deux consoles cloud.
Les contrôles qui comptent, câblés par défaut.
RBAC least-privilege, visuellement
Définissez ServiceAccounts, Roles et bindings dans une matrice de permissions au lieu d'écrire du YAML qu'il faudrait un outil séparé pour auditer. Voyez qui peut faire quoi d'un coup d'œil.
Frontières réseau dures par défaut
Chaque cluster et site est isolé par défaut. Rien ne se connecte tant que vous ne l'autorisez explicitement. Chaque autorisation est unidirectionnelle, optionnellement limitée en ports, et révocable en un clic. La carte montrée est exactement ce qui est appliqué.
Durcissement des pods out of the box
Exécution non-root, filesystem root en lecture seule, capabilities droppées : le security context fait partie de la définition de service, pas d'une réflexion après coup après un finding.
Scan d'images avant déploiement
Les images buildées atterrissent dans Harbor et sont scannées par Trivy automatiquement. Une image non scannée ou en échec ne peut pas être promue en production — le gate est dans le pipeline, pas un check manuel.
Taguez un cluster HIPAA. Zeus active les contrôles.
La plupart du travail de conformité est la même checklist à chaque fois : chiffrement au repos, réseau deny-by-default, journalisation d'audit, rotation des clés, contrôles d'accès. Zeus transforme cette checklist en un tag de cluster. Les contrôles s'activent automatiquement — vous obtenez une piste de preuves, pas un projet d'implémentation manuelle.
Chiffrement au repos et en transit, journalisation d'accès, isolation réseau et rotation des clés — activés quand vous taguez le cluster.
Réseau deny-by-default, pistes d'audit, scan d'images et durcissement des pods appliqués de façon cohérente sur les clusters in-scope.
Journalisation d'audit, contrôles d'accès, segmentation réseau et export de preuves pour votre auditeur — sans construire vous-même la collecte de preuves.
Les presets de conformité sont disponibles sur le plan Enterprise. Ils configurent les contrôles — votre auditeur revoit toujours la sortie, c'est le but.
Un store chiffré pour chaque credential.
Explorer →Contrôle d'accès inter-clusters deny-by-default.
Explorer →Gardez votre config dans votre propre réseau.
Explorer →Trouvez les écarts avant que l'audit ne le fasse.
Voyez comment Zeus câble l'identité cloud, le RBAC et les contrôles de conformité dans une démo live.