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 this series, we will be testing out several features in Istio with a local Kubernetes (k3s) cluster. Deploy k3s cluster First step is to deploy the k8s cluster with k3d - a wrapper to run k3s in docker. Start by creating a k3d config file: # k3d-istio.yaml apiVersion: k3d.io/v1alpha2 kind: Simple name: istio servers: 1 agents: 2 ports: # for exposing Istio ingress on localhost - port: 8080:80 nodeFilters: - loadbalancer - port: 8443:443 nodeFilters: - loadbalancer options: k3s: extraServerArgs: - --no-deploy=traefik # we will be using Istio ingress instead Deploy the cluster with k3d

In this article, I will be using the process of building a house as an example to explain how Kubernetes Custom Resources work. Imagine building a custom home, which is a highly detailed and laborious work, that you decided to just hire a home builder. The builder gives you a form to fill out details such as: how many rooms do you need and what size should they be?