Photo by Stillness InMotion on Unsplash

Secrets are Kubernetes objects that can be used to store information such as usernames, passwords, and token keys that may be required in the future. Secrets are mostly used to store sensitive information that can be used to authenticate a user before providing them access to a resource. These things serve as a mechanism or as keys for authenticating access to computer resources that are under protection.

Default settings allow for secrets to be stored unencrypted in the API server. This means anyone who has access to the API server can edit or get the secrets, and anyone who has been granted permission to create a pod in that namespace can also read the secrets from that namespace. This makes it a common target for attacks and makes it vulnerable to the attacks that may be carried out.

Why Is Kubernetes Secrets Used?

Kubernetes should be deployed using Kubernetes security best practices and Kubernetes Secrets is a vital part of it. It is vital for containerized applications to remain ephemeral to avoid sharing resources with other pods because Kubernetes operates in a distributed environment.

When PKI and other confidential resources are used to access external resources, this is what happens to the data. Since applications must communicate with external resources, they require a mechanism to query their authentication methods from outside the programme itself. Kubernetes Secret provides that solution. It is based on the principle of least privilege and eliminates the need to include sensitive data with application code.

The ability to query Kubernetes Secrets as discrete objects when an application pod requests access to external resources decreases the pod's risk of being exposed, which is particularly useful when developing new applications. Access to secrets is possible for pods, but only when the secrets are expressly part of a mounted volume or when the Kubelet is fetching the image utilized by the pod.

Secrets can only be accessed by those who are members of the cluster in which they are located. The majority of secrets are only accessible with the use of a master key.

Implementing Kubernetes Secrets to Your Installation

Source

Implementing Kubernetes Secrets is a straightforward process. It starts by creating a file---it can be a text file or a YAML file. The file can contain secrets. Making secrets (username and password) in a text file requires that we first store them in a text file, with the text files "./username_new.txt" and "./password_new.txt" serving as the appropriate text files for the username and password, respectively.

echo -n 'new_admin_user' > ./username_new.txt

echo -n 'new_admin@321' > ./password_new.txt

In order for the "echo" command not to attach a new line, the "-n" option must be specified. If this is not done, the new line will be treated as a character and will be encoded alongside the rest of the characters. Following the storage, we will use the command "Kubectl generate secret," which will bundle these files into a secret command that will look like this:

kubectl create secret generic db-user-pass ---from-file = ./username_new.txt --fromfile = ./password_new.txt

The keyword "generic" is used to create an opaque secret, and the phrase "-- from-file" is used to identify the location of the secret file. Using the text file as a medium, the output of the preceding command certifies the formation of a secret. Now, if a user wishes to verify whether or not secrets have been successfully produced, he or she can use the command:

kubectl get secrets

The command will display a list of all available secrets, which may include their name, the number of data values they include, the types of data values they contain, and any other available information.

It is possible to construct secrets (username and password) using the configuration file, which can be either JSON or YAML. As a result, the user must define the information in the configuration file and encode the values that he wishes to store before he can use the command described below.

echo -n 'new_admin_user' | base64

echo -n 'new_admin@321' | base64

Add the above encoded values in the YAML file.

apiVersion: v1

kind: Secret

metadata:

name: NewSecret

type: Opaque

data:

   username: <encoded value of new_admin_user>

   password: <encoded value of new_admin@321>

There are two characteristics to "data," which are "username" and "password." "Data" is the parameter with these attributes. It is possible for users to pass their encoded information through the corresponding characteristics.

As soon as this file is saved, it will be saved with the ".yaml" extension, and the user will use the "kubectl apply" command to create the secret.

Kubectl apply -f [file]

We can generate Kubernetes secrets using generators like Kustomize. To do so, we need to create a file entitled Kust.yaml with the following structure:

secretGenerator:

- name: db-credentials 

  files:

  - username_new.txt

  - password_new.txt

In the above snippet, db-credentials is the name of the secret, and username_new.txt and password_new.txt are files that were previously generated for the purpose of storing the username and password respectively. If you want to include the unencrypted, literal version of values in your code, you can change the following snippet and include the "literal" part in your code.

secretGenerator:

- name: db-credentials

  literals:

  - username=new_admin_user

  - password=new_admin@321

Save the above file with the .yaml extension and then run the command below in the directory where the above file is stored.

kubectl apply -k

The output of the preceding command confirms that a secret has been created.

We have learned how to create secrets so far, but if a user wishes to encode a value of a secret, he or she can use the snippet below. Encoding is important since credentials in plaintext run the risk of being compromised.

kubectl get secret [secret file name] -o jsonpath='{.data}'

So the user can choose which secret file values he wants to decode by passing them through this snippet, which is valid for JSON files. It will return the values that have been base 64 encoded using this snippet. So, if a user wishes to decrypt it further, he or she can use the following code snippet:

echo '[encoded-values]' | base64 --decode

We supply the user input in clear text by giving the encoded values to the snippet above one by one, one at a time. It indicates that we are employing the username and password, and that the first user will be required to supply the username and password encoded values to decode the information.

Source

Conclusion

Secrets are a safe way to store sensitive information in Kubernetes if you need to store sensitive information in a secure manner. Base 64 encoding is preferred for secrecy since it aids in the concealment of data (although, it is not totally secure against cyber attacks). For example, an organization can integrate Kubernetes with the secrets management tools that require access to a secret vault, or an organization can use IAM service so that the system can use a token from a secure Token Service, or it can integrate a third-party secrets manager into the pods to mitigate problems regarding secrets.