Welcome to the NZRT Wiki Podcast. Today we’re looking at Security Overview.

If you’ve spent any time working with Kubernetes, you’ll know that security isn’t just one thing you switch on. It’s a set of overlapping layers, and understanding how those layers fit together is what this episode is all about.

The core idea is this: Kubernetes security is built in depth. You’re protecting the cluster from multiple angles at the same time, covering who can access it, what traffic can flow through it, how workloads are isolated from each other, and how sensitive information is stored. Let’s walk through each of those layers.

The first layer is authentication. This is about proving who you are when you connect to the cluster. You might do that through a kubeconfig file on your local machine, through a ServiceAccount token assigned to an application running inside the cluster, or through an external identity provider using a protocol called OIDC, which stands for OpenID Connect. Think of authentication as the front door.

Once you’re through the front door, the next layer is authorisation. Kubernetes uses something called RBAC, which stands for Role-Based Access Control. This is how the cluster decides what you’re allowed to do once it knows who you are. You might be authenticated as a valid user, but RBAC is what determines whether you can actually create, read, modify, or delete specific resources.

The third layer is admission control. This is a set of gatekeepers that check requests before they’re written to the cluster. Tools here include LimitRange and ResourceQuota, which stop workloads from consuming too many resources, and a policy engine called OPA Gatekeeper, which lets you enforce custom rules across the cluster.

Layer four is the network. Kubernetes lets you define NetworkPolicies, which control exactly what traffic is allowed in and out of each pod. You can think of these as firewall rules at the pod level, giving you fine-grained control over ingress and egress traffic.

Fifth is pod isolation. This is handled through something called the SecurityContext, which is a set of settings you apply to a pod or container. At NZRT, the standard is to run containers as non-root users wherever possible and to use read-only filesystems. This limits the damage an attacker can do if they manage to get inside a running container.

The sixth and final layer is secrets management. Kubernetes Secrets store sensitive values like passwords, tokens, and API keys. The important thing here is that secrets should be encrypted at rest, meaning they’re not just sitting in plain text in the cluster’s data store. NZRT also uses external secrets managers for more advanced cases.

Now let’s talk about the NZRT-specific security baseline, because this is where those general principles get applied to our own environment.

The production namespace, which is called nzrt-prod, is restricted. Only the roles assigned to xc and dan have access to it. Secrets in that namespace are written using a format called stringData, and encryption at rest must be enabled on the cluster for this to be properly protected. All containers run as non-root where possible, as mentioned earlier. There’s also a ResourceQuota applied to nzrt-prod, which acts as a safety net to prevent any one workload from accidentally, or maliciously, consuming all available cluster resources. And ingress traffic into the cluster uses TLS, with certificates managed automatically by cert-manager using Let’s Encrypt.

Now let’s look at a few quick checks you can run to verify that security is configured correctly. These are command-line checks you’d run against the cluster.

The first check lets you ask the cluster a direct question: can a given user create pods in the nzrt-prod namespace? You’re essentially asking the cluster to tell you whether a particular action is permitted.

The second check is broader. You can ask the cluster to list all the things a user is allowed to do within the nzrt-prod namespace, giving you a full picture of their permissions.

The third check lets you inspect a specific pod and retrieve its security context settings, so you can confirm whether it’s running with the expected non-root and filesystem configurations.

And the fourth check simply lists all the NetworkPolicies that exist in nzrt-prod, so you can see at a glance whether traffic controls are in place.

None of these checks change anything in the cluster. They’re read-only inspection commands, which makes them safe to run at any time if you want to audit what’s in place.

To bring it all together, think of Kubernetes security as concentric rings. The outer ring is authentication and authorisation, controlling who gets in and what they can do. The middle rings are admission control and networking, shaping what workloads can run and how they communicate. The inner rings are pod isolation and secrets management, protecting the workload itself and the sensitive data it handles. NZRT’s baseline tries to get all of those rings working together, particularly in the production namespace where it matters most.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.