Replies: 6 comments 4 replies
-
See the configuration options for the plugin here: https://www.openpolicyagent.org/docs/edge/envoy-introduction/#configuration The
So you'll want to add: result["allowed"] := allow Not sure if it solves the problem, but it was the one outstanding issue I noticed :) |
Beta Was this translation helpful? Give feedback.
-
Also you can define the HTTP response status code sent to the downstream client when a request is denied. Be default, Envoy returns a 403. More info here. |
Beta Was this translation helpful? Give feedback.
-
Thanks I'll take a look at this tomorrow. |
Beta Was this translation helpful? Give feedback.
-
OK so I set Am I missing something ? |
Beta Was this translation helpful? Give feedback.
-
My |
Beta Was this translation helpful? Give feedback.
-
I would first unit test the policy to ensure you're seeing the correct response. If that looks ok, then turn on debug logging to ensure you see the correct OPA policy result. At this point we've verified that the response OPA sends to Envoy is what we expect. Then you can look into Envoy logs to see if you notice anything in there. You could also add a log here to print the complete response OPA sends to Envoy. |
Beta Was this translation helpful? Give feedback.
-
So I have this policy which basically checks that the SAN UPN value is submitted CSR matches a claim within the JWT used for authorisation.
https://play.openpolicyagent.org/p/1tmmorwMuD
The demo's input provide an
authorization1
andauthorization2
field. If you set thehttp.headers.authorizationX
in the token section toauthorization1
the fields match and the policy is allowed and it returns a 200 status code.If set to
authorization1
the fields don't match and the policy is not allowed and it returns a 407 status code.This seems to work as expected in the playground, however if I then move it to the Envoy proxy it returns a 401 instead of the 407 upon failure.
Beta Was this translation helpful? Give feedback.
All reactions