Skip to main content
Back to Library
mastering ckad certified kubernetes application developer

ConfigMaps and Secrets

3 min read Chapter 46 of 87
Summary

Introduces the principle of externalizing configuration following the...

Introduces the principle of externalizing configuration following the twelve-factor app methodology, explains why baking config into images creates fragile, environment-specific artifacts, and previews ConfigMaps for non-sensitive data and Secrets for credentials. Connects both topics to the CKAD Configuration domain (18% weight).

ConfigMaps and Secrets

Every non-trivial application needs configuration: database connection strings, feature flags, log levels, API endpoints, TLS certificates. The question is where that configuration lives.

One approach is to hardcode values into the application source code. This works until you need different values in staging versus production, at which point you maintain parallel builds or wrap everything in conditionals. Another approach is to bake configuration into the container image — a custom application.properties file, a .env file copied at build time, environment variables set in the Dockerfile. This eliminates source-code changes but creates a different problem: every environment gets its own image tag, and a configuration change triggers a full image rebuild.

The twelve-factor app methodology, distilled from building and running thousands of SaaS applications, calls this out as Factor III: store config in the environment. Configuration should be strictly separated from code. The same container image should run in development, staging, and production — the only difference is the configuration injected at deploy time.

Kubernetes provides two primitives for this purpose: ConfigMaps and Secrets.

ConfigMaps: Non-Sensitive Configuration

A ConfigMap is a Kubernetes API object that stores key-value pairs of non-sensitive configuration data. Database hostnames, log levels, feature toggles, entire configuration files — anything that is not a credential belongs in a ConfigMap. Pods consume ConfigMaps as environment variables or as files mounted into the container filesystem.

The key property of ConfigMaps is that they decouple configuration from the container image. You build the image once, push it to a registry, and then inject different ConfigMaps in different namespaces or clusters. The same api-server:v2.3.0 image runs everywhere; only the ConfigMap differs.

Secrets: Sensitive Configuration

Secrets follow the same structural pattern as ConfigMaps — they store key-value pairs and Pods consume them identically — but they carry different semantics. Secrets are intended for sensitive data: passwords, OAuth tokens, SSH keys, TLS certificates. Kubernetes stores Secret values as base64-encoded strings and can restrict access through RBAC policies.

It is critical to understand what Secrets are not: they are not encrypted at rest by default. Base64 encoding is not encryption. Without additional measures (etcd encryption, external secret operators), anyone with API access to the namespace can read Secret values. The CKAD exam tests your ability to create and consume Secrets — the operational hardening is a CKA/CKS concern, but awareness of the limitation matters.

What This Chapter Covers

The following sections provide:

  • ConfigMap Creation and Consumption: Creating ConfigMaps from literals, files, and env-files. Consuming them via environment variables (envFrom, valueFrom) and volume mounts. Understanding update semantics and immutable ConfigMaps.

  • Secrets: Types, Creation, and Security: Working with Opaque, TLS, and Docker registry Secrets. Creating, decoding, and consuming Secrets. Security implications of environment variables versus volume mounts.

Both topics fall within the CKAD “Application Environment, Configuration, and Security” domain, weighted at 25% of the exam. Expect at least two or three tasks involving ConfigMaps and Secrets on exam day.