1

We have recently setup istio on our kubernetes cluster and are trying to see if we can use RequestAuthentication and AuthenticationPolicy to enable us to only allow a pod in namespace x to communicate with a pod in namespace y when it has a valid jwt token.

All the examples I have seen online seem to only apply for end user authentication via the gateway rather than internal pod to pod communication.

We have tried a few different options but are yet to have any luck.

We can get AuthenticationPolicy to work for pod to pod traffic using "from" and the source being the IP address of the pod in namespace x:

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
 name: "request-jwt"
 namespace: y
spec:
  jwtRules:
  - issuer: "https://keycloak.example.com/auth/realms/istio"
    jwksUri: "https://keycloak.example.com/auth/realms/istio/protocol/openid-connect/certs"
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "jwt-auth"
  namespace: y
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        ipBlocks: ["10.43.5.175"]

When we add when block for jwt it doesn't work:

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
 name: "request-jwt"
 namespace: y
spec:
  jwtRules:
  - issuer: "https://keycloak.example.com/auth/realms/istio"
    jwksUri: "https://keycloak.example.com/auth/realms/istio/protocol/openid-connect/certs"
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "jwt-auth"
  namespace: y
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        ipBlocks: ["10.43.5.175"]
    when:
     - key: request.auth.claims[iss]
       values: ["https://keycloak.example.com/auth/realms/istio"]

Also tried this but doesn't seem to work either:

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
 name: "request-jwt"
 namespace: y
spec:
  jwtRules:
  - issuer: "https://keycloak.example.com/auth/realms/istio"
    jwksUri: "https://keycloak.example.com/auth/realms/istio/protocol/openid-connect/certs"
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "deny-invalid-jwt"
  namespace: y
spec:
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]

Thanks in advance!

gdix0n
  • 214
  • 3
  • 13
  • 1
    Yes, it is possible. It matters a lot with your environment, the JWT that is being used, etc. I'd suggest that you turn on rbac scoped logs to debug in the envoy proxy and see the filter metadata that you get from your JWT. Maybe it is not matching the issuer in the RequestAuthentication resource at all. If it is then you should see the filter metadata that shows the information that you can apply AuthZ policies. – Rinor Dec 08 '21 at 09:21
  • Which Istio and Kubernetes version are you using? – Mikolaj S. Dec 08 '21 at 16:40
  • 1
    Which Istio and Kubernetes version are you using? Which [installation configuration profile](https://istio.io/latest/docs/setup/additional-setup/config-profiles/) did you use? How did you setup your cluster - some bare metal or cloud provider solution? This information is important to reproduce your problem. How your pod is making request to the pod in the other namespace? – Mikolaj S. Dec 17 '21 at 16:28
  • @rinor suggestions of increasing logging for rbac helped identify an issue with our keycloak setup. When we fixed that issue it all works as expected. – gdix0n Dec 23 '21 at 13:06
  • @gdix0n I added the comment as an answer, as people might not read the comments thinking that it isn't answered. – Rinor Dec 23 '21 at 15:52
  • Hi @gdix0n, does the answer from the Rinor answer your question? If yes, please consider [up-voting / accepting it](https://stackoverflow.com/help/someone-answers). – Mikolaj S. Dec 24 '21 at 08:41

1 Answers1

2

Yes, it is possible to use both Authorization Policies and Request Authentications.

But debugging is quite difficult because a lot is based on your environment and the JWT that is being used, and so on.

To troubleshoot these kinds of issues I'd start by setting the rbac scoped logs to debug for the services envoy proxy. In the rbac debug logs you'll see the data extracted from the JWT and stored into filter metadata. What you'll frequently find is that:

  • The issuer in the filter metadata might not match the one in the RequestAuthentication resource, etc.

Learn more about logging scopes here https://istio.io/v1.12/docs/ops/diagnostic-tools/component-logging/#logging-scopes

Rinor
  • 1,790
  • 13
  • 22