
Tips and tricks for creating Kubernetes secrets
7 Dec 2020 #kubernetes #deployment #automation
When you manage secrets with Kubernetes, you'll be using the kubectl secret
suite of commands. There are a few patterns I use to make life a little easier.
First one is to have kubectl
ignore errors when deleting a secret which doesn't exist. There is a command-line argument --ignore-not-found
which does exactly that:
$ kubectl delete secret my-secret --ignore-not-found
By adding --ignore-not-found
, kubectl
will silently ignore the error which is great if you for example use it in a Makefile. In a Makefile, when a command fails (exits with a non-zero exit code), the build will stop. If you are recreating a secret, this is not what you want.
Defining secrets containing environment variables are usually done by using literals:
$ kubectl create secret generic my-env-vars1 \ --from-literal="VAR1=myhost.yellowduck.be" \ --from-literal="VAR2=production"
$ kubectl create secret generic my-env-vars2 \ --from-literal="VAR3=secret-key" \ --from-literal="VAR4=db-conn"
However, I find this hard to read and it also disables syntax coloring. I prefer to define them in a file with the extension .env
(so that Visual Studio Code does syntax highlighting):
my-env-vars1.env
VAR1=myhost.yellowduck.beVAR2=production
my-env-vars2.env
VAR3=secret-keyVAR4=db-conn
Once you have these files, loading can be done by using the --from-env-file
command-line argument specifying the path of the file in which they are defined:
$ kubectl create secret generic my-env-vars1 --from-env-file=my-env-vars1.env
$ kubectl create secret generic my-env-vars2 --from-env-file=my-env-vars2.env