Blog
Thoughts on engineering, design, and building great products.
RBAC: Turning Identity Into Permission
Article 51 stopped where the API server knows who you are. RBAC answers the rest: what may you do. This article stands up a ServiceAccount that can only read pods in one namespace, verifies it with both kubectl auth can-i and a real token — it lists pods but reading secrets or creating pods returns 403. Then we see how a RoleBinding points at a built-in ClusterRole to scope permission to one namespace, and why the view ClusterRole deliberately can't read secrets.
Authentication and the Path Into the API Server
Every kubectl command is an HTTPS request to the API server, and before it touches data it must pass three stages: authentication, authorization, admission. This article opens Part XI with the first stage — the API server figuring out who you are. We examine the three ways our self-built cluster authenticates a request: client certificate (the one admin.kubeconfig uses), ServiceAccount token, and anonymous request — using kubectl auth whoami and real commands on the cluster.
LB IPAM and Traffic Policy
Articles 48 and 49 both stopped where the LoadBalancer Service and Gateway hung with external-IP <pending> — nobody hands out addresses on a self-built cluster. This article fills the gap with Cilium's LB IPAM: define an IP range, let Cilium assign it, and the previous Gateway flips to Programmed=True. Then externalTrafficPolicy — Cluster or Local decides whether the client's source IP survives. With a clear line between assigning an IP and advertising it.
Gateway API: The Successor to Ingress
Ingress is frozen at the basics. Gateway API is Kubernetes' new API for inbound traffic, splitting infrastructure and application roles into separate objects, and doing what Ingress can't: weighted traffic splitting, header matching, multi-protocol routing. This article enables Gateway API on Cilium, stands up a Gateway with an HTTPRoute routing by host/path, then splits traffic 80/20 between two versions — tested for real on the EC2 cluster.
Ingress: Getting HTTP In From Outside (With Cilium)
NetworkPolicy handles pod-to-pod traffic inside the cluster. This article opens the cluster edge to HTTP from outside, routing by host and path to the right Service — using Cilium's built-in Ingress controller, no extra software to install. Just as important as the mechanics is a real decision: Ingress NGINX was retired in March 2026 and the Ingress API is frozen, so we pick a maintained controller and watch how Cilium translates an Ingress into Envoy config running on eBPF.
NetworkPolicy: A Firewall By Label
By default every pod in the cluster talks freely with every other — flat and open. This article uses NetworkPolicy to lock it down: deny all ingress to a pod, then allow only the right labels through, tested for real on a Cilium cluster. And because the cluster runs eBPF, we get to watch Hubble print DROPPED/FORWARDED verdicts per packet, with Cilium identity proving policy attaches to labels, not IPs.
Migrating to kube-proxy-less Cilium
Theory's done, now for real: replace Part I's kube-proxy + bridge with eBPF-based Cilium 1.19, remove kube-proxy entirely, enable Hubble. This article traces each migration step on a live cluster — install Cilium, disable kube-proxy, confirm Services still work with not a single kube-proxy iptables rule left — plus four real traps a self-built cluster hits (providerID, topology labels, IMDS hop limit, hostNetwork) and how to clear them.