Kubernetes dedicates two primitives to defining configuration data: the ConfigMap and the Secret. Both primitives are completely decoupled from the life cycle of a Pod, which enables you to change their configuration data values without necessarily having to redeploy the Pod.
In essence, ConfigMaps and Secrets store a set of key-value pairs. Those key-value pairs can be injected into a container as environment variables, or they can be mounted as a Volume. Figure 19-1 illustrates the options.
Figure 19-1. Consuming configuration data
The ConfigMap and Secret may look almost identical in purpose and structure on the surface; however, there is a slight but significant difference. A ConfigMap stores plain-text data, for example connection URLs, runtime flags, or even structured data like a JSON or YAML content. Secrets are better suited for representing sensitive data like passwords, API keys, or SSL certificates and store the data in base64-encoded form.
Encryption of ConfigMap and Secret data
The cluster component that stores data of a ConfigMap and Secret object is etcd. Etcd manages this data in unencrypted form by default. You can configure encryption of data in etcd, as described in the Kubernetes documentation. Etcd encryption is not within the scope of the exam.
This chapter references the concept of Volumes heavily. Refer to Chapter 7 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month, and much more.
