Difficulty: Intermediate
Estimated Time: 15 minutes

ConfigMaps and Secrets

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 deployments. 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:

  1. Command line arguments
  2. Environment variables
  3. 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.

Conclusion

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.

Lessons Learned

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.

References


For a deeper understanding of these topics and more join me, Jonathan Johnson, for a transcendent experience on the No Fluff Just Stuff Software Symposium Tour.

Kubernetes ConfigMaps and Secrets

Step 1 of 7

Minikube

This Katacoda instance provides a Kubernetes based environment based on Minikube plus a client Linux Bash terminal with the Kubectl and Helm command line interface (CLI) tools.

Ensure Minikube is running and ready to accept your upcoming declarations.

minikube status