ISTIO authorization policy failing to match string in a claims

1

I was trying trying to implement an ISTIO authorization policy where I have a requirement to allow a request if a value in claim matches in any part of particular string.

Example: The Rule looks something like this:

rules:
  - to:
    - operation:
        methods: ["GET"]
        hosts: ["sample.com"]
    when:
    - key: request.auth.claims[TEST_STRING]
      values: ["SUBSTR" , "*SUBSTR" , "*SUBSTR*" , "SUBSTR*"]

Everything works fine if the value ‘SUBSTR’ contains as a prefix or suffix in claims, But if the string SUBSTR is in a middle the claim the condition failing. Is there any solution where the request is allowed if the values contains a substr in the middle.In my case the condition 

 “[* SUBSTR *]”

Check for the contains
2

To clarify your test case. It seems that a few characters chopped in your policy.
Policy for your testing:
values: [“SUBSTR” , “*SUBSTR” , “*SUBSTR*” ]
you are using the value “[* SUBSTR *]” as the claim. # there are spaces before and after SUBSTR.

3

Thanks Emily for a quick response.

It doesn’t work even after removing spaces.
It is failing to match the rule if the value in the claim contains XYZSUBSTRPQR

4

Hi @Govula_Srinivas @k_santosh

AFAIK This value matching is not Supported. see this link:


may be this will help you.
5

Any plan to support this feature in future releases?

6

We haven’t introduced regular expression match in AuthorizationPolicy because there was concern that it may introduce security vulnerability unexpectedly. But there was a proposal to introduce CEL (https://github.com/google/cel-spec) condition with limited syntax in the future to AuthorizationPolicy. @yangminzhu

7

@liminwang Do you have any temporary work around or alternative solution to address this usecase.

8

I don’t have an easy workaround for it. You can look at your use case, and try to express it using multiple prefix/suffix matches.

9

@liminwang

We were able to achieve the functionality using lua filter which is something like below.
We are yet to perform peformance tests, in the mean time could you advice and share your thoughts would there be any performance impact using lua filter.

function envoy_on_request(request_handle)
local meta = request_handle:streamInfo():dynamicMetadata():get(“envoy.filters.http.jwt_authn”)
local claims = meta[“https://XXXXXXXXXXX”]
local applicationGroups = claims.APPLICATION_GROUPS
local headers = request_handle:headers()
local path = headers:get(":path")
local authority = headers:get(":authority")
if authority == “testdomain.com” and path == “/testPath” then
if string.match(applicationGroups, “testGroup”) then
return
else
request_handle:respond({[":status"] = “401”},“

policy denied: should be part of testGroup

”)
end
end
end

10

Performance wise, Lus filter is not ideal compared to native Envoy filter (which Istio AuthorizationPolicy uses). But I don’t really have performance profile comparing the two. It can be a good workaround before the native support is ready.

11

Thanks @liminwang for the details, Can we expect native support in 1.7 release?

12

No. Definitely not in 1.7. We will take it as one of the feature requests. cc @YangminZhu who is planning future improvement for AuthorizationPolicy.