External auth

[julianstephen]

I have an envoy+opa external auth setup working well. If I create a dummy policy with allow = true, I can access my web pages and if I change the flag to false, I get a 403 as expected.

Now, my trouble is with a slightly more complex policy. I recreated a scaled down version in the
Playground. My opa-envoy config is set to look at path:

plugins:
  envoy_ext_authz_grpc:
    addr: :9000
    path: envoy/authz/allow

I have a policy that follows the structure

   package envoy.authz
   default allow := false
   allow {
	test1
   }
   test1 {
	4 == 4
   }

Policy is mounted as a config-map into the opa-envoy server. If this policy is evaluated without any additional data, I will get envoy/authz/allow: true as expected. But, immediately after server start, if I visit <serv>/v1/data, I see

{"decision_id":"977a2baf-truncated","result":{"envoy":{"authz":{"allow":false}}}}

I am not PUT/POST'ing any data to the server. And now, because of the allow: false in the base data document (as shown in the playground link), all future evaluations of the policy is turning out to be false. Of course if I change the package name in the playground to newpackage so that it does not match the allow object in the data section, I will get true again. But this just means in the server v1/data there is now {"newpackage":{"allow":false}}

What am I doing wrong here? How can I get the expected behaviour where value of envoy/authz/allow is decided only by evaluation of the policy and not default value in v1/data?

Thank You!

[ashutosh-narkar]

@julianstephen I am not exactly sure I understand but if the policy you stated is the only policy loaded into OPA, then both curl -X POST localhost:8181/v1/data and curl localhost:8181/v1/data should both result in the same result for the allow rule.

Now I'm not sure why you also have the following. What is the purpose of this?

{
    "envoy": {
        "authz": {
            "allow": false
        }
    }
}

[julianstephen]

Hi Ashutosh. This is the only policy loaded into OPA. I am not adding the

{
    "envoy": {
        "authz": {
            "allow": false
        }
    }
}

by myself. Once the ext auth opa server is running, I can see this value in v1/data, presumably from the default value set in the policy. Note that the policy package name is envoy.authz. And as you see here, it does not return allow:true as I thought it would.

[timothyhinrichs]

That extra data is overriding the evaluation of your 'allow' rules in the playground. Remove it, and 'allow' will evaluate to true. It's not the `default allow := false` rule that is causing the result. It's the Data you included. The playground (as well as OPA) merge the 'data' you inject with the package hierarchy. Since your data is envoy.authz.allow: false, and your package name is envoy.authz, the playground is combining them to produce 'allow' as false because that's what your data says it should be. (Not sure off the top of my head what OPA would do if you added that data to it -- could be the same, could use the rules instead, could reject the data insert.) Tim

…

On Wed, Aug 9, 2023 at 4:50 PM julianstephen ***@***.***> wrote: Hi Ashutosh. This is the only policy loaded into OPA. I am not adding the { "envoy": { "authz": { "allow": false } } } by myself. Once the ext auth opa server is running, I can see this value in v1/data, presumably from the default value set in the policy. Note that the policy package name is envoy.authz. And as you see here <https://play.openpolicyagent.org/p/LSjoMzFpYf>, it does not return allow:true as I thought it would. — Reply to this email directly, view it on GitHub <#481 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACMVQKY3AMTVUOFQNK6OBI3XUQO3PANCNFSM6AAAAAA3KV2JVY> . You are receiving this because you are subscribed to this thread.Message ID: <open-policy-agent/community/repo-discussions/481/comments/6685462@ github.com>

[julianstephen]

I understand the extra data is overriding the allow rule in the policy. But my trouble is that immediately after the opa-envoy server starts up and loads the policy, the extra data is automatically showing up in the server. I'm a bit stumped by this, I am under this assumption because immediately after the opa-envoy deployment becomes ready, if I curl the v1/data end point, I get this:

{"decision_id":"977a2baf-truncated","result":{"envoy":{"authz":{"allow":false}}}}

[timothyhinrichs]

I see. Quick point of clarification first. When we run v1/data we're asking OPA to evaluate all the rules that are loaded and return the result as a giant JSON object. In contrast, we're not asking OPA to return the JSON data that has been loaded into base documents. It's the combination of base documents and results of policy evaluation that get returned. Example. Say we have your rules slightly tweaked... package envoy.authz default allow := false allow { test1 } default test1 = false test1 { 4 == 3 } If we run GET v1/data, the answer will be... { "envoy": {"authz": {"allow": false, "test1": false}}} So just because v1/data returns the above, that doesn't mean the data is loaded as a base document. I'd try adding a default value into test1 and see if you get values for allow+test1. If not, we're not loading the policies we think we are. Two branches of help depending on what you think is most likely. 1. There's NO ADDITIONAL data being injected into OPA. I'm wondering if we have an old ConfigMap that's not getting re-read into OPA. I'm fuzzy here, but just updating the ConfigMap on a running OPA doesn't remount or get reread I don't think. Did we try killing the OPA pod to force the re-read of the configmap? I'd suggest adding the default rule for test1 and seeing if you're getting a value for test1 on a v1/data API call. If not, we know the policy loaded isn't the one we think is loaded. 2. There IS ADDITIONAL data being injected into OPA. My first instinct would be that there are additional JSON files getting mounted somehow... - Can you share K8s pod/deployment/whatever manifest? - Is there another configmap getting mounted? - Are there any directories getting mounted with the file data.json in them? - Have we tried killing the OPA pod to be sure it's starting from a clean slate? Tim

…

On Wed, Aug 9, 2023 at 5:23 PM julianstephen ***@***.***> wrote: I understand the extra data is overriding the allow rule in the policy. But my trouble is that immediately after the opa-envoy server starts up and loads the policy, the extra data is automatically showing up in the server. I'm a bit stumped by this, I am under this assumption because immediately after the opa-envoy deployment becomes ready, if I curl the v1/data end point, I get this: {"decision_id":"977a2baf-truncated","result":{"envoy":{"authz":{"allow":false}}}} — Reply to this email directly, view it on GitHub <#481 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACMVQK7SFTH6QS4I7GVH6MDXUQSZZANCNFSM6AAAAAA3KV2JVY> . You are receiving this because you commented.Message ID: ***@***.*** com>