Kubernetes Secrets: How to Manage Secrets in Kubernetes?

Just like any other software platform, Kubernetes needs API keys and passwords to access external and internal private systems. API keys and passwords are only secure when stored safely and encrypted. To boost API keys and password security Kubernetes introduced secret objects.

In this article, you will learn about Kubernetes secrets in detail. In addition, you will learn how to configure and manage Secrets in Kubernetes while maintaining secure practices.

#Prerequisites

Make sure you have a fully operational Kubernetes cluster and that kubectl is properly installed on your local machine.

#What are Secrets in Kubernetes?

The definition of a secret in Kubernetes is different from the definition of a secret in software development. In software development, a secret is any sensitive data that has to be secured. Meanwhile, in Kubernetes, a Secret is an object that contains and manages sensitive data such as API keys and passwords. Secret objects are the proper way of handling credentials in Kubernetes. Storing sensitive data in configuration files such as ConfigMap or Pods poses a high risk of data leakage.

Examples of sensitive information contained in Secrets are:

1. TLS certificates
2. Passwords
3. Tokens
4. Docker registry keys

Secrets are built into the Kubernetes platform. Secrets are a secure way of using credentials in Pods and container images. When a secret is referenced in a Pod configuration, the only information the viewer will access is the name of the Secret, not the password or token stored in the Secret.

Secrets allow you to write sensitive information in plain text using the stringData field. Kubernetes will automatically encode this data using base64. Using the stringData is only convenient when you want the sensitive data to be human-readable. Alternatively, sensitive data in Secret objects is encoded using base64. It is recommended to use base64 encoding over stringData which makes it easy for everyone to read the stored sensitive data.

Secrets are stored in the etcd database hosted on the control plane. Secrets can be used in Pods as volume mount or environment variable. Secrets take a minimalistic approach, very few sensitive details have to be stored in one Secret. This reduces the attack surface in case the Secret is compromised. To reinforce this minimalistic practice Secrets have a maximum memory of 1MB.

Kubernetes offers various types of Secrets that serve different purposes.

1. Opaque secrets: This secret type is suitable for containing different types of sensitive data such as passwords and API keys. This data will be stored in arbitrary key-pair values.
2. Docker config secrets: This secret is used for storing Docker registry credentials that are used to pull images from private Docker registries. This secret can be created using the kubectl create secret docker-registry command followed by your Docker registry URL, username, password, and email.
3. TLS secrets: These Secrets are used for securing network connections. TLS Secrets store TLS certificates and keys. These secrets are used by the ingress controllers.

#How to manage Secrets in Kubernetes

In this section, you will learn important kubectl commands used to create and manage Secrets.

#1. Creating a Secret

Use the following command to create a Secret.

kubectl create secret [secret-name]

Besides using the imperative command you can use the declarative approach to add more detailed information about the Secret. The YAML file below creates a Secret called prod-secret. This Secret type will be opaque. The data section adds the contents of the Secret which are the username and the credentials using base64 encoding. Other resources will access this Secret using the username.

apiVersion: v1
kind: Secret
metadata:
  name: prod-secret
type: Opaque
data:
  username: dXNlcm5hbWU=
  password: cGFzc3dvcmQ=

The Secret contents have to be in base64 or else kubectl will output the following error when creating the Secret.

Error from server (BadRequest): error when creating "prod-secret.yaml": Secret in version "v1" cannot be handled as a Secret: illegal base64 data at input byte 4

Use the following command to create the Secret after saving the YAML file.

kubectl apply -f prod-secret.yaml

#2. Listing and getting the secret’s details

Use the following command to view and list available Secrets in the current namespace.

kubectl get secrets

You will get the following output:

To get more details about a specific Secret use the following command:

kubectl describe secret dev-secret

You will get the following output that shows the Secret’s namespace, type, and data size.

#3. Deleting a Secret

If a Secret is no longer in use it is important to delete to avoid having any redundant Secrets. Use the following command to delete the Secret.

kubectl delete secret [my-secret]

#The importance of using Secrets to protect Kubernetes resources

Secrets boost cluster security in many ways. Below are the benefits of using Secrets to store sensitive data.

#Credential hardcoding prevention

Hardcoded credentials create vulnerabilities that can be exploited by cyberattackers to get access to the cluster or application. The problem with hardcoded credentials is that they are visible to anyone who has access to the Pod’s configuration file that has credentials. The situation becomes dreadful when the YAML file containing Secrets is pushed to a public repository on GitHub.

Hardcoded credentials can even be leaked in logs and error messages. Hardcoded credentials are logged as variables and exposed during exception handling if they are part of the error context. In addition, using hardcoded credentials makes it harder to comply with regulations and maintain the application.

When a credential is hardcoded, you'll need to manually update its value in every file that references it, which can be an incredibly tedious task. However, using Secret objects simplifies this process significantly. With Secret objects, you can change a credential's value without having to modify the codebase directly. This approach allows credentials to be securely stored and shared among developers, who can use them without ever needing to know the actual values hidden within the Secret objects.

Secrets can be easily rotated since you don't have to update the Pod configuration files when changing Secret values. Rotating Secrets is a crucial aspect of maintaining strong security practices because it minimizes the risk of unauthorized access and limits the potential damage if a Secret is compromised.

Also read: How to restart a Kubernetes pod

#Centralized management of sensitive information

The Kubernetes Secret object allows you to add more than one credential. This enables you to update and delete Secrets in one file. You can list all available Secrets and fetch their details such as namespaces they have been assigned to using kubectl.

#An additional layer of security to protect sensitive data

Without encryption and secure storage credentials can be accessed and stolen by anyone with access to the file containing credentials. Kubernetes Secret object adds a layer of security by preventing credentials from being hardcoded. Even though Secret objects are important in the process of securing Secrets they do not give Secrets full security until they are encrypted.

#Conclusion

In this guide, you have learned various aspects of Secrets such as the secret types and definitions. In addition, you have learned how to create, list, and delete Secretes. Using Secrets to improve sensitive data security isn't enough to stop a data breach from occurring.

Using Cherry Servers’ cloud infrastructure to host your Kubernetes clusters and data allows you to implement the shift-left strategy early.