Difficulty: intermediate
Estimated Time: 15-20 minutes

Digital Academy Logo

Welcome to the Digial Academy's "Kubernetes Fundamentals" series. This is Module 3 - Introduction to Secrets.

In this lab, we will decouple configuration from applications with Kubernetes ConfigMaps.

Secrets are a way to deploy sensitive information to Kubernetes Pods. They are similar to ConfigMaps, but are designed for sensitive information you don't want leaking out. They can optionally be encrypted at rest.

Secrets allow you to independently store sensitive data that your application needs in a Kubernetes object. Secrets are decoupled from Pods and Deployments. In addition, Secrets can be consumed by multiple Pods and Deployments, which can be extremely useful. As an example, if you have multiple microservies that need access to the same configuration parameter, all it takes is a single Secret. This used to be accomplished with a Config-Server microservice, or supplying each microservice with the same environment variable, which made updates difficult.

Kubernetes Secrets can store simple values like usernames and passwords. They can also store credentials to access a Docker registry, OAuth tokens, and SSH keys. In general, if there is some type of secret value you need to provide, regardless of the content, you can store it as a literal value and make sure your application can consume it without using a built-in construct.

We will go through the process of creating Secrets from literal values and files. We'll supply these values to Pods as environment variables and directories.

For more information, see the Kubernetes documentation.

Developer(s): William Hearn and Zachary Seguin

Secrets are powerful Kubernetes objects that let you deploy sensitive data to Pods. There are several other use-cases that can be solved with Kubernetes Secrets.

You can encrypt secrets at rest in Etcd, and you can also deploy your secrets as hidden files.

In addition, you can provide Docker Registry credentials to all pods deployed by a Service Account, deploy SSH keys to applications, etc.

Congratulations, you now have an understang of Kubernetes Secrets next we will be taking a look at Kubernetes Persistent Volumes.

Module 3 - Introduction to Secrets

Step 1 of 4

Create Secrets from Files

Secrets enable us to provide sensitive information to running Pods. The easiest way to create them is via the command line.

We have 2 files in /resources that contain sensitive data:

cat ./resources/username

cat ./resources/password

These files are populated by running the following:

echo -n 'admin' > ./username

echo -n 'password' > ./password

Once you have these files, you can create a Kubernetes secret with the following:

kubectl create secret generic login-credentials --from-file=./resources/username --from-file=./resources/password

Now, we can view the secret with kubectl:

kubectl get secrets

We can get even more information with:

kubectl describe secret login-credentials -o yaml

Note: Kubernetes will not give us the values of the secrets, these are only provided to Pods at runtime in the form of directories and environment variables.

The actual data is stored in Etcd, by default in Base 64 encoded form. This data can be encrypted at rest, but that is beyond the scope of this lab. For more information, please see the Kubernetes documentation.

This tab will not be visible to users and provides only information to help authors when creating content.

Creating Katacoda Scenarios

Thanks for creating Katacoda scenarios. This tab is designed to help you as an author have quick access the information you need when creating scenarios.

Here are some useful links to get you started.

Running Katacoda Workshops

If you are planning to use Katacoda for workshops, please contact [email protected] to arrange capacity.

Debugging Scenarios

Below is the response from any background scripts run or files uploaded. This stream can aid debugging scenarios.

If you still need assistance, please contact [email protected]