Open Policy Agent (OPA) SSH Access Proxy

Efficient security practices are essential when giving SSH access across teams. This is where Open Policy Agent (OPA) comes into play. OPA can act as a policy engine to help you enforce fine-grained access controls, particularly in complex, multi-user systems. Pairing OPA with an SSH access proxy can simplify enforcement and provide better auditing while maintaining security across your infrastructure.

In this article, we’ll cover how you can use OPA as an SSH access proxy, how it enhances security, and the steps to implement it. You'll leave with a clear understanding of how to get started—and see results in just minutes.

What is OPA and Why Use It for SSH Access?

OPA is an open-source, general-purpose policy engine that lets you define and enforce authorization policies via Rego—a declarative language purpose-built for expressing access policies.

When you integrate OPA as an SSH access proxy, it acts as a decision-maker for each attempted SSH connection. You define policies that determine conditions for SSH access, such as:

• Who can SSH into a specific machine.
• When SSH access is permitted.
• Contextual checks, like originating IP addresses or MFA status.

This approach centralizes your access logic, eliminates hardcoding rules, and creates a single place for policy updates.

Benefits of Integrating OPA with an SSH Proxy

1. Centralized Policy Control
   Instead of managing SSH access files (.ssh/authorized_keys) across individual servers, all decisions can be deferred to a centralized OPA service. Updates to access policies propagate in real-time, reducing the administrative burden.
2. Granular, Context-Aware Policies
   Rego enables highly specific and contextual policies. For example, you can enforce rules like, “Only team members from a specific department can access staging servers during business hours.”
3. Better Auditing and Compliance
   Every access decision passes through OPA, creating detailed logs of who attempted access, when, and why they were granted or denied. This level of auditing simplifies compliance reporting.
4. Reduced Risk Surface
   No need to scatter SSH credentials over multiple systems. Access is managed dynamically through OPA, reducing the risk of leaked credentials.

How to Set Up OPA as an SSH Proxy

Getting OPA to work as an SSH proxy requires integrating it with a transport layer, like sshd_config on Linux, and configuring OPA policies appropriately.

Step 1: Configure OPA Policies

Start with classic access policies written in Rego. For example:

package ssh.access

default allow = false

allow {
 input.user == "alice"
 input.destination == "staging-server"
 time.now >= "09:00:00"
 time.now < "18:00:00"
}

This policy allows “alice” to SSH into a staging server only during working hours.

Step 2: Add an SSH Proxy Layer

Install an SSH proxy like Teleport or customize sshd_config to forward access requests to the OPA service. Tools like Envoy can also help proxy the requests if you need additional scalability.

Modify sshd_config:

ForceCommand /usr/bin/query-opa-for-access.sh

This script should query the OPA API and enforce the decision locally.

Step 3: Deploy and Test

Deploy OPA on a reliable infrastructure or as a Kubernetes sidecar. Test your setup by attempting SSH access with different users and contexts to verify policy behavior.

Simplify Integration with hoop.dev

Building an SSH access proxy with OPA hands you robust access controls but managing the configuration manually can be time-consuming. With hoop.dev, you can set up and enforce policies for SSH access seamlessly in minutes.

hoop.dev includes built-in support for dynamic access controls and audit logs, layered on OPA’s policy engine. Skip the manual scripting and let hoop.dev streamline your process so you can focus on what really matters: managing access with precision and confidence.

Don’t take our word for it—see it live in minutes. Empower your teams without compromising on security.