Confidential information is crucial for running production systems, but having them exposed to wider people or making them easily accessible brings lots of risks to the system. Storing crucial data such as passwords, authentication tokens, and SSH keys, in plaintext on containers is a bad idea. But this information is frequently utilized by Containers for performing various operations like integration of one system with another.
To make confidential information accessible yet secure, Kubernetes is tailored with a powerful encrypting, managing, and sharing feature known as ‘secrets’ that gets deployed across every Kubernetes cluster. By default, every information stored into secrets is encoded with the Base64 encoding. Saving confidential data in secrets enables users to have better control over passwords, keys, etc. Let’s roll down the blog to learn everything about Kubernetes Secrets in detail.
What are Secrets in Kubernetes?
Secrets allow Kubernetes users to store and manage all the sensitive information, such as passwords, OAuth tokens, and ssh keys more effectively. It is a better and more flexible way if compared to other options such as using Pod specifications and container images.
Users have the flexibility of either creating them manually or configuring the infrastructure to create these secrets automatically every time a cluster gets formed. Every Secret can be restored as plain text by users having API access, or anyone having accessibility for etcd, which is the data store for Kubernetes.
Protections Offered by Kubernetes
Kubernetes resources offer strict security to the Secrets for preventing them from getting exposed. Following is the brief information about the security added by various resources in the environment:
1. Secret resources
Pods and secrets are completely isolated from each other, this makes the data stored in Secret less prone to getting exposed during the complete pod lifecycle. Therefore, the very first step for sharing critical information variables with pods is to create them separately as secret objects.
2. Kubelet
Kubelets are node agents that function on all the nodes that interact with the containers during the runtime. Data stored in secrets are utilized by containers that should be available on the nodes as well. However, these secrets are not shared with all the nodes and are only given to the nodes that have pods running the secret.
3. Pods
Multiple pods run on every node, but only selective ones that are defined for using secrets can access them. Having said that, every pod has several Containers running in them, but the secrets are only restricted for Containers that have asked for them in volume mounts specification. Therefore, the functioning of Pods reduces the possibility of the secrets getting shared unnecessarily to pods or containers.
4. Kubernetes API
The process of creating and accessing secrets is performed over the Kubernetes API. Therefore, Kubernetes secures all the conversations happening between users, the API server, and kubelet using SSL/TLS.
5. etcd
Just like the data of any other Kubernetes resource, Secrets also get stored in etcd. This makes it possible for individuals to access secrets data after breaking into the etcd via the control plane. To prevent this, Kubernetes enables users to encrypt the secret data. Encryption will further help secrets to get isolated from other Kubernetes resources and reduce the exposure.
Types of Kubernetes Secrets
Every time a Secret is created, it gets specified to a “type” field of secret resources. The main purpose behind defining the type of a Secret is to facilitate programmatic handling of the information. Kubernetes offers some pre-configured types for Secrets that are used in specific scenarios.
An individual can also create their own Secret type by assigning non-empty strings as the type value for Secret objects. All the empty strings are counted as ‘Opaque’ type and their name can be modified easily by the users.
1. Opaque Secrets
It is a default secret type. While creating secrets using kubectl, an individual has to execute a subcommand for indicating the Opaque Secret type. For instance, the below-mentioned commands are used for creating an empty Opaque type secret.
kubectl create secret generic empty-secret
kubectl get secret empty-secret
2. Service account token Secrets
A kubernetes.io/service-account-token or service account token secrets is utilized for storing tokens that help in identifying service accounts. If using this type, an individual has to make sure that the notation kubernetes.io/service-account.name is configured to any existing service account name.
Every time a pod is created, Kubernetes instantly creates a service account token secret, and the pod further gets added to this secret by default. It also comes with credentials for accessing the Application Program Interface. However, users are enabled to switch off this automatic creation and usage of API credentials if required.
3. Docker config Secrets
Individuals are allowed for choosing anyone from the below-mentioned secret types to create a secret and store credentials for accessing Docker registries:
Kubernetes.io/dockercfg
This secret type is responsible for storing serialized ~/.dockercfg that is the official format to configure the Docker command line. Here, it is important to make sure that the Secret data field has a .dockercfg key whose values are the contents of ~/.dockercfg file written in base64 format.
kubernetes.io/dockerconfigjson
This secret type is developed in order to store serialized JSON that is configured with similar rules as ~/.docker/config.json file. One thing to keep in mind for adding the .dockerconfigjson key to the Secret objects file, and the data inside ~/.dockercfg is in base64 encoded string.
4. Basic authentication Secret
This Kubernetes secret type “kubernetes.io/basic-auth” is used for storing data that is utilized for storing basic authentications. Data fields should have the following keys:
- username: This field must contain the username for basic authentication
- password: It is the password for authentication
Both of the aforementioned values should be base64 encoded strings. The main intent of this secret type is to provide more convenience to the users. Using this built-in Secret type allows individuals for uniting the format of credentials and API servers to quickly get the required keys in secret configurations.
5. SSH authentication Secrets
The built-in type kubernetes.io/ssh-auth helps to store all the information utilized in SSH authentications. Here, an individual has to specify ssh-private keys and key-value pairs in stringData for allowing SSH credentials to be used at times.
6. TLS secrets
Kubernetes comes with this built-in Secret type kubernetes.io/tls to store certificates that are the keys utilized for TLS. Kubernetes’ environment utilizes this data during TLS termination of the Ingress, which is an API object that provides routing rules for the management of external users. However, this can also be utilized along with other Kubernetes resources or can be deployed on any workload directly. Administrators should ensure to provide the stringData field of secret configurations to the tls.key and the tls.crt key.
7. Bootstrap token Secrets
For creating this secret type, individuals should specify the secret type to bootstrap.kubernetes.io/token. It is majorly developed for tokens utilized during the node bootstrap processes. The stored token helps in authenticating for ConfigMaps as well.
Bootstrap token secrets are developed into the kube-system namespaces and are named in the format of bootstrap-token-<token-id>. The <token-id> is basically a six characters string of the token ID. The data stored in this secret type is composed of the following information:
- token-id: An id with six characters used for identifying tokens.
- token-secret: The original token secret key, which is sixteen characters long.
- description: Brief information that is used by individuals to know the functionalities of a particular token.
- expiration: The Coordinate Universal Time (UTC) tells when a particular token will get expired.
- usage-bootstrap-<usage>: Boolean flags that indicate the extra purposes of bootstrap tokens.
- auth-extra-groups: It is a list of groups separated by commas that get authenticated along with the system:bootstrappers.
Creating Kubernetes Secrets
There are two ways for organizations to make Kubernetes Secrets for their infrastructure:
1. Built-in secrets
By opting for built-in secrets, Kubernetes will build secrets automatically and add them to the container through API keys. However, if it is leading to security issues, then users are allowed to disable this service.
2. Custom secrets
Users can create secrets themselves by defining the desired sensitive data. However, one can configure the system to make Kubernetes secrets automatically by making the use of kubectl create secret command as mentioned below. Users have to include the sensitive information that they want to store in it:
kubectl create secret generic db-user-pass –from-file=./username.txt –from-file=./password.txt
Following are some ways for creating Secrets manually using Kubectl, configuration files, or using Kustomize.
3. Using Kubectl
For creating Secret with the help of Kubectl, you need to have a Kubernetes cluster that has kubectl configured in it for communicating with the clusters. It is suggested by Kubernetes itself for running Kubectl on clusters that have at least two nodes, and also they shouldn’t be the control plane hosts. However, if you don’t have any Kubernetes cluster yet, you can use minikube for creating one quickly.
Secrets are useful for storing confidential information that are used by pods. Users can save the data fields such as username in a file named ./username.txt and the password in the file name ./password.txt on the local machine with these commands:
echo -n ‘admin’ > ./username.txt
echo -n ‘1f2d1e2e67df’ > ./password.txt
In the aforementioned commands, the -n flag makes sure that the file created afterward does not have any extra newline characters in the texts. This is important to add because kubectl reads all the files and encodes them into base64 strings, and if there are some extra newline characters, then they’ll be encoded too.
An individual can execute kubectl create secret command for packaging these files as Secrets and creating objects on API servers:
kubectl create secret generic db-user-pass \
–from-file=./username.txt \
–from-file=./password.txt
For verifying the secret created composed of all the crucial information, run the following Kubectl command:
kubectl get secrets
For deleting the created secrets, run the following command:
kubectl delete secret db-user-pass
4. Using Configuration files
Before proceeding, ensure to create config files first. Further, Kubernetes secrets can be created within these files either in JSON or YAML format. All the resources of the secrets are composed of two fields: data and stringData. The data field is utilized for storing arbitrary data, whose encoding is done with the help of base64.
The stringData field is added for the ease of the users and it helps them for providing Secret data as an unencoded string. Also, keep in mind that keys of both data and stringData should have alphanumeric characters. Therefore, for storing a string into Kubernetes Secret with the help of data field, run the following command for converting them into base64:
echo -n ‘admin’ | base64
Now execute the following Kubectl command for creating a secret:
kubectl apply -f ./secret.yaml
For deleting the secret you have created using the config file, run the below-mentioned command:
kubectl delete secret mysecret
5. Using Kustomize
After the Kubernetes v1.14, kubectl enables the functionality of the management of objects using Kustomize. Kustomize can help users in making secrets and ConfigMaps by using resource generators. The only prerequisite is that all of these generators should be defined in the kustomization.yaml file.
Creating Kustomization file: For creating secrets, users need to define secretGenerators into kustomization.yaml file or Kustomization file. Run the following command for creating Kustomization file on your system and defining secretGenerator in the same:
secretGenerator:
– name: db-user-pass
files:
– username.txt
– password.txt
Another way of doing the same is by providing “literals”. For instance, following kustomization.yaml file has two literals defining username and password:
secretGenerator:
– name: db-user-pass
literals:
– username=admin
– password=1f2d1e2e67df
Now, to create a secret, execute the directory that is composed of the kustomization.yaml file:
kubectl apply -k .
Conclusion
Kubernetes is designed with sophisticated encrypting, managing, and sharing features known as Kubernetes secrets that are deployed throughout every Kubernetes cluster in order to make confidential data available while being secure. Users have the flexibility of either creating them manually or configuring the infrastructure to create these secrets automatically every time a cluster gets formed.
When new secrets are created, they are assigned to a secret resource’s “type” field. There are seven types of pre-defined secrets assigned by Kubernetes itself for different purposes. An individual can also create their own Secret type by assigning non-empty strings as the type value for Secret objects. The blog contains three ways of creating Kubernetes secrets: using Kubectl, configuration file, and Kustomize.