A long-lived key with unknown scope, sitting in every image.
That's how most teams handle cloud access. Someone needed S3, so they added an access key to an env var — and now that credential lives in every image, across every cluster, with no clear scope and no rotation. ZeusK8s replaces it with short-lived, per-service identity that never touches your images.
Least privilege that’s actually practical.
Cloud access is where security quietly erodes. A service needs to read an S3 bucket, so someone drops an access key into an environment variable, and now a long-lived credential with who-knows-what scope is sitting in an image. Multiply by every service and every cluster.
ZeusK8s wires up proper workload identity instead. On AWS, pods assume IAM roles via IRSA; on GCP, they authenticate as service accounts via Workload Identity. Either way the credentials are short-lived, scoped to that service, and never stored. You configure it next to the service that needs it, not in a separate cloud console.
From zero to running.
Pick the role or service account
In the service’s Identities tab, choose the AWS IAM role or GCP service account it should assume. The permission lives next to the workload.
Zeus wires the trust
It configures the OIDC trust relationship, the ServiceAccount annotations, and the bindings automatically. No manual trust-policy editing.
Pods get short-lived credentials
At runtime the pod receives temporary, scoped credentials from the cloud’s metadata service. No access keys, nothing to rotate or leak.
Audit in one place
See which services hold which cloud permissions across every cluster, instead of reconstructing it from two cloud consoles.
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.
Why not just use access keys?
Long-lived keys leak, over-grant, and never get rotated. Workload identity gives each pod short-lived, scoped credentials with nothing to steal from an image. It’s the model AWS and Google both recommend, made easy here.
Do AWS and GCP work the same way in Zeus?
The mechanics differ (IRSA vs. Workload Identity) but the experience is identical: pick an identity in the service’s Identities tab, and Zeus handles the cloud-specific wiring.
Does this cover Kubernetes RBAC too?
Yes. In-cluster RBAC (ServiceAccounts, Roles, bindings) is configured in a permission matrix on the same service, so cloud and cluster permissions live together.
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.