Yes, deploying OPAL Server in one EKS cluster and OPAL Clients as sidecars in another EKS cluster is a valid architecture. Here's what the documentation says about this setup: Architecture Overview OPAL uses a client-server architecture where the OPAL Server creates a Pub/Sub channel that clients subscribe to (1) . The OPAL Client is deployed alongside a policy-agent (like OPA) and subscribes to updates from the server . Clients open an outgoing websocket connection to servers, which helps overcome most firewall/networking challenges and creates a bi-directional Pub/Sub channel . Sidecar Deployment Pattern The most common way to deploy the PDP (with OPAL Client) locally is as a sidecar or daemon-set - running one PDP container next to each of your microservices (2) . This provides zero-latency between your application and the PDP, along with improved stability and security . For Kubernetes deployments, including EKS, you need to: 1. Open port 7000 (often mapped to 7766 when running locally) for the API Service 2. Open port 8181 to expose OPA directly 3. Use the

/healthcheck

endpoint on the API to check for readiness Cross-Cluster Communication Since OPAL Clients open outgoing HTTPS websocket connections to the OPAL Server , having them in separate EKS clusters works well as long as: • The OPAL Server is accessible via HTTPS from the client cluster • Network policies allow the outgoing websocket connections • The server is exposed with proper SSL/TLS certificates in production (3) Scaling Considerations For scaling OPAL Servers across multiple instances, you can use a backbone Pub/Sub like Redis, Kafka, or Postgres (1) . The architecture supports multiple OPAL Server instances syncing through this backbone, so a client connecting to one server receives notifications triggered by another server . This distributed architecture with OPAL Server in one cluster and clients as sidecars in another is particularly suitable for hybrid cloud environments where you want centralized policy management with distributed enforcement (4) (5) .

To learn more, see the sources I considered: [[1] Architecture 🏗️](https://docs.opal.ac/overview/architecture) [[2] at Scale](https://docs.permit.io/how-to/deploy/overview) [[3] Running the Server](https://docs.opal.ac/getting-started/running-opal/run-opal-server/putting-all-together) [[4] Best Practices for Implementing Hybrid Cloud Security](https://www.permit.io/blog/best-practices-for-implementing-hybrid-cloud-security) [[5] OPAL - an Authorization Service for Fine-Grained Permissions](https://www.permit.io/blog/introduction-to-opal)

ALBs can potentially cause issues with WebSocket connections, but they can work if configured properly. Based on the OPAL documentation: OPAL creates a highly efficient communications channel using websocket Pub/Sub connections to subscribe to both data and policy updates (1) . By using ​*outgoing*​ websocket connections to establish the Pub/Sub channel, most routing/firewall concerns are circumnavigated . The key consideration is that OPAL uses WebSocket connections that need to stay idle most of the time, saving CPU cycles for both clients and servers . The PDP opens an outgoing HTTPS websocket connection to Permit.io, which is used to subscribe to updates (2) . For ALB specifically, you'd need to ensure: • WebSocket support is enabled (ALB supports WebSockets) • Appropriate timeout settings (WebSockets can have long idle periods) • Sticky sessions if using multiple OPAL server instances The direct connectivity recommendation makes sense because WebSocket connections benefit from minimal network hops and latency. Extra networking layers can introduce complexity with connection persistence and timeouts.

To learn more, see the sources I considered: [[1] Design](https://docs.opal.ac/overview/design) [[2] at Scale](https://docs.permit.io/how-to/deploy/overview)

Thanks for the feedback, glad I was helpful.

Thanks for the feedback, glad I was helpful.