Most cloud platforms that need access to your infrastructure start with the same onboarding step: paste in a service account key. Or an access key and secret. Or a JSON blob you downloaded from the console and definitely should not be emailing to yourself.
You paste it in. The platform stores it. You hope they encrypted it. You hope they rotate it. You hope nobody on their team can read it. You move on with your day and try not to think about it.
We built Zero — b0gy's platform for engineering truth — around a different premise. For cloud infrastructure access — GCP and AWS — we don't store credentials at all. The platform connects to your projects and accounts using short-lived, federated identity tokens that are minted on demand and expire in minutes. There is nothing to leak because there is nothing stored.
Not every integration can work this way. GitHub, Slack, and Jira use OAuth, which means we do hold tokens for those services. But for the highest-risk connections — the ones with read access to your entire cloud infrastructure — keyless was a hard requirement.
This is the first post in a three-part series about building Zero. We're starting here because the connector model shaped everything else.
Why stored secrets are the wrong default
The argument for storing a service account key is convenience. You paste it once, the platform can access your cloud whenever it needs to. Simple.
The argument against it is longer.
A stored secret is a liability that compounds over time. The moment you paste a GCP service account key into a third-party platform, you've created a credential that is valid indefinitely, scoped to whatever permissions you granted, and stored in a system you don't control. If that platform gets breached — or if an employee with database access gets curious — that key works until someone revokes it. And nobody revokes it, because nobody remembers it exists.
This isn't theoretical. The GitGuardian 2026 report found 28.65 million hardcoded secrets pushed to GitHub in 2025. A 34% year-over-year increase. Most of those secrets were valid at the time of detection. The problem isn't that teams are careless — it's that long-lived credentials are inherently fragile. They work silently until they don't, and the failure mode is a breach.
We wanted Zero to be a platform that teams connect to their infrastructure without adding to their attack surface. That meant no stored secrets. Which meant we needed a different model entirely.
How keyless connectors actually work
The mechanism is federated identity — specifically, Workload Identity Federation on GCP and OIDC-based AssumeRoleWithWebIdentity on AWS. The core idea is the same for both clouds: instead of giving Zero a key, you tell your cloud to trust Zero's identity.
Here's the flow for GCP:
Zero runs its own OIDC issuer. It publishes a JWKS (JSON Web Key Set) endpoint — a standard discovery URL that says "here are the public keys you can use to verify tokens I've signed."
When you connect a GCP project, you create a Workload Identity Pool in your project that trusts our OIDC issuer. You add an attribute condition that scopes it to your specific Zero organization —
attribute.workspace == "org:YOUR_ORG_ID".When Zero needs to read your resources, it mints a short-lived JWT, signed with its private key, containing your org ID as a claim. It presents that token to GCP's Security Token Service, which verifies the signature against our published JWKS, checks the attribute condition, and — if everything matches — issues a short-lived GCP access token scoped to the roles you granted.
Zero uses that access token to read your resources. The token expires in minutes. There is no refresh token. The next time Zero needs access, it goes through the same flow.
AWS works the same way, just with different terminology. Instead of a Workload Identity Pool, you create an IAM role with a trust policy that references our OIDC issuer and your org ID. Instead of STS token exchange, it's AssumeRoleWithWebIdentity. The result is identical: a short-lived credential, scoped to your account, with no stored secret on our side.
# The trust boundary, simplified:
Your cloud ──trusts──▶ Zero's OIDC issuer
│
▼
Token minted per-request
Contains: org ID, timestamp, expiry
Signed: RS256
Lifetime: minutes
Stored: nowhere
The per-org scoping matters. The attribute condition on the Workload Identity Pool means that even if Zero minted a token for a different organization, your cloud would reject it. One tenant can never read another's projects — not because of application-level query filters, but because the cloud itself enforces the boundary.
What this costs us
Keyless isn't free. It's cheaper in security terms, but it costs more in engineering complexity and onboarding friction.
Setup is harder. A service account key is one step: download and paste. Keyless federation requires creating a Workload Identity Pool (GCP) or an IAM role with OIDC trust (AWS), which means either clicking through the cloud console or running Terraform. We've built setup wizards — step-by-step guides with copyable commands, Terraform snippets, and even a one-shot LLM prompt that generates the right config for your environment. It's better than it was. It's still not "paste a key."
Token exchange adds latency. Every cloud operation starts with a token exchange round-trip. For a sync that reads thousands of resources, this is negligible — the exchange happens once at the start. But it's there. We pay a few hundred milliseconds per sync cycle that a stored-key approach wouldn't.
Error surfaces are wider. When a stored key stops working, the error is "invalid credentials." When federated identity fails, the error could be an expired OIDC token, a misconfigured attribute condition, a Workload Identity Pool that references the wrong issuer, or an IAM role with the wrong trust policy. We've invested heavily in diagnostic error messages that tell you exactly which part of the chain broke.
We accepted these costs because the alternative — storing your cloud keys — creates a liability that only grows with time and scale. The setup friction is a one-time cost. The security benefit compounds.
The pattern behind the decision
This wasn't an abstract security principle. It came from watching what happens when platforms store secrets.
Teams connect a cloud account during onboarding. The service account key gets the broadest permissions because the person setting it up wants it to work, not to be minimal. Six months later, nobody remembers what permissions that key has. Twelve months later, the person who set it up has left the company. The key is still valid. The platform still uses it nightly. Nobody can tell you what it can do.
We've seen this in advisory engagements. The audit question "what third-party services have access to your cloud, and with what permissions?" produces a silence that lasts longer than it should. The answer is usually "we don't know." Not because the team is negligent — because stored secrets are invisible by design. They work quietly until they become a problem.
Keyless federation inverts this — at least for the cloud connections where it matters most. The trust relationship is visible in your cloud's IAM configuration. You can see exactly which external identity is trusted, with what scope, and revoke it by deleting a single resource. There's no key to rotate because there's no key. There's no secret sprawl because there's no secret.
For connectors where keyless isn't an option today — GitHub Apps, Slack, Jira — we use standard OAuth flows with encrypted token storage. The attack surface is smaller (scoped OAuth tokens, not full cloud admin keys), but we'd prefer keyless everywhere. As more platforms adopt OIDC federation, we'll move to it. The architecture is ready.
The heuristic
If your platform stores cloud credentials, you're trusting a third party to protect a secret that never expires, never audits itself, and works silently until someone misuses it. Federated identity removes the secret entirely — your cloud verifies the caller on every request and you can cut access from one place.
tl;dr
The pattern. Most platforms store your cloud credentials — long-lived secrets that compound in risk and resist audit at scale.
The fix. Use federated identity wherever the protocol supports it — Workload Identity Federation on GCP, OIDC-based role assumption on AWS — so the platform never holds a secret for your highest-risk connections.
The outcome. For cloud infrastructure access, there is nothing to leak, nothing to rotate, and the entire trust relationship is visible in your IAM config — one resource to revoke if you ever walk away.
This is part 1 of a three-part series on building Zero. Next, we'll get into how the platform started — a tool called Landed that answered one question: is the commit you deployed actually the commit that's running.
Originally published at b0gy.com