Authorization Policy in Ingress Gateway — Istio in GKE, allowing specific source for ingress.

Johanes Glenn
FAUN — Developer Community 🐾
3 min readJan 27, 2021

The why

Hi everyone, this time I want to explore a quick approach from Istio’s AuthorizationPolicy. Commonly when we create a cluster we have an idea of what this cluster intended for, especially when the cluster is public-facing and we never know who is actually reaching our services. Now, the idea is for a cluster to be able to whitelist certain IP sources that we allow to come in is the main objective of this story.

In the common networking configuration, we may straight forward think about a firewall, so that we may configure the whitelists. However, when we do talk about Kubernetes, things become more interesting especially adding Istio setup within the cluster which will automatically create TCP/UDP LoadBalancer to expose the service to the outside world in GKE.

AuthorizationPolicy

As we are able to think around how to configure allow/deny traffic to our environment we think about firewall. Well, GCP has the firewall setup for our instances, Kubernetes basically has a network policy, and Istio has AuthorizationPolicy. It is not an apple to apple comparison but in a simple way, we can think of it in that particular concept.

To have a better understanding we can see the documentation on how to implement authorization policy in Istio’s ingress gateway.

Loving the excalidraw tools to draw :D

At a very high level we can have this concept, that when we enable istio ingress gateway, GKE also prepare a network load balancer in front of it. Now (as stated on the referenced above “Authorization on Ingress Gateway”) if we want to allow certain sources as our policy, it is required for us to know the real source IP.

Which lead us to such configuration, we may enable the policy on the gateway itself (single AuthPolicy) but to have a direct source IP we require to :

  1. Use the NodePort service
  2. Let the Ingress Gateway Pod deployed to each nodes
  3. Set Istio Ingress Gateway externalTrafficPolicy: local
kubectl patch svc istio-ingressgateway -n istio-system -p '{"spec":{"externalTrafficPolicy":"Local"}}'

Then the rest is just to add AuthorizationPolicy Custom Resource into our Istio Ingress Gateway. Please change the CIDR to the source CIDR we want to allow.

Then test it out:

We can see that I put my cloud shell IP on the policy which allows the request to pass through, however my request from my machine (Yes loving the termux+VIM for now :D) is rejected.

With such a concept, we can implement more strict network traffic. Imagine if we have a certain service in front (eg. L7 Firewall, or any other inspection) and we only allow traffic in if it is coming from that specific service only. Will drop any other traffic (eg. someone trying to bypass and directly call the IP of our istio ingress gateway).

👋 Join FAUN today and receive similar stories each week in your inbox! Get your weekly dose of the must-read tech stories, news, and tutorials.

Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Published in FAUN — Developer Community 🐾

We help developers learn and grow by keeping them up with what matters. 👉 www.faun.dev

Written by Johanes Glenn

Solution Architect @AWS ex-Google Customer Engineer. Stories are my own opinion. https://linktr.ee/alevz

No responses yet

Write a response