Istio (1.6.2) : RBAC Access Denied for Valid JWT Token

Security
1

I’m new to Istio. I’m implementing Authorization with JWT. I get RBAC access denied error for a valid JWT token. I’ve added the JWT Payload and Authorization Policy for reference.
I’m using kubernetes version v1.18.3 and Istio 1.6.2. I’m running cluster on minikube.

2

@YangminZhu ^^ can you take a look?

3

Can you add your request authentication yaml?

4

apiVersion: “security.istio.io/v1beta1”
kind: “RequestAuthentication”
metadata:
name: dex-ms-contact-jwt
namespace: default
spec:
selector:
matchLabels:
app: dex-ms-contact
jwtRules:

5

Hi @sweta581990

You have to apply the RequestAuthentication & Authorizationpolicy on the Istio-ingressgateway pod in the istio-system in case if you are accessing from the outside the cluster. and generate the token use it when accessing the application Authorization: Bearer $TOKEN

may be this will help you.

6

try this:

RequestAuthentication

apiVersion: "security.istio.io/v1beta1"
kind: "RequestAuthentication"
metadata:
  name: "dex-ms-contact-jwt"
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
  - issuer:  “https://dev-n63ipah2.us.auth0.com/”
    jwksUri: “https://dev-n63ipah2.us.auth0.com/.well-known/jwks.json”
    audience:
     - “http://10.97.72.213/”

Authorizationpolicy

    apiVersion: "security.istio.io/v1beta1"
    kind: "AuthorizationPolicy"
    metadata:
      name: "dex-ms-contact-require-jwt"
      namespace: istio-system
    spec:
      selector:
        matchLabels:
          istio: ingressgateway
      action: ALLOW
      rules:
      - from:
        - source:
           requestPrincipals: ["https://dev-n63ipah2.us.auth0.com/sEbjHGBcZ16D0jk8wohIp7vPoT0MWTO0@clients"]
        to:
        - operation:
           methods: ["*"]
           paths: ["*"]
        when:
        - key: request.auth.claims[iss]
          values: ["https://dev-n63ipah2.us.auth0.com/"]

look this:

1 Like
7

@Shubham, @mandarjog

Hi, I have few queries:

Let’s say I applied authentication and authorization policy at ingressgateway.
Now I again apply authentication and authorization policy at namespace level.(Note: I have not deleted the ingressgateway authentication and authorization policy yet.)

Istio will consider which policy(ingressgateway or namespace level)?
Can I apply both the ingressgateway and namespace level at same time? If yes, which one take precedence or both will work at same time? If no, what should be the ideal way to apply policy at all the levels and expected behavior? Could you please explain me with some example Lets say we have ingressgateway (I) , Service A and Service B(in same namespace)

Also, How virtual service and authentication and authorization policy are connected?

8

@Shubham, @mandarjog Could you please reply. Thanks!

9

Istio will consider which policy(ingressgateway or namespace level)?
Can I apply both the ingressgateway and namespace level at same time?

The basic model is that request authentication and authorization policy are additive, which means multiple policies applied to the same workload will have effect at the same time. In your example, if you apply the policy on ingressgateway which is usually in the namespace istio-system, and apply some other policies in another namespace (e.g. foo), those policies will not take effect at the same time because they are not applied to the same workload. See Istio / Security for more details.

Also, How virtual service and authentication and authorization policy are connected?

The VirtualService applies to Envoy in the client side, it has nothing to do with the auth policy which take place in the server side Envoy.

For your original question, I noticed that there is an extra / in your JWT token issuer, which means the requestPrincipal should be https://dev-n63ipah2.us.auth0.com//sEbjHGBcZ16D0jk8wohIp7vPoT0MWTO0@clients. There is also another reply in your original post for this, please give this a try and let me know if it fixes the issue. Thanks.

2 Likes
10

Sorry for late response @sweta581990

But what @YangminZhu Said is right. Thanks @YangminZhu
i didn’t notice that “/”.
taking your case(policies you apply on workload) – May be you should access the app application with header Authorization: Bearer $TOKEN
try it when you curl.

11

@YangminZhu, @Shubham Let’s say I have 3 namespace:

  1. istio-system
  2. foo (2 services are running service A and service B)
  3. bar (3 services are running service C, service D and service E)

I applied policies at ingressgateway, I will be able to access service A and service B(in foo namespace) only through bearer token right?
Also service C, service D and service E which are in namespace bar only through bearer token right?

Can I apply different policy for namespace foo and namespace bar at the same time?
if yes, will both the policies work at same time (considering I have not applied policy at ingressgateway)

Also, Let’s say I have 2 applications running. one is web application (Service A) and other expose just a simple rest api (Service B) in same namespace. In Auth0 there are 2 application clients registered for each application to generate token. Can i use different policies for each application in same namespace?

12

@YangminZhu @Shubham Could you please reply. thanks!

13

Hi @sweta581990

  • you can access the service from outside the cluster through bearer token if you apply
    the policy to the ingressgateway with proper gateway rule & VirtualService.
  • From my understanding u can apply the diif policy to foo and bar ns at same time. its
    work. i try it by applying Requestauthenticationpolicy & Authorizationpolicy in foo & bar
    ns. have same applications. (i.e. httpbin & sleep) i used same token for them. when
    i accessed from sleep.foo to httpbin.bar with bearer token then it gave me
    200(succesful accessed) without token i can’t accessed it and vice versa also.
  • diffpolicies for diff applications in same namesace… not sure but may be yes. you can
    apply it workload specific policy.

It is on my understanding & i am still learning the things so may be i am wrong. so if you find anything wrong so pls tell me also its good for me. @YangminZhu will tell more accurate about it…

14

@YangminZhu Could you please help. Thanks!

15

@mandarjog Could you please help thanks!

16

Yes.

and yes. (Note you need to make sure your traffic is going through the ingress gateway in the first place if you plan to apply the policy on ingress gateway)

Yes, you can do this and they will take effect at the same time. Say you have policy x on ingress gateway, policy y on namespace foo and policy z on namespace bar.

policy x and y will take effect for requests to namespace foo assuming it’s going through ingress gateway.

policy x and z will take effect for requests to namespace bar assuming it’s going through ingress gateway.

yes, this is the workload-level policy, say you have policy m on service A in namespace foo, and policy n on server B in the same namespace, with the policy x on ingress gateway and policy y on namespace foo:

policy x, y and m will take effect for requests to service A in namespace foo assuming it’s going through ingress gateway.

policy x, y and n will take effect for requests to service B in namespace foo assuming it’s going through ingress gateway.

1 Like
17

Thanks @YangminZhu for the explantion. so what i have said above is right.!