In this post, we will be looking at how Istio handles end user authentication/authorization based on JSON Web Tokens (JWT). JWT is commonly used in OAuth2.0 flows to specify the resources a client has access to, but there are a couple of things to verify before the client is given access: Is the JWT issued by the right party Is the client who they claim to be The logic for the checks above are usually coded into the application.

There are times when applications deployed in Kubernetes need to communicate with external services that requires mTLS authentication, where the applications have to present client certificates signed by a common root/intermediate CA when accessing the service. This can lead to unpleasant scenarios where application owners have to keep track of certificates for each of their applications applications written in different language/libraries have different ways of implementing mTLS connections As an application owner, I would prefer to just deal with plain ol' HTTP on port 80, and not have to modify the application to handle HTTPS or mTLS.

I got a question on how we can restrict access to certain external endpoints on a per namespace basis. There was an idea to use Istio’s egress gateway to control access to external endpoints, though I’m not convinced that’s a valid use case for an egress gateway today. So I went off to do some investigation, and found some options: Specifying which namespaces can access certain hosts defined in the ServiceEntry Specifying which endpoints can be accessed from a namespace But before that, a bit of back story of how we got here…

In this post, we will be testing Istio’s ServiceEntry by accessing a PostgreDB database hosted externally from the Kubernetes cluster. Setup “External” PostgresDB service Since we are running the Kubernetes cluster locally in Docker containers using k3d, we can create an “external” service by running a PostgresDB Docker container on the same host and expose its ports to localhost. Create a local PostgresDB container database using Docker docker run --name postgres --restart always -e POSTGRES_PASSWORD=password -d -p 5432:5432 postgres Create a test database app_db

In the previous post, we deployed the Bookinfo application on a k3s cluster with Istio enabled. In this post, we will explore the features on Istio Ingress. Kubernetes Ingress Istio should handle Kubernetes Ingress resource just fine as documented here. Here we create a Kubernetes Ingress to access the Bookinfo application. Note the additional annotation kubernetes.io/ingress.class: istio: kubectl -n bookinfo apply -f - <<EOF apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: kubernetes.