Cloud Native DevOps with Kubernetes

Chapter 10. Configuration and Secrets

If you want to keep a secret, you must also hide it from yourself.

George Orwell, 1984

It’s very useful to be able to separate the logic of your Kubernetes application from its configuration: that is, any values or settings that might change over the life of the application. Configuration values commonly include things like environment-specific settings, DNS addresses of third-party services, and authentication credentials.

While you could simply put these values directly into your code, that’s not a very flexible approach. For one thing, changing a configuration value would require a complete rebuild and redeploy of the application. It’s much better to separate these values out from the code and read them in from a file, or from environment variables.

Kubernetes provides a few different ways to help you manage configuration. One is to pass values to the application via environment variables in the Pod spec (see “Environment Variables”). Another is to store configuration data directly in Kubernetes, using the ConfigMap and Secret objects.

In this chapter we’ll explore ConfigMaps and Secrets in detail, and look at some practical techniques for managing configuration and secrets in applications, using the demo application as an example.

ConfigMaps

The ConfigMap is the primary object for storing configuration data in Kubernetes. You can think of it as being a named set of key-value pairs that stores configuration data. Once you have a ConfigMap, ...