See why permanent SSH keys don't belong in your automated build systems — and what replaces them.
What is a Workload Identity?
Just like employees need ID badges to enter the building, your automated build systems need secure digital badges to SSH into your servers. Workload Identity gives each automated process its own verifiable identity — no shared SSH keys required.
Each of these steps is a liability hiding in plain sight.
Developer merges to main. CI/CD pipeline triggers automatically.
The job must SSH into production servers — to push configuration changes, deploy software, or run scheduled security scans. How does it authenticate?
A private key, stored as a CI/CD secret months ago, is loaded into the runner environment.
The key authenticates as a static user (e.g., deploy_user) that lives on the server 24/7.
Commands execute on the server. Connection closes when the job finishes.
The key remains in CI/CD. The service account remains on the server. Attack surface is identical before and after deployment.
“What if every one of those vulnerabilities simply… didn’t exist?”
Every vulnerability from the traditional flow — eliminated step by step.
Same starting point. Developer merges to main, CI/CD pipeline triggers.
Instead of looking up a stored key, the runner requests a signed OIDC token from its platform's built-in identity provider — no secrets involved.
Supported: GitHub Actions, GitLab, CircleCI, Azure, GCP, Kubernetes, or any Generic JWT provider
OPA checks the JWT signature against the platform's public keys (JWKS) and verifies claims: repository, branch, workflow, and commit.
OPA issues a short-lived access token to the verified workload. This token cannot be renewed or extended.
OPA generates a one-time SSH client certificate for this session. No private key is stored on either side.
A temporary wl_ prefixed Unix account is created on the target server for this session only — with dynamically-scoped sudo privileges written specifically for this job, not blanket root access.
Commands execute under the JIT account. Session ends → certificate expires, account is destroyed.
The Fundamental Shift
Traditional security asks “do you have the right secret?”
OPA asks “are you cryptographically who you say you are?”
No secrets to steal. No passwords to leak. Identity proven mathematically through federated OIDC — the same standard that powers “Sign in with Google.”
Starting with SSH machine-to-machine access. Expanding to secrets retrieval and managed passwords.
Internal Only
Reduce breach risk from compromised CI/CD credentials
Eliminate credential management overhead — key rotation, secret sprawl
Compliance-ready audit trails without custom tooling
Accelerate deployment velocity by removing security bottlenecks
Static SSH keys in CI/CD — never rotated, never expire
Permanent service accounts on production servers — always exploitable
Compromised runner = permanent production access
No audit trail connecting builds to server access
Zero stored credentials — nothing to leak in a pipeline breach
JIT accounts exist only during deployment — zero persistent attack surface
Compromised runner yields nothing — tokens already expired
Full visibility via structured Okta System Log events
Only solution that creates AND destroys local Unix accounts per-session (true JIT)
Non-refreshable tokens — stolen credentials cannot be extended
Built-in governance model (Draft → Active promotion by separate admin)
Works with GitHub Actions, GitLab, CircleCI, Azure, GCP, Kubernetes — any JWT-capable platform
Deepest sudo control in market — host agent dynamically writes session-specific sudoers per-user. Not group-based, not pre-provisioned. Competitors rely on static group sudo.
“How do your automated systems authenticate to production servers today?”
“When was the last time your CI/CD SSH keys were rotated?”
“If a runner was compromised right now, how long would an attacker have access?”
“What's your current process for rotating CI/CD credentials?”
“How does your security team audit which automation accesses which servers?”
“What compliance frameworks require you to demonstrate M2M access controls?”
The Bottom Line
Beyond security — real, measurable value for your organization.
Eliminates permanent SSH keys and service accounts. Between deployments, there is literally no account on the server to compromise.
Teams deploy faster because SSH access is granted automatically. No tickets, no key rotation, no manual server configuration.
Pass compliance checks with structured Okta System Log events — token issuance, SSH connections, session durations — all searchable from a single pane of glass.