Skip to content

Kubernetes ConfigMaps and Secrets

In Kubernetes, externalizing configuration is a core principle for managing containerized applications. Rather than baking configuration settings into container images, operators use ConfigMaps and Secrets to decpler configuration data from application code^[400-devops__06-Kubernetes__basics__README.md].

This separation allows the same container image to be deployed across different environments (e.g., development, staging, production) simply by changing the associated configuration or secrets^[400-devops__06-Kubernetes__basics__README.md].

ConfigMaps

A ConfigMap is an API object used to store non-confidential data in key-value pairs^[400-devops__06-Kubernetes__basics__README.md]. Pods can consume ConfigMaps as environment variables, command-line arguments, or as configuration files in a volume^[400-devops__06-Kubernetes__basics__README.md].

Usage

ConfigMaps are typically used for configuration data that does not need to be treated as sensitive. For example, when deploying a database, you might use a ConfigMap to set a flag to generate a random root password^[400-devops__06-Kubernetes__basics__README.md].

Creation

The following command creates a ConfigMap named mysql in the cms namespace using literal values:

[kubectl](<./kubectl.md>) -n cms create [ConfigMap](<./configmap.md>) mysql \
--from-literal MYSQL_RANDOM_ROOT_PASSWORD=1

You can retrieve ConfigMaps using get configmaps^[400-devops__06-Kubernetes__basics__README.md].

Secrets

A Secret is an API object similar to a ConfigMap, but specifically designed to hold sensitive information such as passwords, OAuth tokens, or SSH keys^[400-devops__06-Kubernetes__basics__README.md].

Usage

Secrets are consumed by Pods in a similar way to ConfigMaps (e.g., as environment variables or volumes). However, Kubernetes handles Secrets with additional precautions to keep the data safe. In the context of containerized applications, secrets provide a mechanism to inject credentials at runtime without storing them in the Docker image^[400-devops__06-Kubernetes__basics__README.md].

For example, when deploying an application like WordPress that requires a database connection, the database credentials (host, user, password, and name) should be stored in a Secret^[400-devops__06-Kubernetes__basics__README.md].

Creation

The following commands demonstrate creating secrets for both a WordPress application and a MySQL database^[400-devops__06-Kubernetes__basics__README.md]:

# Create secret for WordPress DB connection
[kubectl](<./kubectl.md>) -n cms create secret generic wordpress \
--from-literal WORDPRESS_DB_HOST=mysql \
--from-literal WORDPRESS_DB_USER=exampleuser \
--from-literal WORDPRESS_DB_PASSWORD=examplepassword \
--from-literal WORDPRESS_DB_NAME=exampledb

# Create secret for MySQL user credentials
[kubectl](<./kubectl.md>) -n cms create secret generic mysql \
--from-literal MYSQL_USER=exampleuser \
--from-literal MYSQL_PASSWORD=examplepassword \
--from-literal MYSQL_DATABASE=exampledb

You can list secrets using kubectl -n cms get secret^[400-devops__06-Kubernetes__basics__README.md].

  • [[Environment Variables]]
  • [[Pods]]
  • [[Deployments]]
  • [[Volumes]]

Sources

^[400-devops__06-Kubernetes__basics__README.md]