Protect applications on Kubernetes with Istio and Azure AD

Whenever you decide to expose API of your K8s hosted applications, so it’s publicly available outside of the K8s cluster and outside of your private network, you want to protect it with authorization. When it comes to API you don’t need any login pages or SSO approaches as it happens with UI. But you want to make sure that requests to the API are authorized, meaning that the client has right to call your API. A common approach for the use cases like this one is to implement Oath 2.0 JWT authorization.

This is very common to expose API from a K8s cluster with Istio ingress gateway. Normally, there is a LoadBalancer istio-ingressgateway service with an external IP accessible from outside of the cluster. We want to protect all requests to this service on the external IP with authorization mechanism. On the other hand, for the sake of local development and user experience we want to be able to work with the API through the port forwarding without any authorization. If we can access the cluster with kubectl, then we are authorized.

We can achieve that behavior with Istio Authorization Policy:

With this policy in place all requests to the istio-ingressgateway service are required to be authenticated. All, but the requests on127.0.0.1 (localhost). So when you access the service through the port forwarding, the requests will be allowed without authentication. The rest of requests are supposed to include bearer tokens in their headers. The token should be issued by a trusted issuer. This post demonstrates how to use Azure AD as a trusted token issuer. When the request arrives to the K8s cluster, Istio validates the token by asking the issuer if the token is good with Request Authentication K8s resource:

Having Istio Authorization Policy and Request Authentication configured, we can send authorized requests to our API:

However, we are still able to access the API through the port forwarding:

That’s it!