Principal SSH access for automated workloads
The Principal SSH Access feature of Okta Privileged Access allows automated workloads, such as CI/CD runners or automation scripts, to establish SSH connections to servers in the same way as human users. Okta Privileged Access provisions server users for these workloads and manages their sessions.
Automated server user provisioning
When you create a workload role in Okta Privileged Access, the platform automatically assigns a specific Unix or Linux username for that workload to use when signing into a server. The server username is based on the name of the workload role, with the prefix wl_. For example, creating a workload role named builder automatically results in the username wl_builder. This username is managed by the platform and can't be edited by admins, which ensures consistent naming across your environment.
If a security admin renames a workload role, the corresponding server username is updated automatically. For example, renaming the role from builder to app-deployer changes the username from wl_builder to wl_app-deployer, mirroring how username changes are handled for human users. These users are provisioned Just-In-Time and admins should look for the wl_ prefix when checking local server logs.
Shared access identity
Workload roles act as logical groupings for automated tasks. Multiple different workloads, such as containers in a Kubernetes cluster or separate CI/CD jobs, can use the same workload role. In this case, any workload using a particular role logs in to the target server as the same wl_ username associated with that role. This approach allows several workloads to access a server at the same time using the same role, without causing conflicts.
Security and session lifecycle
Workload access is protected by the same real-time security engine that governs human access. Okta Privileged Access continuously evaluates access policies for all active connections. If a workload role is removed from an access policy while a workload is connected to a server, Okta Privileged Access immediately enforces the change by terminating the active SSH session and disconnecting the workload from the server.