Traditional CI/CD automation relies on static API keys or SSH keys stored in environment variables, secrets managers, or source control. This model has compounding security flaws:
OPA Workload Identity shifts the security model from "you have a secret" to "you are cryptographically who you say you are." Workloads prove their identity using signed JWTs issued by their native platform (GitHub Actions, GitLab CI, GCP, CircleCI, or any JWKS-compliant provider). OPA validates the token against a pre-configured trust relationship called a Workload Connection — no secrets are stored anywhere in the pipeline.
No static keys. No Secret Zero. No standing privilege. Every deployment above is proof.
$ACTIONS_ID_TOKEN_REQUEST_URL) and received a signed JWT attesting its runtime context: repository, branch, workflow, SHA, and triggering actor. No stored credential was used. The raw token and its decoded claims are shown in Step 1 above.sft CLI exchanged the GitHub JWT for an OPA access token. The workflow called sft workload authenticate --team farley --connection github-actions-prod --role-hint github_actions --jwt-env GITHUB_OIDC_TOKEN. OPA fetched GitHub's JWKS, verified the JWT signature, validated required claims against the Workload Connection configuration, and issued a short-lived OPA access token to the authenticated Workload Principal. The token's claims are decoded and displayed in Step 2 above.sft ssh --team farley --workload-role github_actions target-server-01. OPA evaluated the security policy attached to the github_actions Workload Role, issued an ephemeral SSH client certificate, and created a JIT Unix account (wl_github_actions) on the target server. The job wrote state.json under that account, then the session closed and the account was torn down. No persistent SSH key was used.pam.user_creds.issue (token issuance, actor type WorkloadPrincipal) and pam.server.ssh_login (SSH session establishment, actor: wl_github_actions). Both events were pulled live via the Okta System Log API using a time-bounded query anchored to the OPA token's iat claim — no manual log search required.https://token.actions.githubusercontent.com/.well-known/jwks), and required JWT claims that must be present for authentication to succeed.sft workload authenticate into the CI/CD pipeline and sets OPA_ADDR. The resulting OPA access token is used for all subsequent sft ssh calls. No secrets are stored — the pipeline is self-contained and auditable from first principles.--role-hint flag on sft workload authenticate pre-selects the intended role at authentication time.wl_ (e.g., wl_github_actions). This visually distinguishes JIT workload accounts from human accounts in audit logs, on the target server, and in any SIEM integration. The account exists only for the duration of the SSH session."No standing credentials" means there is nothing to steal between job runs:
wl_ account on the target server is created at job start and destroyed at job end
Every workload authentication and SSH session generates structured events in the Okta System Log automatically — no custom instrumentation required. This dashboard pulls both events live via the System Log API, anchored to the OPA token's iat claim:
sub claim), Workload Connection name, team, client IP, and token TTL. This is the primary record of authentication.wl_ JIT account (e.g., wl_github_actions). Records the target server, session timestamp, and outcome. Together with pam.user_creds.issue, these two events provide a complete, tamper-evident audit trail from JWT issuance through session close.