Kubernetes ConfigMaps & Secrets

A ConfigMap is a Kubernetes API object used to store non-sensitive configuration data for pods.

ConfigMaps allow you to decouple configuration from application code and images.

A Secret is a Kubernetes API object used to store sensitive information such as passwords, tokens, or TLS keys.

Secrets help keep sensitive data out of source code and container images.

Configuration is the environment-specific or runtime-specific settings an application needs to run properly.

Runtime configuration includes environment variables, settings files, and dynamic data used while the app runs.

A pod is the smallest deployable unit in Kubernetes and usually contains one or more tightly-coupled containers.

Pods can consume ConfigMaps through environment variables, command-line arguments, or mounted files.

Pods consume Secrets similarly to ConfigMaps: as environment variables, mounted files, or projected volumes.

A ConfigMap is for non-sensitive config. A Secret is for sensitive config and is stored in a way that is handled more securely.

Kubernetes stores Secret data base64-encoded in the API, and in many setups additional protections such as encryption are enabled at rest.

A Secret object is a Kubernetes resource containing sensitive data stored as key-value pairs.

A key-value pair maps a name to a value, often used in ConfigMaps and Secrets.

A ConfigMap key is the name of a data item, similar to a property name.

A Secret key is the name of a sensitive data item stored inside a Secret object.

A ConfigMap file mount injects ConfigMap data as files in a container filesystem.

A Secret file mount injects Secret data into a mounted volume as files.

Environment variable injection absorbs ConfigMap or Secret data and exposes it as environment variables inside a container.

A projected volume takes data from multiple sources such as ConfigMaps and Secrets and mounts them as files.

The kubectl apply command creates or updates Kubernetes resources declaratively.

It creates a ConfigMap from literal values, files, or directories.

It creates a Secret from a literal, file, or generated data.

A ConfigMap YAML manifest declares the object and includes its data.

A Secret YAML manifest declares the secret and its data.

A ConfigMap usually has:

• apiVersion
• kind: ConfigMap
• metadata
• data

A Secret usually has:

• apiVersion
• kind: Secret
• metadata
• type
• data or stringData

Because they let configuration be changeable without rebuilding the container image.

Because credentials should not be embedded in container images or source repositories.

A config file mount allows an application to read configuration from a filesystem path rather than environment variables.

A secret file is mounted into a container’s filesystem as a protected file.

By default, updates to ConfigMap data are propagated to mounted files and env vars in a way that depends on mount and refresh behavior.

Because environment variable names or file names must be valid and stable for the application.

A mounted config volume places ConfigMap data in a directory inside the container.

Environment variables are exposed as process variables. File injection makes configuration available as files on disk.

Some applications read config files rather than environment variables.

They are easy to consume in many traditional apps and containers.

A secret volume is a filesystem mount that contains secret data files.

A projection volume combines multiple data sources into a single mount path.

A pod can pass ConfigMap values as command-line arguments to a container entrypoint.

A Secret can also be used as an argument if the application expects it, though file-based or env var approaches are more common.

A mount path is the container filesystem location where a volume is mounted.

A volume mount is a field inside a container definition that connects a volume to a path.

A volume is a directory or file mount provided to containers in a pod.

A pod spec is the Kubernetes manifest describing the pod, containers, volumes, and other runtime properties.

It is a file inside a mounted volume or environment variable whose contents come from the ConfigMap data.

A mirrored config is a common pattern where the application reads configuration files from a mounted volume.

ConfigMap is intended for non-sensitive data. Secret uses special handling and often more restricted access semantics.

The stored value is not a plain string in the object, although it is decoded by clients when they read it.

stringData is a convenient field for writing plaintext values in a Secret manifest, which Kubernetes then converts internally.

It can accidentally expose secrets in YAML files and shell history if not handled carefully.

A Secret type indicates the intended purpose of the secret, such as Opaque, kubernetes.io/tls, or Docker config.

An Opaque Secret is the default form, used for arbitrary key-value pairs.

A TLS Secret contains a TLS certificate and private key for ingress or internal TLS use.

Because they often contain certificate and key files that applications or ingress controllers expect.

A Docker registry Secret stores credentials for pulling private images from a registry.

ConfigMaps and Secrets are Kubernetes resources; environment variables are the process-level view of their data.

It allows environment-specific configuration without altering the base image or code.

It keeps credentials and keys separate from source code and deployment manifests where possible.

The Kubelet is the node agent that ensures the pods and containers described in the API are running correctly.

It is responsible for mounting ConfigMaps and Secrets into pods as files or environment variables.

It mounts or injects the Secret data into the pod, while taking steps to restrict access.

Because it may expose credentials or certificates to processes inside the container.

Secrets are often mounted with restricted permissions to reduce accidental exposure.

It refers to how modified ConfigMap data is refreshed in running pods.

It refers to how Secret values are rotated and reflected in running pods.

It determines whether updated ConfigMap or Secret data is refreshed automatically or requires a pod restart.

Because configuration and secret changes may need rollout or restart coordination.

A rolling update gradually replaces old pods with new ones, often used for config or secret changes.

A pod restart recreates the container so it picks up updated config or secret values.

Because certain mounts and env vars are set at pod startup and may not change live without restart.

A subPath mount is a mount of only a specific file or directory from a volume into the container.

A file from a mounted ConfigMap or Secret may be placed into a specific destination inside the container.

A projected volume creates a single directory containing files from multiple ConfigMaps and Secrets.

It simplifies the configuration of multiple data sources into one place.

It means a running pod sees the updated data, either via file refresh or by restart depending on Kubernetes behavior.

Because infrastructure and app behavior can vary across environments without recompiling the app.

A config that differs across dev, staging, and prod, such as database URLs or log levels.

Hostnames, feature flags, service URLs, or log levels.

Passwords, certificates, tokens, or private keys.

Pods, Deployments, DaemonSets, Jobs, and CronJobs commonly consume ConfigMaps.

Pods, Deployments, StatefulSets, and Ingress often consume Secrets.

This separation encourages a security-sensitive workflow and easier configuration management.

A kubelet-managed volume is mounted by the Kubelet and exists as part of the pod runtime.

Annotations can trigger sidecars or controllers to populate secrets or config into pods.

A ConfigMap or Secret can be created, updated, read, used by pods, and eventually deleted.

Because workloads reference them and may fail if the config source does not exist.

Because the pod may fail to start if required secret files or env vars are missing.

A stale configuration is an old or outdated config value still being used by the application.

A stale secret is an old credential that remains active or still mounted when it should be rotated.

Secret rotation is replacing old credentials or tokens with new ones and updating workloads to use them.

Because old secrets may be exposed or expire and need regular replacement.

Mounted secret files are persisted on disk. Env vars are present in process environment and easier to read via process inspection.

Because some tools and runtimes expect files, and file permissions can be restricted.

Because they are simple to pass into applications and CI/CD automation.

A secret manager is an external service or controller that manages secrets and integrates with Kubernetes.

External Secrets Operator syncs external secrets from systems such as AWS Secrets Manager or HashiCorp Vault into Kubernetes Secrets.

Vault is a secret manager used to securely store and manage secrets.

Because K8s Secrets are helpful but may be complemented by centralized secret lifecycle management.

To protect Secrets data even if the underlying storage or etcd is compromised.

etcd is the key-value store used by Kubernetes to persist cluster state and object data.

Because it stores Kubernetes resources, including Secrets, and therefore must be protected.

It is a feature that encrypts Secret values before they are stored in etcd.

KMS (Key Management Service) is often used to store the encryption key used for Kubernetes Secret encryption.

Because etcd can be a high-value target and should not expose raw secret data if compromised.

It defines which users, controllers, or workloads can access or modify the Secret.

RBAC (Role-Based Access Control) restricts who can create, read, update, or delete Kubernetes resources.

A Role grants permissions within a namespace.

A ClusterRole grants permissions across the whole cluster.

Because not everyone should be able to read or modify sensitive configuration.

A service account is an identity used by pods to interact with the Kubernetes API or other services.

A pod may need permissions to read secrets or config sources depending on the environment.

Secret-mounted files often have mode 0444 or similar settings so they are readable but not writable.

The file mode determines read/write access permissions of the mounted secret files.

ConfigMap volumes are often mounted with read-only permissions as well.

It is how Kubernetes updates mounted or injected Secret values in a running pod.

It is how Kubernetes updates config files or env vars from ConfigMaps in a running pod.

Because Kubernetes may require a pod restart or rely on specific volume or env var behavior.

A projected volume can include multiple source objects, like ConfigMaps and Secrets, in one mount.

A Symmetric Secret is a secret used by a single app or workload and is often created as a generic Opaque secret.

A TLS Secret commonly contains:

• tls.crt
• tls.key

Because ingress controllers and TLS clients expect those standard file names.

Ingress controllers use TLS Secrets to terminate TLS and serve certificates.

A Docker config Secret stores credentials for a private registry used by the Kubernetes runtime to pull images.

Because private registries require authentication and should not expose credentials in publicly visible manifests.

ConfigMaps can also contain binary-like data, though the common pattern is textual key-value data.

A Secret can store binary data as base64-encoded values.

This modularity keeps config reusable and allows config changes without altering deployment logic.

A values file often contains environment-specific parameter values used by Helm or other templating tools.

Helm is a package manager for Kubernetes that often manages ConfigMaps and Secrets via templates.

Because Helm charts frequently generate ConfigMap and Secret manifests for application deployment.

Kustomize is a Kubernetes manifest customization tool used to merge config overlays and generate ConfigMaps/Secrets.

Config and secret values are often version-controlled, but sensitive content should not be stored in plain text without safeguards.

GitOps uses Git as the source of truth for declarative infrastructure and app configuration, which often includes ConfigMaps and Secrets.

Because plain text Secrets in Git repositories can leak credentials if not managed carefully.

It moves secret material from external systems into Kubernetes Secrets without storing it directly in Git.

Avoid committing plaintext credentials, certificate private keys, or other sensitive values.

It is the rendering of Secret values from environment variables or templates before applying to Kubernetes.

Because plaintext values may end up in logs, shell history, or source-control artifacts.

A secret generator can create secret data dynamically during deployment, often via tools like Kustomize or external systems.

A config generator creates ConfigMaps from files or environment values for application settings.

Mounted ConfigMap files are more suitable for file-based applications; env var injection is easier for simple config values.

The filename is often derived from the key and can be used by applications directly.

Some applications can reload config when the files or directories are updated.

Ephemeral config may be built into images or generated at runtime; persistent config is typically managed through ConfigMaps or external stores.

Dynamic secret injection uses controllers or sidecars to make secrets available without static manifests.

It can expose several Secret keys to a single mount directory in a structured way.

This is common in Java and other frameworks and maps naturally to ConfigMap file mounts.

A ConfigMap may hold keys representing config settings, such as database.url, log.level, or feature.x.enabled.

A Secret remount is when Kubernetes updates the mounted Secret and the pod’s filesystem reflects the new values.

A kubelet token is used by the node to authenticate to the API server.

Because the app should not be tightly coupled to environment-specific values or private keys.

Network policy can restrict which pods can talk to which services, but it does not replace RBAC for API access.

A namespace defines a logical boundary for resources, including ConfigMaps and Secrets.

To isolate teams, workloads, and environments and control access to config and secret resources.

A pod can access secret volumes or env vars only if configured in the pod spec and permitted by policy.

A cluster-wide secret is available across namespaces or at a cluster scope when defined accordingly.

A namespaced Secret is created in a specific namespace and visible only within it unless further exposed.

A service account token is automatically mounted into pods and can be used to access the Kubernetes API, making it sensitive.

Because if abused, it can be used by a compromised pod to interact with the cluster.

It is a Secret containing the token used by the pod to authenticate with the cluster API.

Because broad token access can allow unauthorized cluster actions.

A security context can restrict privileges and filesystem access inside the pod.

A readiness probe can help ensure the app is starting with the latest ConfigMap values before traffic is routed to it.

A deployment may restart pods to refresh config when mounted ConfigMaps or Secrets are updated.

Some apps can reload configuration files without restarting, but this is application-specific.

Because applications may need to re-read or use new credentials after rotation.

It automates the creation of new secrets and updates workloads or applications to use them.

Secret versioning tracks multiple versions of a secret so workloads can transition smoothly between old and new values.

Immutable config avoids surprise drift and makes changes explicit and reviewable.

It defines how config is updated, what triggers rollout, and how to validate the new values.

It usually includes generating the value, storing it securely, creating the Secret object, and updating the workload to consume it.

Because generating secrets with low entropy or in unsafe contexts can produce weak credentials.

A generated Secret is created automatically by tools or controllers, often with strong randomness.

A checksum can be used to trigger a pod restart when ConfigMap or Secret content changes.

It is a common pattern where a deployment annotation includes the hash of config to trigger rollout.

Because it ensures workloads restart after config changes that require reloading.

It provides reproducibility, reviewability, and operational consistency for K8s objects.

It improves consistency and integration with GitOps while still requiring secure handling of the actual secret data.

Because they decouple environment-specific behavior from the image and provide the data plane needed for reliable, configurable, and secure workloads.

Do not store private data in plain text in Git, build pipelines, or image history when a more secure secret workflow is available.

It encrypts Secret data before persisting it in etcd, using a configured KMS or encryption provider.

It is the plugin or service that provides the actual encryption and decryption for API object data.

Because if etcd is compromised, Secrets may be accessible unless encryption at rest is enabled.

It is the chain from Secret object storage to the kubelet to the mounted file or env var seen by the container.

Because it handles mounted data and thus must be trusted to preserve secret confidentiality and correctness.

It validates that a projected Secret or ConfigMap is mounted and any referenced data keys exist.

It occurs when an application expects a file or env var that does not exist in the mounted Secret.

It occurs when mounted Secret files are readable by unintended processes or users.

It is a malicious process or actor attempting to manipulate config or secret values in a pod or cluster.

It is an attempt to alter config content in ways that change runtime behavior or exploit assumptions in the app.

Because they constrain who can read, create, or update configuration and sensitive values.

Pod security admission enforces baseline security restrictions on pod creation based on policy.

It enforces more stringent controls such as no privilege escalation, no root, and restricted capability usage.

Because apps running as root can access more sensitive files and may have broader privilege over mounted Secrets.

Because configuration changes may be routine and low-risk, while secret changes require rotation and stricter governance.

Some patterns use reloading and hot updates, but many applications still require a restart or reload hook.

Because running pods may hold stale in-memory copies of secret data and need coordinated reloading.

Stale or forgotten secrets can remain valid longer than intended, increasing exposure.

It integrates Kubernetes Secrets with platforms like Vault, AWS Secrets Manager, or GCP Secret Manager.

Configuration should be externalized and Governed; secrets should be isolated, protected, rotated, and tightly controlled, while ConfigMaps stay flexible and environment-driven.