fix(proxy): include OPA deny reason in CONNECT 403 response#2363
Conversation
When a CONNECT request was denied by OPA policy, the 403 response used a generic "not permitted by policy" message for both "endpoint not in policy" and "endpoint matched but binary didn't match." Users had no way to distinguish the two without reading supervisor logs. The OPA policy already computes a detailed deny_reason (e.g., "binary '/usr/bin/node' not allowed in policy 'X'") but the proxy was not including it in the HTTP response. Now the CONNECT deny response includes a "reason" field with the OPA deny reason when available. When the reason is empty, the field is omitted for backward compatibility. Fixes NVIDIA#2355 Signed-off-by: Adel Zaalouk <azaalouk@redhat.com>
PR Review StatusValidation: This PR is project-valid because it is a small, concentrated proxy bug fix linked to #2355 and addresses a user-visible sandbox policy debugging gap. Review findings:
Docs: missing for a direct sandbox/proxy behavior change documented in Next state: |
|
/ok to test e333f14 |
|
Label |
…sponse The proxy now includes a reason field in the JSON body of denied CONNECT responses when the policy engine provides a specific denial cause. Update the Proxy Error Responses section to show the field and describe when it is present vs omitted. Signed-off-by: Adel Zaalouk <azaalouk@redhat.com>
PR Review StatusValidation: This PR is project-valid because it is a small, concentrated proxy bug fix linked to #2355 and addresses a user-visible sandbox policy debugging gap. Review findings:
Docs: updated for the direct sandbox/proxy behavior change; no navigation update is needed for this existing docs page. Next state: |
|
/ok to test 785d231 |
Monitoring CompleteMonitoring is complete because this PR has merged. Final status: latest gator state was I removed the active |
Summary
When a CONNECT request is denied by OPA policy, the 403 response used a generic "not permitted by policy" message for both "endpoint not in policy" and "endpoint matched but binary didn't match." Users had no way to distinguish the two without reading supervisor logs, making binary identity the #1 debugging friction when setting up agents.
Related Issue
Fixes #2355
Changes
build_json_error_response_with_reasonfunction that includes an optionalreasonfield in the JSON bodydeny_reason(which already contains detailed binary mismatch info)Before:
{"detail":"CONNECT host:443 not permitted by policy","error":"policy_denied"}After (binary mismatch):
{"detail":"CONNECT host:443 not permitted by policy","error":"policy_denied","reason":"binary '/usr/bin/python3.11' not allowed in policy 'allow_xxx' (ancestors: [...])"}Testing
Bug reproduced live against a running sandbox:
mise run pre-commitpassespolicy_deny_response_includes_reason,policy_deny_response_omits_empty_reasonChecklist