Ein langlebiger Key mit unbekanntem Scope — in jedem Image.
So handhaben die meisten Teams Cloud-Zugriff. Jemand brauchte S3, also kam ein Access Key in eine Env Var — und jetzt lebt dieses Credential in jedem Image, über jeden Cluster, ohne klaren Scope und ohne Rotation. ZeusK8s ersetzt es durch kurzlebige, per-Service Identity, die Ihre Images nie berührt.
Least Privilege, das tatsächlich praktikabel ist.
Cloud-Zugriff ist der Ort, an dem Security still erodiert. Ein Service muss einen S3 Bucket lesen, also droppt jemand einen Access Key in eine Environment Variable — und jetzt sitzt ein langlebiges Credential mit who-knows-what Scope in einem Image. Multiplizieren Sie das mit jedem Service und jedem Cluster.
ZeusK8s verdrahtet stattdessen proper Workload Identity. Auf AWS übernehmen Pods IAM-Rollen via IRSA; auf GCP authentifizieren sie sich als Service Accounts via Workload Identity. In beiden Fällen sind Credentials kurzlebig, scoped auf diesen Service und nie gespeichert. Sie konfigurieren es neben dem Service, der es braucht — nicht in einer separaten Cloud Console.
From zero to running.
Rolle oder Service Account wählen
Im Identities-Tab des Service die AWS-IAM-Rolle oder den GCP Service Account wählen, den er übernehmen soll. Die Permission lebt neben dem Workload.
Zeus verdrahtet den Trust
Es konfiguriert OIDC Trust Relationship, ServiceAccount Annotations und Bindings automatisch. Kein manuelles Trust-Policy-Editing.
Pods bekommen kurzlebige Credentials
Zur Runtime erhält der Pod temporäre, scoped Credentials vom Metadata Service der Cloud. Keine Access Keys, nichts zu rotieren oder zu leaken.
An einem Ort auditieren
Sehen, welche Services welche Cloud-Permissions über jeden Cluster halten — statt es aus zwei Cloud-Consoles zu rekonstruieren.
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.
Warum nicht einfach Access Keys?
Langlebige Keys leaken, übergranten und werden nie rotiert. Workload Identity gibt jedem Pod kurzlebige, scoped Credentials — nichts aus einem Image zu stehlen. Es ist das Modell, das AWS und Google beide empfehlen, hier easy gemacht.
Funktionieren AWS und GCP in Zeus gleich?
Die Mechanics unterscheiden sich (IRSA vs. Workload Identity), aber die Experience ist identisch: Identity im Identities-Tab des Service wählen, und Zeus handhabt das cloud-spezifische Wiring.
Deckt das auch Kubernetes RBAC ab?
Ja. In-Cluster RBAC (ServiceAccounts, Roles, Bindings) wird in einer Permission-Matrix auf demselben Service konfiguriert — Cloud- und Cluster-Permissions leben zusammen.
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.