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 orgs to use federated, platform-signed identities (JWT/OIDC) or secure API keys 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 sprawl, Okta Privileged Access offers two authentication approaches: * Cloud-hosted workloads: Shifts 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 without storing static credentials on disk. * Non-cloud or on-premise workloads: Okta Privileged Access API key connections enable secure authentication using managed, short-lived secrets with built-in rotation and revocation capabilities controlled by security administrators.
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. For JWT connections, this is a JSON Web Token (JWT) signed by a trusted third-party provider such as GitHub, GitLab, or GCP. For API key connections, this is a cryptographically signed API key managed by Okta. |
|
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. |
|
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 (for JWT connections) or sets up managed API key authentication (for API key connections). For JWT connections, a DevOps admin creates them in Draft status, and a security admin promotes them to Active to enable token issuance. For API key connections, only a security admin creates and manages the connection. Note:
A JWT 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, preventing inadvertent access during testing. API key connections are managed exclusively by security admins with no draft phase. |
|
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 |
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.
For JWT connections: A DevOps admin creates a draft workload connection to define the external provider's JWKS validation source 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.
For API key connections: A security admin creates an API key workload connection in active status (no draft phase required). The admin generates an API key and delivers it to the DevOps team through a secure out-of-band channel. The security admin defines a workload role with attribute-matching conditions and binds it to a policy to set resource 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.
For JWT connections: 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.
For API key connections: At run time, the workload presents its API key and references its workload connection. The system validates the API key and, if successful, issues a short-lived access token. The workload uses this token to request protected resources and specify its role. The policy engine validates the token and checks role requirements. If approved, access is granted and the event is logged.
Topics
CLI command for workload authentication