Okta Privileged Access gateways

You can use Okta Privileged Access gateways both as standalone replacements for SSH bastion servers and with standard SSH bastions. Okta Privileged Access gateways are also used for SSH session capture. See Session recording for more information on SSH session capture.

Okta Privileged Access gateways offer increased availability and improved security.

High availability

Gateways offer several mechanisms to guarantee high availability, allowing them to function as bastion hosts without the risk of a single point of failure. In addition to standard load balancing, gateways provide various mechanisms to ensure that access to your servers is always on. These mechanisms include built-in status checks and automatic load balancing when multiple gateways are enrolled with the same labels. See Okta Privileged Access gateway high availability.

Security

Okta Privileged Access gateways are more secure than SSH bastions through their design, which includes:

Zero Trust

Standard SSH connections use some type of secret credentials (such as passwords, keys, or certificates) to connect to servers. While these credentials may only be valid for a short time, a compromised client or edge device can give an attacker direct access to a target server.

When using Okta Privileged Access gateways for your SSH connections, the client never receives any credentials that it can use on its own to directly SSH to a server. Instead, the client receives an encrypted payload that's forwarded to the gateway, which only the gateway can decrypt. The advantages of this approach include:

  • A compromised client device never gives an attacker access to any credentials that can be used to directly SSH to the target server.
  • Since access must pass through a gateway, it's easier to monitor access attempts using an intrusion detection system (IDS) or other monitoring tools.

Logical access management

Maintaining proper access control can be challenging, even when using SSH bastions. It's important to keep a record of user access permissions and maintain a record of which bastions can access which servers. The complexity increases when different bastions have varying security requirements based on the servers they can access.

Okta Privileged Access gateways reduce this complexity using labels. Labels determine which gateways are used to route connections to servers on a project. You can use labels to slice gateways by cloud region, compliance certification, operating system, or any key-value pair that you choose. Provided the labels and label selectors you use on a project are accurate, you can be confident that the gateway used to access a target server meets your requirements.

For example, consider a data locality requirement that dictates that data must never leave a particular country's borders. In a legacy bastion environment, you need to audit all the target servers and bastion servers to ensure that the only possible access to the server is through a bastion server located within the country. When you use gateways, you can label the gateways with their operating region (for example, their AWS region). Instead of needing to audit individual servers, you add the region as a gateway selector to the project whose servers require such an access restriction.

Gateways can be powerful tools that you can use to meet compliance requirements, especially when used with Okta Privileged Access groups to manage users.

Native Identity Provider (IdP) integration

While SSH is a fantastic protocol for securing access to servers, it was designed before the advent of a federated Identity Provider. This resulted in its authorization scheme being centered on machine identity rather than human identity. SSH deals with users on servers, keys, and certificates, rather than organizations, company divisions, and human roles.

This leaves SSH bastions vulnerable to forms of side-channel attacks. Suppose that a user with sufficient access can modify the configuration of a bastion or target server. In that case, they can access target servers to bypass your Identity Provider. For example, imagine a scenario where a user with admin access to a server modifies its sshd configuration and installs their public key for unlogged access.

Gateways address this problem by being deeply entwined with Okta Privileged Access, rather than being a generic protocol like SSH. To pass through a gateway, users must have run the Okta Privileged Access client and be authenticated by Okta. This guarantees that all access to your servers behind gateways is protected by Okta.

Topics

Task Description
Install the Okta Privileged Access gateway Install the Okta Privileged Access gateway
Create tokens and labels

Connect the gateway to a team

Configure the Okta Privileged Access gateway Control the operation of the gateway
Optional. Session recording Configure session recording on your gateway