Home Container Kubernetes Secrets Management

Kubernetes Secrets Management

-

Introduction

Kubernetes is currently the de-facto standard for container orchestration. As organizations globally are adopting a Container first development approach, a large part of existing workloads are still running on virtual machines, be in the public cloud or a private data centre. Hence a lot of companies are now facing severe challenges  in migrating from their old methods to Kubernetes.

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 defintion YAML or a docker image. This is where Kubernetes Secret comes to your rescue.

Suggested read – Why Kubernetes? – 11 benefits that simplifies container management

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

Why Use a Secret?

Not all configuration information is safe to keep out in the “public” . Also it is a bad practice to store sensitive data, like passwords, SSH keys and authentication tokens, in plaintext on a container. However, containers do need this data to perform basic operations like integrating with other systems.

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.

Suggested read – Top 10 open-source monitoring tools for Kubernetes

What is a Kubernetes Secret?

As per the Kubernetes documentation notes: “Kubernetes Secrets let you store and manage sensitive information, such as passwords, OAuth tokens, and ssh keys. Storing confidential information in a Secret is safer and more flexible than putting it verbatim in a Pod definition or in a container image ”. 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?

Both, ConfigMaps and Secrets store data as a key-value pair. However the major difference is, Secrets store data in base64 format meanwhile ConfigMaps store data in a plain text.

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.

Suggested read – Top 7 Updates Offered With All-New Kubernetes 1.18 Release

How does Kubernetes Secrets Work?

There are two types of secrets in Kubernetes:

  • 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

Kubernetes provides a built in mechanism for storing configuration values that you would prefer to keep private. They can be access controlled to specific namespaces, and their contents are not shown by default in kubectl get or describe output. They are base64 encoded, so the contents are not immediately apparent even when you pull them directly from kubectl. Of course, base64 decoding is trivial.

These secrets are stored in plaintext  format on the cluster’s etcd server, and unless etcd 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

1. Creating a Secret Using kubectl: this is the simple and easy method to generate your secrets. You can use the kubectl create command to create 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.

2. 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 validDNS 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.

Suggested read – Ok! Google…. What are the Kubernetes best practices?

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

In case you are using one of the cloud vendors, you can try using one of their secret management services, as part of their cloud platform offerings. Using a secret management service, gives you the power to control access to secrets using fine-grained permissions and auditing.

Saurabh Gupta
Saurabh Gupta
Saurabh is a tech enthusiast with over a decade of experience in the software industry. His focus areas and expertise is around open-source,DevOps, Cloud ,Containers and Kubernetes. He often speaks at community meetups and conferences and is a part of CNCF Speaker’s Bureau.

Cloud

Cloud Management