Okta Privileged Access gateway high availability

Gateways use various techniques to ensure high availability, which provides more reliability than traditional SSH bastions:

Gateway load balancing

For projects with multiple gateways, Okta Privileged Access routes traffic through a single gateway randomly selected when a client connects to a server. This allows Okta Privileged Access to balance requests across any available gateways.

If a specific gateway becomes unavailable, Okta Privileged Access may continue to route requests to the gateway for up to five minutes. During this time, all requests fail. After five minutes, Okta Privileged Access removes the gateway from the pool and begins routing connections to other available gateways.

To ensure that requests are handled properly, you should configure gateway load balancing similar to how you'd configure a web application server behind a load balancer. This generally involves the following tasks:

  • Ensure that clients can connect to the load balancer (port 7234 by default).
  • Ensure that the load balancer can connect to gateways (port 7234 by default).
  • Ensure that gateways can connect to your target servers (port 22 by default).
  • Configure every gateway to use the same AccessAddress. This must match the domain name or static IP used to access the load balancer.

Different ports are treated as different addresses for clients to connect to and validate the identity of a gateway. Host certificates for multiple gateways are considered valid if they share a default address. This is detected using cloud instance metadata for servers hosted on Amazon Web Services or Google Cloud Provider.

After configuring gateways behind a load balancer, Okta recommends adding other health checks to remove gateways from the pool after they become unhealthy or unreachable.

  • Ensure that gateways are listening on the correct port (7234 by default).
  • Ensure that gateways have sufficient space to store logs.
  • Ensure that gateway CPU and memory usage is operating normally.

For more information on implementing health checks for your platform and tools, see your cloud provider or load balancer's documentation.

Gateway status checks

Gateways automatically report health status to Okta Privileged Access every two minutes. This status is used to provide valuable insights that can help control traffic routing when users attempt to connect to a server.

If Okta Privileged Access doesn't receive a status from a specific gateway for more than five minutes, the gateway is removed from the pool and connections are sent to other available gateways. Similarly, if Okta Privileged Access doesn't receive a status report from any gateways for five minutes, connections are sent to the gateway that most recently reported. However, if Okta Privileged Access doesn't receive a status report from any gateways for 24 hours, all attempts to connect will fail and you may need to perform other configuration or troubleshooting.

You can find the most recent health data by viewing the gateway details from the Okta Privileged Access dashboard.

Configure a temporary gateway bypass

In the unlikely event that every gateway is inaccessible, you can configure access to servers that bypass gateways but still allow for restricted and audited connections:

  1. Create a temporary Okta Privileged Access group containing only users who need temporary access.
  2. Identify the project where the server is enrolled and remove every group.
  3. Add the temporary group to the project.

The new group is synchronized to servers. This process may take several minutes, after which time members of the temporary group can access the server. After the incident is resolved, you must manually restore the original groups.

Session capture isn't possible for connections that bypass the gateway. However, user and connection time information is still recorded to the Okta Privileged Access audit log.

Troubleshoot a gateway

Teams can troubleshoot gateways by installing the Okta Privileged Access server agent and enrolling the gateway in a project that doesn't require a gateway. Provided the server is active and accessible, users who belong to the associated project can connect to the gateway through SSH.

Related topics

Install the Okta Privileged Access gateway

Projects