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.
HAProxy Consolidates Three API Servers, and Remote kubectl
Three api-servers are running, but clients need to know which one to call. This article stands up HAProxy on lb-0 to consolidate them into a single address in TCP passthrough mode — preserving end-to-end mTLS, then configures kubectl on your laptop to point at the Elastic IP and sets up the RBAC so the api-server can call down to the kubelet.