Kubernetes Secrets Management

The Kubernetes environment, like many other computing systems, necessitates the use of sensitive data. Secrets relate to a group’s sensitive data (such as passwords, SSH keys, and security tokens). We’ll look at the capabilities of Kubernetes and other secret management systems in this post and how to create and manage secrets in your Kubernetes environment.

What are Secrets in Kubernetes?

A secret is a piece of private information such as a password, key, or token. Such information may also be laid out in a container image or a Pod specification. If you employ a Secret, you don’t have to include secret data in your application code.

Because Secrets may be installed independently of the pods that use them, there may be much less threat of the Secret (and its information) being discovered in the workflow of generating, examining, and changing Pods. Kubernetes and the apps that run for your cluster also use secrets and techniques to take greater precautions, including heading off writing confidential information to nonvolatile storage.

Types of Secrets

Kubernetes provides many built-in types for some common use scenarios. The validations accomplished and the restrictions enforced through Kubernetes differ between those categories.

Opaque secrets

The default Secret type is used when there is no Secret configuration file. When creating a secret by kubectl, use the generic subcommand for specifying this type.

Service account token secrets

This Secret stores a token with a service account. You need to set the kubernetes.io/service-account.name annotation to a current service account name during the use of this Secret type.

Docker config secrets

This type is for storing a serialized /.dockercfg file. It is the traditional format for configuring the Docker command line. First, verify that the field of the Secret data has a.dockercfg key, and its value is the content of the a /.dockercfg file encoded in base64 format when utilizing this Secret type.

Basic authentication secret

This kind is used for storing fundamental authentication credentials. When utilizing this Secret type, one of the two keys (username and password) must be present in the Secret’s data field:

These keys’ values are both base64 encoded strings. You can use the stringData for Secret generation if you want to supply clear text content.

SSH authentication secrets

This is used to handle SSH’s authentication data. The SSH credential needs to be accepted as an ssh-privatekey key-value pair withinside the data (or stringData) subject while enforcing this Secret type.

TLS secrets

Kubernetes has a built-in Secret type kubernetes.io/tls that may store a certificate and its corresponding key, which is commonly used for TLS. This information is utilized with the TLS termination. But it could additionally be employed with different assets or without delay through a workload. When imposing this sort of Secret, the tls.key and tls.crt keys should be supplied within the data (or stringData) area of the Secret configuration, even though the API server now no longer simply examines the values for every key.

Bootstrap token Secrets

This form of secret can be created by going to bootstrap.kubernetes.io/token and choosing the Secret type. This type of Secret aims to store tokens. These tokens are primarily used during the node bootstrap procedure. It keeps track of the signature tokens for well-known ConfigMaps.

A bootstrap token Secrets is often created under the kube-system namespace and named bootstrap-token-token-id>, where token-id> is a six-character string representing the token ID.

How to create a secret in Kubernetes?

A Secret can be used to hold user credentials. Pods use these credentials in order to access a database. An id (username) plus password, for example, make up a database connection string. You can save the username in./username.txt and the password in./password.txt on your local PC.

$ echo -n 'Alex' > ./username.txt

$ echo -n '01TRfg02' > ./password.txt

The below piece of code shows how you can create a secret with the create command.

$ kubectl create secret generic secret-mbps \

--from-file=./username.txt \

--from-file=./password.txt

Below, the secret (named secret-mbps) is successfully created below.

As mentioned above, the -n parameter in the commands ensures there is no extra newline character at the end of the content in the output files. This is significant because the extra newline character is encoded when kubectl reads a file and converts it to a base64 string.

How to edit a Secret?

The following command is used to make changes in an existing Secret:

$ kubectl edit secrets secret-mbps

This will open the editor with the default configuration. It will allow you to adjust the data field’s base64 encoded Secret values:

How to check if a secret exists?

In order to verify a secret, type the get secret command.

$ kubectl get secrets

The attached screenshot shows the details of the specified secret.

How to decode the secret?

To decode the secret, you can use the below-mentioned command.

$ kubectl get secret secret-mbps -o jsonpath='{.data}'

Below you can see the output screenshot.

You may now decode the password data as follows:

$ echo 'MWYyZDFlMmU2N2Rm' | base64 --decode

Here is the result.

You can use the command (as you can see below) if you want to do not want to store a secret encoded value in your shell history:

$ kubectl get secret secret-mbps -o jsonpath='{.data.password}' | base64 –decode

This command will produce the same results as the previous one.

How to delete the secret?

In order to delete the secret, you can use the delete command and mention the accurate name of the secret.

$ kubectl delete secret secret-mbps

Here you can observe that the specified secret is successfully deleted.

Conclusion:

Secrets are digital identities that allow users to verify their identities and access privileged accounts, apps, and services by authenticating their identities. We have mentioned Kubernetes secrets management in detail in this article.