Hi, I am trying to play around with OPAL locally and am able to evaluate policies as expected but the result field doesn't return a decision id. I tried adding the following in the opal-client but didn't work. Can you please help troubleshoot what I am missing

- OPAL_INLINE_OPA_CONFIG={"decision_logs":{"console":true},"plugins":{"decision_logs":{"reporting":{"min_delay_seconds":1,"max_delay_seconds":5}}},"default_decision_id_enabled":true,"default_authorization_decision_id_enabled":true}

Hi, I’m currently using the OPAL Alpine-based image and noticed that Trivy reported a vulnerability related to Starlette: CVE-2025-62727 Ref: https://avd.aquasec.com/nvd/2025/cve-2025-62727/ Since the OPAL image bundles Starlette, may I ask if there is a plan to update the Starlette version to address this CVE? Thanks~

hello everybody. when a pod with opa + opal-client as sidecar is booted, this container is extremely slow to get healthy. i figured out it depends on the number of rego-policies it fetches from the repo (currently 480 policies) this is the log: 2025-11-18T155741.165363+0000 | 15 | uvicorn.protocols.http.httptools_impl | INFO | 10.100.32.100:57604 - "GET /healthcheck HTTP/1.1" 503 2025-11-18T155745.382529+0000 | 15 | uvicorn.protocols.http.httptools_impl | INFO | 10.100.32.100:57612 - "GET /ready HTTP/1.1" 503 2025-11-18T155751.164121+0000 | 15 | opal_client.policy_store.opa_client |*WARNING | OPA client health: False (policy: False, data: True)* it takes ~10minutes or even longer how can i solve the issue? is this something known? can I workaround it?

In Opal server with scope configuration can we configure each scope to fetch a policy from an http endpoint.

Hi everyone, I'd like to discuss some authorization challenges we’ve been facing with OPAL External Data Source and get some feedback and experiences from the community. In our setup, every time we call the Triggering Data Updates API, we include a data source token in the payload entries that gets pushed to subscribers. The OPAL Client then uses this token to fetch data. Currently, under secure mode, the OPAL_CLIENT_TOKEN (JWT) is only validated at two points: • When initially establishing the WebSocket connection (handshake) • When reconnecting after a disconnect Once the connection is successfully established, the WebSocket connection continues to receive all topic updates even if the client token has expired. A hypothetical concern is that if an attacker obtains a client token, they could continuously access all the latest triggered data as long as the WebSocket connection remains open. Setting a short expiration for the client token seems ineffective and could cause issues with normal disconnects and reconnects, impacting availability. Similarly, setting a short expiration for the data source token also doesn't help because a new token is sent with every Trigger Data Updates call. I’m curious if the community has any strategic recommendations for managing authorization between OPAL client and server? Or if anyone knows of a way for the client to automatically include its OPAL Client Token during data fetch, so the Data Source could verify the token again on its end. Thanks!

Hello everyone, We've encountered something puzzling during our OPAL Client migration from 0.8.3 to 0.9.0, and I'd really appreciate some clarification. What we did: 1. Updated OPAL Client to 0.9.0 2. Initially enabled compatibility mode (

OPAL_OPA_V0_COMPAT=true

) as recommended 3. Then disabled compatibility mode (

OPAL_OPA_V0_COMPAT=false

) to test breaking changes 4. Expected our policies to fail (since we didn't add

.v1

to package names) What actually happened: Everything continues to work perfectly, even with compatibility mode disabled. Here's our policy structure:

package data.role  # No .v1 suffix - should this fail in strict v1 mode?

import rego.v1

import data.utils.v1.functions.jwt as functions_jwt
import data.utils.v1.roles as roles

default allow := false

allow if {
    functions_jwt.user_has_role(roles.admin)
    input.action == "get-roles"
}

According to the migration guide, without

.v1

suffix and with compatibility mode disabled, this should fail. But it doesn't. My questions: 1. Is

import rego.v1

now sufficient for v1 compatibility, making the package

.v1

suffix optional? 2. Has something changed in OPAL 0.9.0 that we're not aware of? 3. Are we possibly misunderstanding how compatibility mode works? We want to ensure we're not missing something important before rolling this out to other environments. Thanks for any insights!

hi, I have a question about limiting / blocking some credential data to be shown to public in opal. as i known, we could write a

system.rego

file like below to limit the url.

# system.rego
allow if {
    input.method == "POST" 
    input.path == ["v1", "data", "token"]
}

however, this would block the data update for that url. we know that the best benefit would be real-time data update in opal. so would there be any problem to trigger using

curl --request POST '<https://opa.xxx.xxx/data/config>'

. great thanks!

Can OPAL sever scopes work with http endpoints delivering policy bundle?

Which version of opal client supports EOPA

Hi all, can we disable capabilities of the integrated OPA somehow? For example, I want to forbid "http.send" completely, how can I do this?

I have OPAL_LOG_MODULE_EXCLUDE_LIST=["uvicorn"] set in my opal-client but continue to get logs like in my opal-client container {"text": "2025-12-22T222901.860010+0000 | uvicorn.protocols.http.httptools_impl | INFO | 100.98.8.170:57006 - \"GET /ready HTTP/1.1\" 200\n", "record": {"elapsed": {"repr": "00035.451661", "seconds": 35.451661}, "exception": null, "extra": {}, "file": {"name": "httptools_impl.py", "path": "/usr/local/lib/python3.10/site-packages/uvicorn/protocols/http/httptools_impl.py"}, "function": "send", "level": {"icon": "ℹ️", "name": "INFO", "no": 20}, "line": 476, "message": "100.96.6.170:57006 - \"GET /ready HTTP/1.1\" 200", "module": "httptools_impl", "name": "uvicorn.protocols.http.httptools_impl", "process": {"id": 11, "name": "MainProcess"}, "thread": {"id": 136954652896128, "name": "MainThread"}, "time": {"repr": "2025-12-22 222901.860010+00:00", "timestamp": 1766442541.86001}}}

@Sai Srungaram joined #opal. They’re also new to Permit.

@franziska joined #opal. They’re also new to Permit.

@dana joined #opal. They’re also new to Permit.

@dereky joined #opal. They’re also new to Permit.

@austin joined #opal. They’re also new to Permit.

@Will McGinnis joined #opal. They’re also new to Permit.

@Billy Yao joined #opal. They’re also new to Permit.

@david joined #opal. They’re also new to Permit.

@Javier Ponzo joined #opal. They’re also new to Permit.

Hello! Just a quick question, I was considering to use OPAL for managing policies, however it is not clear to me how it works when multiples/distributed OPAs (PDPs) come intro play, and how OPAL distributes the policy to the corresponding PDP

Hello everyone! 👋 Apologies for bringing this up again — I'd really appreciate hearing from anyone who has experience running 500+ rego policies managed with the opal-server + opal-client stack. The problem: I run opa and opal-client-standalone as sidecars in the same k8s pod. During cold start, the initial policy sync takes over 10 minutes, during which the OPAL client reports an unhealthy status — causing the pod to fail both readiness and liveness probes. Opal-client logs:

2026-03-03T20:36:11.372421+0000 | 16 | opal_client.policy_store.opa_client     | WARNING | OPA client health: False (policy: False, data: True)
2026-03-03T20:36:11.373165+0000 | 16 | uvicorn.protocols.http.httptools_impl   | INFO    | 10.100.35.127:51372 - "GET /healthcheck HTTP/1.1" 503
2026-03-03T20:36:11.379258+0000 | 16 | uvicorn.protocols.http.httptools_impl   | INFO    | 10.100.35.127:51384 - "GET /ready HTTP/1.1" 503

Root cause: OPAL pushes each policy individually via PUT /v1/policies/{path} to the OPA agent. With 500+ policies, each PUT takes ~0.5s+, and this duration appears to grow as more policies are loaded (likely because OPA recompiles/re-evaluates the entire policy set on every single insertion (not sure tho)). This sequential loading leads to a prohibitive startup time. OPA logs:

{"client_addr":"[::1]:37922","level":"info","msg":"Received request.","req_body":"<policy_content>","req_id":3841,"req_method":"PUT","req_params":{},"req_path":"/v1/policies/main/domain/subdomain/policy1.rego","time":"2026-03-03T20:23:39Z"}
{"client_addr":"[::1]:37922","level":"info","msg":"Sent response.","req_id":3841,"req_method":"PUT","req_path":"/v1/policies/main/domain/subdomain/policy1.rego","resp_body":"{}\n","resp_bytes":3,"resp_duration":631.523340,"resp_status":200,"time":"2026-03-03T20:23:39Z"}
{"client_addr":"[::1]:37934","level":"info","msg":"Received request.","req_body":"<policy_content>","req_id":3842,"req_method":"PUT","req_params":{},"req_path":"/v1/policies/main/domain/subdomain/policy2.rego","time":"2026-03-03T20:23:39Z"}
{"client_addr":"[::1]:37934","level":"info","msg":"Sent response.","req_id":3842,"req_method":"PUT","req_path":"/v1/policies/main/domain/subdomain/policy2.rego","resp_body":"{}\n","resp_bytes":3,"resp_duration":716.441353,"resp_status":200,"time":"2026-03-03T20:23:39Z"}

What I've considered to solve: one idea is to use bundles and pre-bake the policies into the OPA container image (e.g. via opa run --bundle /policies, or different methods), so that OPA boots up instantly with all policies already compiled. However, OPAL client has no concept of a "starting commit hash" or awareness that OPA already has the policies — its internal state is in-memory and lost on every restart. So it would still perform the full sync via individual PUTs on every cold start, making the pre-bake effectively useless unless there's a way to tell OPAL "the store is already up-to-date as of commit X — only sync the delta." I’d be very interested to know: - whether others have seen similar behavior at this scale and how you handled/mitigated this - whether there is a way to make OPAL skip the initial full sync if OPA is already pre-loaded (e.g. by providing the last policy commit hash present in the bundle) - whether there is a way to switch OPAL to deliver policies as an OPA bundle instead of individual PUT calls Any real-world experience or recommendations would be very helpful. Thanks!!! 🙏☺️

Hi all, We are running into an issue with the communication between the OPAL server and the OPAL client. We are using a Kubernetes cluster in GCP and Helm to deploy the OPAL server, client, and PostgreSQL. Below are the logs from the OPAL server and client. The issue disappears when I restart or redeploy the OPAL server. This does not happen all the time and appears to be a random event. When this happens, the OPAL client cannot start. Any thoughts? Let me know if you need more information. Thank you in advance. 🙂 OPAL server log:

2026-03-12T09:20:44.817436+0000 | fastapi_websocket_rpc.websocket_rpc_e...| INFO  | Client disconnected - 43490 :: d78ae83fc0b4447a98a544a81f7465e0
2026-03-12T09:20:44.817686+0000 | websockets.legacy.server                | INFO  | connection closed
2026-03-12T09:20:44.889455+0000 | fastapi_websocket_rpc.websocket_rpc_e...| INFO  | Client connected
2026-03-12T09:20:44.889886+0000 | websockets.legacy.server                | INFO  | connection open
2026-03-12T09:20:44.894689+0000 | fastapi_websocket_rpc.websocket_rpc_e...| INFO  | Client disconnected - 39376 :: dee642b8daa4491a8ba991f19a80b981
2026-03-12T09:20:44.894872+0000 | websockets.legacy.server                | INFO  | connection closed
2026-03-12T09:20:46.382346+0000 | fastapi_websocket_rpc.websocket_rpc_e...| INFO  | Client connected
2026-03-12T09:20:46.382868+0000 | websockets.legacy.server                | INFO  | connection open
2026-03-12T09:20:46.388795+0000 | fastapi_websocket_rpc.websocket_rpc_e...| INFO  | Client disconnected - 37782 :: 44457ab56137481e9fb742fd39fe10b0
2026-03-12T09:20:46.389028+0000 | websockets.legacy.server                | INFO  | connection closed
2026-03-12T09:20:47.124470+0000 | fastapi_websocket_rpc.websocket_rpc_e...| INFO  | Client connected

OPAL client log:

File "/usr/local/lib/python3.10/site-packages/fastapi_websocket_rpc/rpc_channel.py", line 433, in async_call
    await self.send(msg)
          │    │    └ RpcMessage(request=RpcRequest(method='_ping_', arguments={}, call_id='5369bcdcc34a4b4a9c32e3837ddec06a'), response=None)
          │    └ <function RpcChannel.send at 0x7c45cc2e69e0>
          └ <fastapi_websocket_rpc.rpc_channel.RpcChannel object at 0x7c45c541a890>
  File "/usr/local/lib/python3.10/site-packages/fastapi_websocket_rpc/rpc_channel.py", line 211, in send
    await self.socket.send(data)
          │    │      │    └ RpcMessage(request=RpcRequest(method='_ping_', arguments={}, call_id='5369bcdcc34a4b4a9c32e3837ddec06a'), response=None)
          │    │      └ <function JsonSerializingWebSocket.send at 0x7c45cc2e7c70>
          │    └ <fastapi_websocket_rpc.simplewebsocket.JsonSerializingWebSocket object at 0x7c45c54183d0>
          └ <fastapi_websocket_rpc.rpc_channel.RpcChannel object at 0x7c45c541a890>
  File "/usr/local/lib/python3.10/site-packages/fastapi_websocket_rpc/simplewebsocket.py", line 44, in send
    await self._websocket.send(self._serialize(msg))
          │    │          │    │    │          └ RpcMessage(request=RpcRequest(method='_ping_', arguments={}, call_id='5369bcdcc34a4b4a9c32e3837ddec06a'), response=None)
          │    │          │    │    └ <function JsonSerializingWebSocket._serialize at 0x7c45cc2e7b50>
          │    │          │    └ <fastapi_websocket_rpc.simplewebsocket.JsonSerializingWebSocket object at 0x7c45c54183d0>
          │    │          └ <function WebSocketsClientHandler.send at 0x7c45cc2fc280>
          │    └ <fastapi_websocket_rpc.websocket_rpc_client.WebSocketsClientHandler object at 0x7c45c753c280>
          └ <fastapi_websocket_rpc.simplewebsocket.JsonSerializingWebSocket object at 0x7c45c54183d0>
  File "/usr/local/lib/python3.10/site-packages/fastapi_websocket_rpc/websocket_rpc_client.py", line 147, in send
    await self._websocket.send(msg)
          │    │          │    └ '{"request": {"method": "_ping_", "arguments": {}, "call_id": "5369bcdcc34a4b4a9c32e3837ddec06a"}, "response": null}'
          │    │          └ <function Connection.send at 0x7c45c754cd30>
          │    └ <websockets.asyncio.client.ClientConnection object at 0x7c45c547c790>
          └ <fastapi_websocket_rpc.websocket_rpc_client.WebSocketsClientHandler object at 0x7c45c753c280>
  File "/usr/local/lib/python3.10/site-packages/websockets/asyncio/connection.py", line 476, in send
    async with self.send_context():
               │    └ <function Connection.send_context at 0x7c45c754d360>
               └ <websockets.asyncio.client.ClientConnection object at 0x7c45c547c790>
  File "/usr/local/lib/python3.10/contextlib.py", line 199, in __aenter__
    return await anext(self.gen)
                       │    └ <async_generator object Connection.send_context at 0x7c45c75f5fc0>
                       └ <contextlib._AsyncGeneratorContextManager object at 0x7c45c541aaa0>
  File "/usr/local/lib/python3.10/site-packages/websockets/asyncio/connection.py", line 957, in send_context
    raise self.protocol.close_exc from original_exc
          │    │        │              └ None
          │    │        └ <property object at 0x7c45c7e9f830>
          │    └ <websockets.client.ClientProtocol object at 0x7c45c547c6d0>
          └ <websockets.asyncio.client.ClientConnection object at 0x7c45c547c790>

websockets.exceptions.ConnectionClosedOK: received 1000 (OK); then sent 1000 (OK)
2026-03-12T09:21:48.511830+0000 | opal_client.policy_store.opa_client     |WARNING | OPA client health: False (policy: False, data: False)
2026-03-12T09:21:48.512277+0000 | uvicorn.protocols.http.httptools_impl   | INFO  | 10.246.16.157:55704 - "GET /healthcheck HTTP/1.1" 503
2026-03-12T09:21:52.514744+0000 | opal_client.policy_store.opa_client     |WARNING | OPA client health: False (policy: False, data: False)
2026-03-12T09:21:52.515261+0000 | uvicorn.protocols.http.httptools_impl   | INFO  | 10.246.16.157:57878 - "GET /healthcheck HTTP/1.1" 503
2026-03-12T09:22:04.668932+0000 | opal_client.policy_store.opa_client     |WARNING | OPA client health: False (policy: False, data: False)
2026-03-12T09:22:04.669366+0000 | uvicorn.protocols.http.httptools_impl   | INFO  | 10.246.16.157:54528 - "GET /healthcheck HTTP/1.1" 503
2026-03-12T09:22:04.672225+0000 | opal_client.policy_store.opa_client     |WARNING | OPA client health: False (policy: False, data: False)
2026-03-12T09:22:04.672794+0000 | uvicorn.protocols.http.httptools_impl   | INFO  | 10.246.16.157:54536 - "GET /healthcheck HTTP/1.1" 503
2026-03-12T09:22:19.672953+0000 | opal_client.policy_store.opa_client     |WARNING | OPA client health: False (policy: False, data: False)
2026-03-12T09:22:19.673463+0000 | uvicorn.protocols.http.httptools_impl   | INFO  | 10.246.16.157:44232 - "GET /healthcheck HTTP/1.1" 503
2026-03-12T09:22:34.672830+0000 | opal_client.policy_store.opa_client     |WARNING | OPA client health: False (policy: False, data: False)
2026-03-12T09:22:34.673382+0000 | uvicorn.protocols.http.httptools_impl   | INFO  | 10.246.16.157:35314 - "GET /healthcheck HTTP/1.1" 503

Hey Permit team — we saw a transient outage this morning (~622 625 AM PST) where both our PDP sidecars (permitio/pdp-v2:latest) lost their OPAL websocket connection to wss://opal.permit.io/ws. OPA went to health: False (policy: False, data: False) on both pods, causing 502s on all permission checks. Two questions: 1. Was there a Permit.io / OPAL outage this morning around 1422 1425 UTC? Both our PDP instances failed simultaneously. 2. Why does the PDP /healthy endpoint return 200 when OPA is completely unhealthy? We observed OPA client health: False (policy: False, data: False) being logged every 5 seconds, yet /healthy kept returning 200. This prevented Kubernetes from detecting the failure and restarting the pod. Is there a config option to make /healthy reflect OPA readiness, or is this expected behavior? One pod self-recovered, the other got stuck in a DNS resolution loop for opal.permit.io ([Errno -5] Name has no usable address) for over an hour until we manually killed it.

Is this normal when using opal with redis as broadcast? I keep receiving Redis connection made, Redis connection lost

We had a similar OPAL issue. Redeploying PDP seemed to take care of it. Not sure why.

Is there a way to rotate opal master token. Any update on the master token seems to invalidate opal connection to the server. Is there an architecture pattern available?

Is there a better option from the Permit.io team on using OPA vs Cedar?

This message was deleted.

Hi, I'm trying to follow the OPAL tutorial for container playground. The command to start the containers seems to work ok, but when I send the example query (curl --request GET 'http://localhost:8181/v1/data/users' --header 'Content-Type: application/json' | python -m json.tool), I just get {} as the response? There is also a period websocket closure error in the container console... not sure if that's related?