The 3rd factor (Configuration) of the Twelve-Factor App Methodology states:
Configuration that varies between deployments should be stored in the environment.
The last place the source of truth for a configuration would be inside the application, container or Pod since these artifacts are deployed to a variety of places with a variety of changing contexts. Anything that is configurable, changeable or varies between contexts should be submitted separately for each deployment. By not putting the configuration in the codebase, this also protects the 1st factor (Codebase):
There should be exactly one codebase for a deployed service with the codebase being used for many deployments.
Since your deployed containers have no context, that information needs to be supplied when the containers start. Context information can typically include names of other services, database locations, service URLs, running modes, feature enable/disable requests. Sensitive context information can include passwords, account IDs, security tokens, and the like.
This is where Kubernetes ConfigMaps and Secrets can help by supplying your deployment containers with the contextual and secretive information they require.
A core component of the Kubernetes management plane is etcd. Etcd is a high-available, distributed key/value store ideal for contextual environment settings and data. The ConfigMaps and Secrets are simply interfaces for managing this information in etcd.
Pods provide containerized applications access to ConfigMaps and Secrets with three techniques:
- command-line arguments
- Environment variables
- Files in a volume
In the following steps you will learn:
- how to create configuration data in the form of ConfigMaps and Secrets,
- how Pods make configuration accessible for applications in containers,
- how secrets should remain secrets.
Keeping configurations and secrets out of your codebase is an important guideline for application on Kubernetes. Kubernetes can be deployed to a variety of data center targets and your application should also accommodate these different contextual settings. You learned, the environment configuration can all be stored in ConfigMaps and Secrets. This allows your applications to reference these configurations as environmental resources.
Secrets and Protection
If you are interested in storing secrets safely in version control, consider this approach "Sealed Secrets" for Kubernetes.
Since secrets are stored in etcd it's recommended to separate and firewall your etcd cluster. This is an advanced administration topic for Kubernetes, but it's important to keep your secrets secret. See 11 Ways (Not) to Get Hacked.
Lastly, enable RBAC and protect your Kubernetes API. Unprotected access to the cluster, such as through the dashboard, can unveil secrets. Invest in protecting your Kubernetes cluster and avoid what others have done in the past Lessons from the Cryptojacking Attack at Tesla.
With these steps you have learned:
- ✔ how to create configuration data in the form of ConfigMaps and Secrets,
- ✔ how Pods make configuration accessible for applications in containers,
- ✔ how secrets should remain secrets.
- Free PDF of Kubernetes Up & Running: CHAPTER 11, ConfigMaps and Secrets
- Configuring Redis using a ConfigMap
- Storage of secrets as plain text in etcd
Kubernetes ConfigMaps and Secrets
Your Kubernetes Cluster
For this scenario, Katacoda has just started a fresh Kubernetes cluster for you. Verify it's ready for your use.
kubectl version --short && \
kubectl get componentstatus && \
kubectl get nodes && \
The Helm package manager used for installing applications on Kubernetes is also available.
helm version --short
You can administer your cluster with the
kubectl CLI tool or use the visual Kubernetes Dashboard. Use this script to access the protected Dashboard.