Essential Guide to ConfigMaps and Secrets in Kubernetes

Kubernetes, the leading container orchestration platform, is designed to help developers and operators manage containerized applications at scale. It provides a suite of powerful primitives to facilitate application deployment, configuration, scaling, and management. Two of its core and often underestimated features are ConfigMaps and Secrets.

These Kubernetes-native objects are critical to building secure, scalable, and maintainable applications. They allow you to separate configuration from code and protect sensitive data such as credentials or API tokens. In modern DevOps workflows, where infrastructure and application lifecycle are tightly coupled, understanding and leveraging ConfigMaps and Secrets effectively is a must.

In this guide, we will take a look at ConfigMaps and Secrets, how they differ, how to use them properly, and how to apply best practices to improve your Kubernetes configurations and security posture. Whether you are deploying microservices, CI/CD pipelines, or internal tools, mastering these resources will boost the reliability and resilience of your systems.

🔧 Understanding ConfigMaps

What Are ConfigMaps?

A ConfigMap is a Kubernetes object used to store non-sensitive configuration data in key-value pairs. It enables you to inject external configuration into your applications without rebuilding container images. With this approach, you can easily adjust configurations between different environments like dev, staging, and production, promoting separation of concerns and twelve-factor app principles.

ConfigMaps support various input sources including literal values, files, or directories. They are ideal for application properties, flags, endpoints, URLs, and other operational settings that are safe to expose.

How Do ConfigMaps Work?

• Key-Value Store: Each ConfigMap is composed of a set of key-value pairs. Keys typically represent configuration parameters, and their corresponding values define their runtime behavior.
• Multiple Consumption Methods: ConfigMap data can be exposed to applications in three ways: as environment variables, as command-line arguments, or as mounted files.
• Scoped by Namespace: ConfigMaps are namespace-bound, meaning you can create the same ConfigMap name in multiple namespaces with different contents.
• No Automatic Reload: Applications must be explicitly coded to detect changes in mounted ConfigMaps, or restarted manually when values are updated.

Creating a ConfigMap

You can create a ConfigMap using various approaches:

Using the command line with literals:

kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2

From a YAML definition:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  key1: value1
  key2: value2

kubectl apply -f configmap.yaml

From a file:

kubectl create configmap my-config --from-file=config.properties

Using ConfigMaps in Pods

1. As Environment Variables:

containers:
  - name: my-container
    image: my-image
    env:
      - name: MY_ENV_VAR
        valueFrom:
          configMapKeyRef:
            name: my-config
            key: key1

2. As Mounted Volumes:

volumes:
  - name: config-volume
    configMap:
      name: my-config
volumeMounts:
  - name: config-volume
    mountPath: /etc/config

3. As Command Arguments (optional):

args: ["--config", "/etc/config/key1"]

Updating ConfigMaps

When a ConfigMap is updated, Kubernetes does not automatically refresh the data within running containers. You need to:

• Recreate the Pod manually.
• Trigger a rollout restart if part of a Deployment.
• Use sidecars or reloader controllers for dynamic config reloads.

Logging and monitoring changes to ConfigMaps is also recommended, especially in production environments.

🔐 Understanding Secrets

What Are Secrets?

Kubernetes Secrets are designed to securely hold sensitive data such as credentials, tokens, private keys, and connection strings. While they are similar in structure to ConfigMaps, they are intended to be treated with a higher level of protection.

Secrets in Kubernetes are base64-encoded. This obfuscation is not encryption; you should use encryption at rest and secure access controls to protect this data.

How Do Secrets Work?

• Secure Key-Value Store: Like ConfigMaps, Secrets use a key-value structure but for confidential information.
• Access Control: Secrets support fine-grained RBAC permissions, helping to restrict access.
• Volume and Env Mounts: Secrets can be injected into Pods as environment variables or mounted as files, depending on your application's needs.
• Support for Multiple Types: Kubernetes defines several types, including Opaque, kubernetes.io/dockerconfigjson, and kubernetes.io/tls.

Creating a Secret

From CLI:

kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=s3cr3t

YAML Definition:

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: YWRtaW4=  # base64 for 'admin'
  password: czNjcjNt  # base64 for 's3cr3t'

kubectl apply -f secret.yaml

From a File:

kubectl create secret generic my-secret --from-file=credentials.txt

Using Secrets in Pods

As Environment Variables:

env:
  - name: DB_USERNAME
    valueFrom:
      secretKeyRef:
        name: my-secret
        key: username

As Volume Mounts:

volumes:
  - name: secret-volume
    secret:
      secretName: my-secret
volumeMounts:
  - name: secret-volume
    mountPath: /etc/secret

Secrets volumes are mounted with permission 0400 by default for better security.

Updating Secrets

Unlike ConfigMaps, many applications are even less tolerant of changes to Secrets during runtime. Updating a Secret typically requires a Pod restart. Use mechanisms like kubectl rollout restart deployment to propagate new values safely.

🅾️ ConfigMaps vs. Secrets

Similarities

• Both store configuration as key-value pairs.
• Both can be mounted into Pods as files or exposed as environment variables.
• Both are namespaced and accessible via the Kubernetes API.
• Both can be managed declaratively via YAML and integrated into CI/CD pipelines.

Key Differences

✅ Best Practices

• Enable Encryption at Rest: Encrypt Secret data in etcd using Kubernetes' built-in encryption providers.
• Limit Exposure: Only expose Secrets and ConfigMaps to Pods that truly need them.
• Use Namespaces Wisely: Isolate workloads by namespace and apply RBAC rules to control access.
• Audit Access: Monitor and log access to Secrets to ensure compliance.
• Rotate Regularly: Periodically rotate secrets and credentials to limit risk from potential breaches.
• CI/CD Automation: Integrate ConfigMaps and Secrets into your pipelines to maintain version control and reduce manual errors.
• Avoid Secrets in ConfigMaps: Never mix sensitive and non-sensitive data.

🏁 Conclusion

Kubernetes ConfigMaps and Secrets play a vital role in application configuration and data security. They help streamline deployments, enforce separation of concerns, and protect your infrastructure against misconfiguration and data leaks.

By mastering the creation, usage, and management of these objects, you can enforce best practices across your environments and ensure a consistent and secure deployment workflow. Take the time to implement fine-grained access controls, enable encryption, and follow strong operational practices. The investment in getting this right will pay off in security, reliability, and operational efficiency.

Source

❓ FAQs

Q1: How often should I update my Secrets?
Update your Secrets whenever credentials change, access policies are updated, or as part of a regular security hygiene practice.

Q2: Can I use ConfigMaps for sensitive data?
Technically yes, but it is strongly discouraged. Secrets offer stronger access controls and encoding.

Q3: Will my app automatically detect updates to ConfigMaps or Secrets?
Not by default. You must either restart the Pod or build your app to watch for file changes.

Q4: Any performance tips for ConfigMaps and Secrets?
Keep them lightweight. Use environment variables for frequently accessed data, and avoid excessive polling from the API server.

Q5: Is there a data size limit?
Yes. Kubernetes enforces a 1MB size limit per ConfigMap or Secret. Split large data or use persistent volumes when necessary.

Q6: Can I version control Secrets?
Avoid storing Secrets in plaintext in version control. Use sealed secrets or external secret managers for versioning.

Q7: Are Secrets encrypted by default?
They are base64-encoded but not encrypted unless you enable encryption at rest explicitly.