Guest post originally published on Medium by Saurabh Gupta, Sr. Developer Advocate at DigitalOcean


However, there are times when you want bake-in sensitive secret information into your Kubernetes cluster and share it across when needed. You do not want to put this information into a Pod definition YAML or a docker image. This is where Kubernetes Secret comes to your rescue.

In this post, we will try to gain more insight into how we can manage secrets effectively in Kubernetes.

Why use a Secret?

To solve this challenge, Kubernetes provides an object called Secret, which we can use to store sensitive data. Secrets management also enables better management of microservices-based software architecture.

What is the Kubernetes Secret?

Kubernetes Secret can be injected into a Pod container either as an environment variable or mounted as a file.

Difference between a ConfigMap and Secrets in Kubernetes?

So use Secrets for storing critical data like API keys, passwords, service-account credentials, etc and use Configmaps for not-secret configuration data like app theme, base platform URL, etc

How does Kubernetes Secrets work?

  • Built-in secrets – Kubernetes Service Accounts automatically create secrets and attach them to containers with API Credentials. The automatic creation and use of API credentials can be disabled or overridden if desired.
  • Custom secrets – you can define your own sensitive data and create a custom secret to store it.

Built-in Kubernetes Secrets

These secrets are stored in plaintext format on the cluster’s etcd server, and unless, etc is configured to encrypt communication using TLS, are visible on the wire as the etcd cluster is synchronized. Furthermore, anyone who has, or can gain root access to any node in the cluster can read all secret data by impersonating the kubelet.

Creating your own custom Secrets:

$ kubectl create secret <secret-name>

If you want this secret to be added to a specific namespace or context add the – namespace or use-context arguments to this command. (Otherwise, it will be added to the default namespace).

You can use $ kubectl describe secret <secret-name> to view a summary of your secret. Using $ kubectl get secret or $ kubectl describe secret will not reveal the information in the secret.

  • Creating a Secret manually: you can also create a Secret in a file first, in JSON or YAML format, and then create that object. The name of a Secret object must be a valid DNS subdomain name. The Secret contains two maps: data and stringData. The data field is used to store arbitrary data, encoded using base64. The stringData field is provided for convenience and allows you to provide secret data as unencoded strings.

Secret management in cloud:

Some of the popular secret management solutions from different cloud vendors are shared below:

  1. Secrets Manager from AWS
  2. Key Vault from Azure Cloud
  3. Cloud Key Management Service from Google cloud