Workloads
Okta Privileged Access offers a unified identity security fabric that governs non-human identities (NHIs)—such as service accounts and CI/CD runners—with the same rigor as human users. By providing a new alternative to service users and static API keys, Okta Privileged Access workload authentication allows organizations to use federated, platform-signed identities (JWT/OIDC) to prove trust without secret zero risk. This centralized policy layer decouples machine identity from the secrets they consume. It enables a seamless transition from vaulting static credentials to providing just-in-time access to servers, databases, and ephemeral secrets.
To eliminate the risk of secret zero sprawl, Okta Privileged Access shifts workload authentication from static API keys to cryptographic attestation. By establishing workload connections with trusted providers, including CircleCI, GitLab, GitHub Actions, and Google Cloud Platform (GCP), Okta Privileged Access verifies signed JSON web tokens (JWTs) at runtime. Workloads use environment-provided signed tokens to prove identity, authenticating automated requests without storing static credentials on disk.
Key features and concepts
| Feature / Component | Description |
|---|---|
| Workload |
An automated job or machine entity, such as an Ansible controller or CI/CD runner, that requests access to a privileged resource. |
|
Workload identity document |
An identity document presented by the workload to prove its identity. This document is a JSON Web Token (JWT) signed by a trusted third-party provider such as GitHub, GitLab, or GCP. |
|
Workload identity |
A digital identity that enables systems, such as servers, containers, virtual machines, or CI/CD pipelines, to authenticate and get authorization for automated tasks within an organization. |
|
Workload authentication |
The process by which a workload proves its identity using a workload identity document instead of a static API key. |
|
Okta Privileged Access token |
Okta Privileged Access issues a secure, tamper-proof token to the workload after successful authentication. The workload uses this access token to access resources protected by Okta Privileged Access. |
|
Workload connection |
The central configuration defines the trust relationship with an external workload provider. A DevOps admin creates connections in Draft status, and a security admin must promote them to Active to enable token issuance. A workload connection in Draft status allows for JWT validation testing but won't issue functional access tokens for resource access. It also can't match any workload role, which prevents a workload from inadvertently gaining access during testing. |
|
Workload roles |
Critical authorization entities that serve as principals in Okta Privileged Access policies. These roles simplify policy management by mapping workload attributes to logical security groups. |
|
Policy binding for workload principals |
Security admins define policies that use workload roles as principals to protect resources. Policy enforcement relies on detailed attribute information from platform integrations. |
|
Enhanced client tooling |
The Okta Privileged Access client CLI now supports autonomous, non-interactive usage, eliminating the need for human prompts. |
|
Principal SSH Access |
Enables workloads to sign in directly to servers using a system-managed Unix/Linux username (prefixed with wl_) automatically derived from their workload role. This mechanism verifies machine identity to dynamically issue short-lived SSH certificates, allowing for secure, zero standing privilege machine-to-machine connections. See Principal SSH access for automated workloads. |
Workload process for automated access
The Okta Privileged Access workflow for securing automated workloads is structured into two distinct phases: administrative setup and automated execution. This separation ensures that human admins maintain strict oversight and governance while machine identities operate autonomously at runtime.
Administrative setup
The administrative phase focuses on establishing trust and defining the security boundaries for automation. This process requires collaboration between the DevOps and security teams.
A DevOps admin creates a draft workload connection to define the external provider's JWKS URL and validation claims. The admin prepares and tests CLI commands against the draft connection to verify syntax and JWT validation. When the security admin activates the connection, it switches from draft to active, and the DevOps admin loses write access. The connection then issues valid Okta Privileged Access tokens. The security admin defines a workload role with attribute-matching blocks and binds it to a policy to set resource and secret access rules.
Automated execution
This phase details the real-time process that occurs whenever a workload needs access to a privileged resource. After setup, the automated execution phase runs each time the workload requests access.
At run time, the workload authenticates by presenting its JWT and referencing its workload connection. The system validates the JWT and, if successful, issues a short-lived access token to establish the workload's session identity. With the access token, the workload requests a protected resource and specifies its role. The policy engine validates the token and checks role requirements. If approved, it enforces least-privileged access and logs the event. The workload then uses credentials to connect and complete its task.