CloudAcademy
  1. Home
  2. Training Library
  3. Containers
  4. Courses
  5. Introduction to Kubernetes

Secrets and Config Maps

The course is part of these learning paths

Certified Kubernetes Administrator (CKA) Exam Preparation
course-steps 4 certification 2 lab-steps 6
Introduction to Kubernetes
course-steps 1 certification 1 lab-steps 2

Contents

keyboard_tab
Course Introduction and Overview
Production and Course Conclusion
10
play-arrow
Start course
Overview
DifficultyAdvanced
Duration1h 28m
Students2515

Description

Introduction 
This course provides an introduction to how to use the Kubernetes service to deploy and manage containers. 

Learning Objectives 
Be able to recognize and explain the Kubernetes service 
Be able to explain and implement a Kubernetes container
Be able to orchestrate and manage Kubernetes containers 

Prerequisites
This course requires a basic understanding of cloud computing. We recommend completing the Google Cloud Fundamentals course before completing this course. 

Transcript

Hello and welcome back to the Introduction to Kubernetes course for Cloud Academy. I'm Adam Hawkins and I'm your instructor for this lesson.

This is the last lesson in the feature walkthrough section of the course. Now we're covering Secrets and ConfigMaps. Both are powerful for your toolbox. We'll do a short demo of each and cover those use cases. Specifically we'll demo populating an environment variable from a Secret value and also populating an environment variable from a shared configuration value. Anyways, first up, secrets.

A secret is an object that contains a small amount of sensitive data such as a password, a token or an SSH key. Such information might otherwise be in a pod-specification or an image. Putting it in a secret object allows for more control over how much to shield and reduces the risk of accidental exposure. A pod needs to reference a secret to use one. A secret can be used in a pod in three ways: first, it files as a volume, second, as an environment variable or third, as authentication to a doc or registry. Let's do a short demo. We don't need the entire sample application for this exercise, just a simple pod will do. Kubectl includes a handy command to create secrets. Let's use that to encode a fake API key and use it an an environment variable.

Create a new namespace for Lesson 205 like we've done in the past lessons. Use kubectl create secret to create encoded secrets from literal values. Note that one secret may contain multiple values. In a sense, a Secret is a dictionary of keys and values.

Now to create the pod. Create a new pod.yml file with your editor. We'll start with the basic pod like we used earlier. The image and other bits are irrelevant for this exercise. We just need a pod with a container to set environment variables on. Fill in the pod up until the env key. It's straightforward to use secrets as environment variables. Start by declaring an env entry like we've used before. This time, use valueFrom instead of value. Use secretKey and set the name and key to values from the previous step. Here we declare the environment variables from the two values in the API key secret.

Create the pod and then inspect environment variables with kubectl exec. We can see that our process has the assigned plain text environment variables. There isn't really much else to demo with secrets. They are simple to use and you'll undoubtedly use them eventually.

Now onto configMaps. The configMap is similar to secrets but designed for more convenient support working with strings that do not contain sensitive information. ConfigMaps hold key-value pairs of configuration data that can be consumed in pods or used to store internal data for Kubernetes components. I like to use configMaps because they provide a central place for a shared configuration value, such as the environment, e.g. production or staging. Configuration data can be consumed in pods in a variety of ways. ConfigMaps can be used to populate environment variables or config files in a volume. Let's create a configMap and add some data to our demo pod.

Create a new config-map.yml file with your editor. ConfigMaps start off just like all other resources, except they have a datakey instead of a spec. The structure is similar to secrets. Again, we have a dictionary of key-value pairs. I've added dots to my keys to demo how to "group keys together." Here we have an entry for log_level and stage. Save the file and create it with kubectl.

Reopen pod.yml in your editor. Previously we added environment variables that come from secrets. We can use the same strategy for configMaps. Just use configMapKeyRef instead of secretKeyRef. Unfortunately environment variables cannot be changed on a running pod. So save the file, delete the pod, and recreate it with kubectl. Now use kubectl exec to check the container's environment variables. Here we can see the log level and stage environment variables populated correctly.

This concludes a short walk-through on configMaps and secrets. There are useful things you'll encounter in your day-to-day Kubernetes use. Here's a short recap. Secrets store sensitive data. ConfigMaps group key and value configuration data. And both can provide data to pods. We didn't cover using configMaps as volumes. I suggest you repeat this exercise and use configMaps to specify a volume. This is primarily for populating entire configuration files. Check the guides for a complete walkthrough. Also this lesson concludes the technical section of the course. All of the lessons were designed to prepare you as an end-user to manage and deploy applications on Kubernetes.

The next lesson focuses on what you need to know to actually put those applications into production. So you're almost there. Almost at the finish line. Congrats! Join me for the next lesson and we'll cross it together.

About the Author

Students4785
Courses4
Learning paths1

Adam is backend/service engineer turned deployment and infrastructure engineer. His passion is building rock solid services and equally powerful deployment pipelines. He has been working with Docker for years and leads the SRE team at Saltside. Outside of work he's a traveller, beach bum, and trance addict.

Covered Topics