Une clé longue durée au scope inconnu, assise dans chaque image.
C'est ainsi que la plupart des équipes gèrent l'accès cloud. Quelqu'un avait besoin de S3, donc ils ont ajouté une access key dans une variable d'env — et maintenant ce credential vit dans chaque image, sur chaque cluster, sans scope clair et sans rotation. ZeusK8s le remplace par une identité de courte durée, par service, qui ne touche jamais vos images.
Le least privilege qui est réellement praticable.
L'accès cloud est là où la sécurité s'érode en silence. Un service doit lire un bucket S3, donc quelqu'un dépose une access key dans une variable d'environnement, et maintenant un credential longue durée avec un scope qui-sait-quoi est assis dans une image. Multipliez par chaque service et chaque cluster.
ZeusK8s câble plutôt un vrai workload identity. Sur AWS, les pods assument des rôles IAM via IRSA ; sur GCP, ils s'authentifient comme comptes de service via Workload Identity. Dans les deux cas les credentials sont de courte durée, scopés à ce service, et jamais stockés. Vous le configurez à côté du service qui en a besoin, pas dans une console cloud séparée.
From zero to running.
Choisissez le rôle ou le compte de service
Dans l'onglet Identities du service, choisissez le rôle IAM AWS ou le compte de service GCP qu'il doit assumer. La permission vit à côté du workload.
Zeus câble la confiance
Il configure la relation de confiance OIDC, les annotations ServiceAccount et les bindings automatiquement. Pas d'édition manuelle de trust policy.
Les pods obtiennent des credentials de courte durée
Au runtime le pod reçoit des credentials temporaires, scopés, depuis le service de metadata du cloud. Pas d'access keys, rien à rotater ni à faire fuiter.
Auditez en un seul endroit
Voyez quels services détiennent quelles permissions cloud sur chaque cluster, au lieu de le reconstruire depuis deux consoles cloud.
Built by people who run this in production.
No hand-waving. Here’s what’s actually under the hood: the kind of detail you’d expect from a platform you’re going to trust with production.
Questions you’d actually ask.
Pourquoi ne pas simplement utiliser des access keys ?
Les clés longue durée fuient, sur-accordent, et ne sont jamais rotées. Le workload identity donne à chaque pod des credentials de courte durée, scopés, sans rien à voler dans une image. C'est le modèle que recommandent AWS et Google, rendu facile ici.
AWS et GCP fonctionnent-ils de la même façon dans Zeus ?
Les mécaniques diffèrent (IRSA vs Workload Identity) mais l'expérience est identique : choisissez une identité dans l'onglet Identities du service, et Zeus gère le câblage spécifique au cloud.
Est-ce que ça couvre aussi le RBAC Kubernetes ?
Oui. Le RBAC in-cluster (ServiceAccounts, Roles, bindings) se configure dans une matrice de permissions sur le même service, pour que permissions cloud et cluster vivent ensemble.
Keep exploring.
All features →In-cluster permissions too.
Explore →For credentials that aren’t identities.
Explore →Where IRSA is configured.
Explore →Start running it today.
Spin up your first cluster free, or get a guided tour from our team.