Nalluri Gowtham

Posted on Jun 29

Kubernetes ConfigMaps and Secrets: Managing Application Configuration Securely

#kubernetes #devops #security #cloudcomputing

Introduction

Modern applications rely on configuration values such as database URLs, API endpoints, feature flags, and credentials. Hardcoding these values directly into application code makes deployments inflexible and increases security risks. As applications move across development, testing, and production environments, configuration often changes without requiring modifications to the application itself.

Kubernetes solves this challenge by providing two built-in resources: ConfigMaps and Secrets. ConfigMaps store non-sensitive configuration data, while Secrets are specifically designed to manage sensitive information such as passwords, API keys, certificates, and tokens.

In this article, you'll learn what ConfigMaps and Secrets are, how they work, their differences, common use cases, and best practices for securely managing application configuration in Kubernetes.

Figure 1: ConfigMaps manage non-sensitive configuration, while Secrets securely store sensitive application data.

Why Configuration Management Matters

Applications rarely use the same configuration across every environment. For example, a development environment might connect to a local database, while production connects to a managed cloud database.

If configuration values are hardcoded into the application, even a small change requires rebuilding and redeploying the application. This approach is time-consuming and difficult to maintain.

Separating configuration from application code offers several advantages:

Easier application deployment
Better security
Environment-specific configuration
Improved portability
Simplified maintenance
Faster updates without rebuilding container images

This separation is one of the key principles of cloud-native application development.

What is a ConfigMap?

A ConfigMap is a Kubernetes object used to store non-sensitive configuration data as key-value pairs.

Instead of embedding configuration inside the application, developers can store it in a ConfigMap and allow Kubernetes to provide those values to containers at runtime.

Common examples include:

Database host names
API endpoints
Application mode
Logging configuration
Feature flags
Environment variables
Port numbers

Using ConfigMaps allows the same container image to run across multiple environments by simply changing the configuration values.

How ConfigMaps Work

The process is simple:

Create a ConfigMap.
Store configuration values as key-value pairs.
Reference the ConfigMap in a Pod or Deployment.
Kubernetes injects the configuration into the running container.

Applications can consume ConfigMaps in two common ways:

As environment variables
As mounted configuration files

This makes application configuration flexible without changing the application code.

Example ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config

data:
  DATABASE_HOST: mysql-service
  DATABASE_PORT: "3306"
  APP_MODE: production

Using ConfigMaps as Environment Variables

ConfigMaps can populate environment variables inside containers.

Example:

env:
- name: DATABASE_HOST
  valueFrom:
    configMapKeyRef:
      name: app-config
      key: DATABASE_HOST

The application can now access the value just like any other environment variable.

Mounting ConfigMaps as Files

Some applications expect configuration files rather than environment variables.

ConfigMaps can be mounted as files inside a container, making them ideal for:

application.properties
config.yaml
nginx.conf
JSON configuration files

Updating the ConfigMap allows configuration changes without rebuilding the application image.

What are Kubernetes Secrets?

A Secret is a Kubernetes object designed to store sensitive information securely.

Unlike ConfigMaps, Secrets are intended for confidential data that should not be exposed openly.

Typical examples include:

Database passwords
API keys
OAuth tokens
SSH keys
TLS certificates
Private keys

Using Secrets keeps sensitive information separate from application code and reduces the risk of accidental exposure.

Types of Kubernetes Secrets

Kubernetes supports several Secret types.

Opaque Secret

The default Secret type used for storing arbitrary key-value pairs.

Examples:

Database passwords
API keys
Authentication tokens

TLS Secret

Stores:

TLS certificate
Private key

Commonly used by Ingress controllers and HTTPS-enabled applications.

Docker Registry Secret

Stores authentication credentials required to pull images from private container registries.

Service Account Token

Automatically created by Kubernetes for Pods that need to communicate securely with the Kubernetes API.

Example Secret

apiVersion: v1
kind: Secret
metadata:
  name: app-secret

type: Opaque

data:
  DATABASE_PASSWORD: cGFzc3dvcmQxMjM=

Note: Secret values are Base64 encoded by default. Base64 encoding is not encryption. For production environments, enabling encryption at rest is strongly recommended.

Using Secrets as Environment Variables

Secrets can also be injected into containers as environment variables.

Example:

env:
- name: DATABASE_PASSWORD
  valueFrom:
    secretKeyRef:
      name: app-secret
      key: DATABASE_PASSWORD

The application can securely access sensitive values during runtime.

Mounting Secrets as Files

Secrets may also be mounted as files inside containers.

This method is commonly used for:

SSL certificates
Private keys
Authentication tokens
Secure configuration files

Applications can read these files whenever required without storing sensitive information inside the container image.

Figure 2: Applications can consume ConfigMaps and Secrets through environment variables or mounted files.

ConfigMaps vs Secrets

Feature	ConfigMap	Secret
Purpose	Store non-sensitive configuration	Store sensitive information
Data	Plain configuration	Confidential credentials
Examples	URLs, ports, feature flags	Passwords, API keys, certificates
Security	Plain text	Base64 encoded by default
Best Use	Application configuration	Credentials and sensitive data

Simple rule:

Use ConfigMaps for configuration.
Use Secrets for confidential information.

Best Practices

Follow these best practices when managing application configuration:

Never hardcode passwords inside application code.
Store confidential information in Secrets.
Use ConfigMaps only for non-sensitive configuration.
Enable encryption at rest for Secrets.
Limit access using RBAC.
Rotate credentials regularly.
Avoid exposing Secrets in logs.
Maintain separate configurations for development, testing, and production.

Real-World Example

Consider an e-commerce application running on Kubernetes.

The application stores the following in a ConfigMap:

Application mode
Logging level
API endpoint
Cache timeout

The following information is stored in a Secret:

Database password
Payment gateway API key
SMTP credentials
TLS certificate

When the application moves from development to production, only the ConfigMap and Secret values change. The application container remains the same, making deployments faster, more secure, and easier to manage.

Figure 3: Separating configuration from container images makes Kubernetes deployments more secure, flexible, and easier to manage.

Frequently Asked Questions (FAQ)

1. What is the difference between ConfigMaps and Secrets?

ConfigMaps store non-sensitive configuration data, whereas Secrets are designed to store sensitive information such as passwords, API keys, and certificates.

2. Are Kubernetes Secrets encrypted?

No. By default, Secret values are Base64 encoded, not encrypted. Production environments should enable encryption at rest for stronger security.

3. Can ConfigMaps and Secrets be updated without rebuilding the application?

Yes. They can be updated independently, allowing applications to use new configuration values without rebuilding container images.

4. How can applications access ConfigMaps and Secrets?

Applications can access them either as environment variables or as mounted files inside containers.

5. When should I use a ConfigMap instead of a Secret?

Use a ConfigMap for non-sensitive configuration such as URLs, ports, and feature flags. Use a Secret whenever the data contains passwords, tokens, certificates, or other confidential information.

Conclusion

Configuration management is an essential part of deploying applications in Kubernetes.

ConfigMaps provide a flexible way to manage non-sensitive configuration without modifying application code, while Secrets securely handle confidential information such as passwords, API keys, and certificates.

By using ConfigMaps and Secrets appropriately, organizations can build secure, scalable, and maintainable Kubernetes applications that follow cloud-native best practices.

Managing application configuration securely is essential for building reliable and scalable Kubernetes deployments. While ConfigMaps and Secrets help separate configuration from application code, maintaining an efficient Kubernetes environment requires continuous resource optimization.

EcScale automatically analyzes your clusters, eliminates idle resource waste, and optimizes workload performance—helping you reduce cloud costs without compromising reliability.

Book a free EcScale demo today.
https://ecoscale.dev/#booking

⚡ EcScale: Intelligent Kubernetes resource optimization for better performance and lower cloud costs.

DEV Community