10. ConfigMaps and Secrets

Overview

In this chapter, we will learn how to decouple application configuration data from the application itself and the advantages of taking this approach. By the end of this chapter, you will be able to define Kubernetes ConfigMap and Secret objects, run a simple Pod that uses data from ConfigMaps and Secrets, describe the advantages of decoupling configuration data from applications, and use ConfigMaps and Secrets to decouple application configuration data from the application container.

Introduction

In Chapter 5, Pods, we learned that Pods are the minimal unit of deployment in Kubernetes. Pods can have multiple containers, and each container can have a container image associated with it. This container image generally packages the target application that you plan to run. Once the developers are satisfied that the code is running as expected, the next step is to promote the code to testing, integration, and production environments.

Easy, right? One problem, however, is that as we move our packaged container from one environment to another, although the application remains the same, it needs environment-specific data, for example, the database URL to connect to. To overcome this problem, we can write our applications in such a way that the environment-specific data is provided to the application by the environment it is being deployed into.

In this chapter, we will discover what Kubernetes provides to associate environment-specific data with our application...

What Is a ConfigMap?

A ConfigMap allows us to define application-related data. A ConfigMap decouples the application data from the application so that the same application can be ported across different environments. It also provides a way to inject customized data into running services from the same container image.

ConfigMaps can be created through a literal value or from a file or all the files in a directory. Note that the primary data we stored in ConfigMaps is for non-sensitive configuration, for example, config files or environment variables.

Once a ConfigMap is defined, it will be loaded to the application via an environment variable or a set of files. The application can then see the files as local files and can read from them. It is important to note that (from 1.9.6 version onward of Kubernetes), files loaded from ConfigMaps are read-only. ConfigMaps can also hold configuration data for system applications such as operators and controllers.

In the following exercises...

What Is a Secret?

A ConfigMap provides a way to decouple application configuration data from the application itself. However, the problem with a ConfigMap is that it stores the data in plain text as a Kubernetes object. What if we want to store some sensitive data such as a database password? Kubernetes Secret provides a way to store sensitive data that can then be made available to the applications that require it.

Secret versus ConfigMap

You can think of a Secret as the same as a ConfigMap with the following differences:

1. Unlike a ConfigMap, a Secret is intended to store a small amount (1 MB for a Secret) of sensitive data. A Secret is base64-encoded, so we cannot treat it as secure. It can also store binary data such as a public or private key.
2. Kubernetes ensures that Secrets are passed only to the nodes that are running the Pods that need the respective Secrets.

   Note

   Another way to store sensitive data is a vault solution, such as HashiCorp Vault. We have left such...

Summary

In this chapter, we have seen the different ways that Kubernetes provides to associate environment-specific data with our applications running as containers.

Kubernetes provides ways to store sensitive data as Secrets and normal application data as ConfigMaps. We have also seen how to create ConfigMaps and Secrets and associate them with our containers via CLI. Running everything via the command line will facilitate the automation of these steps and improve the overall agility of your application.

Associating data with containers enables us to use the same container across different environments in our IT systems (for example, in test and production). Using the same container across different environments provides a way for secure and trusted code promotion techniques for IT processes. Each team can use a container as a unit of deployment and sign the container so that other parties can trust the container. This also provides a trusted way of distributing code not...