Centrally manage kubernetes ConfigMaps and secrets

Kubernetes (K8s) ConfigMaps allow you to separate your application configuration data from your pod deployments. There are various ways to create ConfigMaps with kubectl and Kustomize. This guide focuses on techniques to centrally manage your kubernetes ConfigMaps data across your organization’s multiple applications and environments.

ConfigMaps for Multiple Environments with GitHub

One method for centrally managing ConfigMap data is to store your properties files or configmaps in GitHub. You have the option of creating a repository per environment. Alternatively, you can create a single repository that contains multiple branches for each environment your applications are running in.

This example repository has a directory containing config data properties files from the official K8s ConfigMap documentation. There are three unique branches that map to environments production, staging and development. The development environment game.properties file has custom values for keys lives and secret.code.lives.

enemies=aliens
lives=100
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=1000 

You can modify and check-in application values specific to your environment. This allows you to have visibility and source control over your configuration. You can create a ConfigMap from the directory by checking out your specified branch. Then run the kubectl create command in the directory.

As an example, if we wanted to create a ConfigMap for our development environment we would check out the development branch:

git checkout development
Switched to branch 'development'
Your branch is up to date with 'origin/development'.

Then create a ConfigMap directly from the game-demo directory with kubectl create which contains the development values for the game.properties file and additional ui.properties file.

kubectl create configmap game-demo --from-file=.

You now have a ConfigMap containing Data from both files for the development environment. The created ConfigMap looks like the following:

Name:         game-demo
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
game.properties:
----
enemies=aliens
lives=100
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=1000

ui.properties:
----
color.good=purple
color.bad=yellow
allow.textmode=true
Events:  <none>

ConfigMaps for Multiple Environments with CloudTruth

An alternative approach is to use a Configuration Management hub like CloudTruth to centrally view and manage your ConfigMaps across an endless number of projects and environments.

CloudTruth allows you to create projects that act as a namespace for your configuration data parameters and set specific values across multiple environments.

We set up a project in CloudTruth that contains our game demo parameters and have selected the development environment.

We can use CloudTruth’s ability to transform data with templates and create a ConfigMap yaml that will dynamically populate values from any number of outlined environments. This gives us a central location to view, audit and manage values for all of our applications and environments.

Using the CloudTruth CLI we get the ConfigMap template and dynamically populate values by specifying the project and environment. Then, we can redirect the output to kubectl apply to create the application ConfigMap.

kubectl apply -f <(cloudtruth --project configmap --env production templates get game-demo)

Dynamically Create, Update, and Manage your K8s ConfigMaps Data and Secrets

We can also take all the manual steps, and mistakes they can bring, out of the picture with an automated Kubernetes operator that syncs with CloudTruth to dynamically build and update K8s ConfigMaps and Secrets. We call the operator KubeTruth and it allows a completely customizable experience to ConfigMap and Secrets management.

KubeTruth will automatically create ConfigMaps and secrets based on the project and environment layout built within CloudTruth. Updates to parameters and values in CloudTruth will automatically be propagated to ConfigMaps and secrets allowing you a single point of management across all of your K8s clusters, environments, and services configuration data.

Secrets Management with CloudTruth

Kubernetes secrets can be managed with the same methods discussed above. A downside to the GitHub method is that you don’t want to store secrets unencrypted in GitHub.

With CloudTruth, you can store secrets in our secrets manager which is protected with a dedicated Vault. Alternatively, you can create external references to your own secret manager with CloudTruth integrations. As a result, you can continue to use your existing services along with CloudTruth methods to centrally manage your kubernetes ConfigMaps data and secrets.