Istio return "RBAC: access denied" with wildcard path

12/31/2020

Istio has returning "RBAC: access denied" when use wildcard path in "AuthorizationPolicy", see files:

api-key-test-authorization.yml

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: api-key-test-authorization
  namespace: test
spec:
  selector:
    matchLabels:
      api-key-secured: enabled
  rules:
  - to:
    - operation:
        paths: ["*/test1", "*/test2/*", "*/test4*"]
  - to:
    - operation:
        paths: ["/*"]
    when:
    - key: request.headers[api-key]
      values: ["XXXXXXXX"]

Resources.java

...
enter code here
@GetMapping(value = "/test1")
@ResponseBody
public ResponseEntity<Resource> getTest1(HttpServletResponse response) throws IOException {

    System.out.println("Test 1");

    return ResponseEntity.ok().build();
}

@GetMapping(value = "/test2/{id}/xpto")
@ResponseBody
public ResponseEntity<Resource> getTest2(@PathVariable("id") String id, HttpServletResponse response) throws IOException {

    System.out.println(id + " XPTO");

    return ResponseEntity.ok().build();
}

@GetMapping(value = "/test3/{id}")
@ResponseBody
public ResponseEntity<Resource> getTest3(@PathVariable("id") String id, HttpServletResponse response) throws IOException {

    System.out.println(id + " of Test 3");

    return ResponseEntity.ok().build();
}

Results:

These path are configured to not need to pass the "api-key", however when there is a wildcard (*) in the path it returns the error demanding the "api-key".

I'm using Istio.1.4.9

-- Joel da Rosa
istio
java
kubernetes
spring

1 Answer

1/1/2021

It seems that according to documentation, prefix or suffix matching is possible, but not both:

Any string field in the rule supports Exact, Prefix, Suffix and Presence match:

  • Exact match: “abc” will match on value “abc”.
  • Prefix match: “abc*” will match on value “abc” and “abcd”.
  • Suffix match: “*abc” will match on value “abc” and “xabc”.
  • Presence match: “*” will match when value is not empty.

Note that for your given URLs, prefix matching will probably be enough, as the domain part is not taken into account in this context.

Something like that (untested)

paths: ["test1", "test2/*", "test4*"]
-- user140547
Source: StackOverflow