Welcome to the NZRT Wiki Podcast. Today we’re looking at ConfigMaps & Secrets.

If you’ve been working with Kubernetes, you’ve probably run into the question of where to store your application’s configuration. Things like environment names, URLs, log levels, database passwords, API keys — all of that has to live somewhere. Kubernetes gives you two dedicated resources for this: ConfigMaps and Secrets. They work in a similar way, but serve different purposes, and knowing which to use and when matters a lot.

Let’s start with ConfigMaps. A ConfigMap is where you store non-sensitive configuration data. Think of it as a key-value store that your application can read at runtime. In NZRT’s setup, you might have a ConfigMap called app-config sitting in the nzrt-prod namespace. Inside it, you’d find entries like the application environment set to production, the application URL pointing to the NZRT network app endpoint, and a log level set to info. None of that is sensitive — it’s just configuration your app needs to know about.

To actually use that ConfigMap inside a pod, you reference it in your pod definition using something called envFrom. What that does is tell Kubernetes to pull all the key-value pairs from the ConfigMap and inject them into your container as environment variables. Your app then reads them just like any normal environment variable — it doesn’t need to know or care that they came from Kubernetes.

Now let’s talk about Secrets. The concept is the same — key-value pairs injected into a pod — but Secrets are designed for sensitive data. Passwords, usernames, tokens, API keys. In the example from the wiki, there’s a Secret called db-credentials, again in nzrt-prod. It holds a database password and a database username. You’ll notice the wiki uses something called stringData, which means you write the values in plain text in your definition file, and Kubernetes automatically base64-encodes them when it saves them to the cluster. Using a Secret in a pod works exactly the same way as a ConfigMap — you use envFrom, but this time you reference a secretRef instead of a configMapRef. The end result is the same: your container sees those values as environment variables.

Now here’s something really important you need to understand about Secrets, and the wiki flags this clearly. Secrets are not encrypted by default. They’re only base64-encoded when stored in etcd, which is Kubernetes’ internal data store. And base64 is not encryption — it’s just encoding. Anyone with access to etcd can decode those values trivially. So for production environments, you need to go further. There are two main approaches. First, you can enable Encryption at Rest on your cluster, which tells Kubernetes to actually encrypt the Secret data before writing it to etcd. Second, and often better for serious deployments, you use an external secrets manager. Tools like HashiCorp Vault, AWS Secrets Manager, or Sealed Secrets are purpose-built for this and give you much stronger security guarantees, audit trails, and access controls.

Finally, let’s cover a few kubectl commands you’ll use regularly when working with these resources. To list all ConfigMaps in the nzrt-prod namespace, you run kubectl get configmaps with the namespace flag. For Secrets, same structure — kubectl get secrets with the namespace flag. If you want to inspect a specific Secret, you use kubectl describe followed by the Secret name and namespace — this shows you metadata and keys but not the actual values, which is intentional. And if you need to create a Secret quickly from the command line without a YAML file, you can use kubectl create secret generic, give it a name, pass in your key-value pairs using the from-literal flag, and specify your namespace. That’s a handy shortcut for quick setups or testing.

To link this back to broader context, ConfigMaps and Secrets connect closely to the Security Overview and Storage Overview docs in the wiki, so if you want to go deeper on cluster security or how persistent data is handled, those are your next stops.

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