In the latest installment of our “How to K8s” series, Kubernetes Secrets Made Simple, we took a deep dive into the ins and outs of Kubernetes Secrets. In doing so, we covered the manual process of creating Secrets and associating them with a given Pod by mounting the Secret as a Volume.

Today, we’ll cover a more direct, but less explicit approach to a very similar task. We’ll create a Secret via the kubectl CLI, and set the contents of the Secret as environment variables in a given Pod.

Best Practices vs. First Practice Exercises

Best practices are important, and things like writing secrets to text files are highly discouraged, as this creates a plain-text version of the secret that can be easily compromised. However, this post is meant to be a practical introduction rather than a production-ready recipe.

The best practice that this series will explore soon is to never expose secrets. This is easier said than done, and implementation is a source of some debate. With that said, on to the first learning exercise.

Create files to pass in the creation of the Secret

To define a Secret via the kubectl CLI, we will first have to create files containing the private information we want to pass to the Secret. So, if we have the following values to pass:

"username": "admin"
"password": "MacStadium"

We can run the following to generate what we need to pass those values to our Secret:

$ echo -n 'admin' > ./username
$ echo -n 'MacStadium' > ./password

As you can see, we need to create a file that is named according to the key in the key-value pair, and we need to write the value from that key-value pair to said file.

Create a Kubernetes Secret with the kubectl CLI

With our files created above, we can now run the following to create our Secret:

kubectl create secret generic db-user-pass --from-file=./username --from-file=./password

Breaking this command down, we can see that “kubectl create secret” is the base command. From there, we pass generic, the type of Secret we want to generate – this will generally be generic, but you can read about other types here. Then the name of the Secret, in this case db-user-pass. And finally, the files we created above passed with the --from-file flag.

Kubernetes Secrets as environment variables

To access our database username and password as environment variables, we will need to define those variables in our Pod template from our Secret.

apiVersion: v1
kind: Pod
 name: redis-pod
 - name: mycontainer
   image: redis
     - name: SECRET_USERNAME
           name: db-user-pass
           key: username
     - name: SECRET_PASSWORD
           name: db-user-pass
           key: password
 restartPolicy: Never

In our Pod template, we’ve defined two environment variables, our username and password. The capitalization of our env variables, i.e. SECRET_USERNAME, denotes the introduction of a global variable.

Notice also that we have told Kubernetes which Secret we want to use, in this case, db-user-pass. And finally, we have to identify a key from which our new global variable's value will be set.

In the above YAML, we’ve passed username as our key because we want to set the global variable SECRET_USERNAME to the value “admin” which we wrote to the file named “username” above.


Kubernetes Secrets store small amounts of encrypted information such as database credentials or SSH keys. Above, we covered how to define a Secret from the kubectl CLI, and then consume that Secret as an environment variable in a given Pod.

Share this article


Orka, Orka Workspace and Orka Pulse are trademarks of MacStadium, Inc. Apple, Mac, Mac mini, Mac Pro, Mac Studio, and macOS are trademarks of Apple Inc. The names and logos of third-party products and companies shown on the website are the property of their respective owners and may also be trademarked.

©2023 MacStadium, Inc. is a U.S. corporation headquartered at 3525 Piedmont Road, NE, Building 7, Suite 700, Atlanta, GA 30305. MacStadium, Ltd. is registered in Ireland, company no. 562354.