Kubernetes

Kubectl Create Secret: How to Create, Use, and Access

Kubernetes is an open-source container orchestration platform widely used for automating deployment, scaling, and management of containerized applications. It is designed to be highly scalable, resilient, and extensible, and it can run on a wide range of infrastructure, including public and private clouds, on-premises data centers, and hybrid environments.

One of its biggest benefits is its support for secure storage and handling of sensitive configuration data - a task undertaken by an object called Secret.

This article discusses Kubernetes' Secrets and how to create and use them. We’ll also discuss some of the best practices to follow when working with them.

To learn how Kubernetes works and its different concepts, watch this video:

What is a Kubernetes Secret?

A Kubernetes Secret is an object that stores sensitive data, like a password, a certificate, an API key, or a token. Generally, an application's sensitive information is packaged with the application binary or passed as environment variables inside a container. The data stored in a Secret object can only be accessed by pods or other Kubernetes objects that are authorized to do so.

Since a user can create Kubernetes Secrets separately from Pods, updating and deleting them does not impact them. Secrets are functionally similar to ConfigMaps. The only difference is that the data in the Kubernetes Secrets is base64 encoded.

Try the Kubernetes Deployments Lab for free

Kubernetes Secret Types

Below are the different types of Secrets supported by Kubernetes and their purpose:

Opaque Secrets - This is the default type that is set by Kubernetes. An opaque secret is stored in an encoded format that is not easily readable by humans. It is normally used to store sensitive information such as passwords or API keys. Below is an example of an opaque Secret:
Service account token Secrets - This type of secret stores credentials such as tokens that are used in service account authentication.
Docker config Secrets - This Secret type is used to store credentials required to access private Docker registries.
Basic authentication Secret - This type is used to store basic authentication credentials, i.e., username and password. You can use opaque type in its place. The only advantage of this type is that it helps developers understand the workflow better.
SSH authentication Secrets - As the name suggests, this type stores data needed in SSH authentication. It requires you to specify an ssh-privatekey.
TLS Secrets - This type is used for storing TLS certificates and their associated keys. When using it, you have to specify the tls.cert and tls.key.
Bootstrap token Secrets - This type stores tokens that are used in the node bootstrap process. You have to specify the following details when creating this Secret; token-id, token-secret, description, expiration, usage-bootstrap-<usage>, and auth-extra-groups

Why We Create Kubernetes Secrets

Secrets are a source of truth for storing and updating sensitive information. They can be passed to the applications by mounting them as a volume or passing the credentials as environment variables object.

How to Create Kubernetes Secrets

Now that we know why we need Secrets, let's dive into how to create them.

We can create secrets using two methods:

Creating a secret using the command line utility kubectl
Creating a secret from a .yaml secret definition file.

Creating a Secret Using kubectl

Below are examples demonstrating how to create different secret types using the kubectl CLI utility.

Application Data or Generic Secrets

The kubectl command line utility provides a way to create secrets from a literal value, a file or directory containing a credential, and an environment file.

kubectl create secret generic user-creds --from-literal username=kodekloud --from-literal password=a//Strong//Password

kubectl create secret generic user-creds --from-literal username=kodekloud --from-file=password=/path/to/file

kubectl create secret generic user-creds --from-env=/path/to/file.env

Docker Config

There are two ways to make a Dockercfg secret. We can create a secret using a .dockercfg file or by passing in the credentials in the following manner:

kubectl create secret docker-registry kodekloud-reg
--from-file=.dockerconfig=/path/to/somefile.dockerconfig

kubectl create secret docker-registry kodekloud-reg
--docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

TLS Certificates

TLS certificate secrets can be created from a public/private key pair. The public key certificate must be .PEM encoded and match the given private key. We can create a TLS secret using the following command:

kubectl create secret tls-secret --cert=/path/to/tls.cert
--key=/path/to/tls.key

Creating a Secret from a .yaml Secret Definition File

Below are examples demonstrating how to create different secret types using .yaml Secret definition file.

An example of a Secret created using a .yaml definition file.

apiVersion: v1 
kind: Secret 
metadata: 
  name: nginx 
data: 
  USERNAME: a29kZWtsb3Vk 
  PASSWORD: YS8vU3Ryb25nLy9QYXNzd29yZA==

Test your Kubernetes expertise with our FREE, fun, and challenging set of hands-on challenges.

Things to Consider Before Using Kubernetes Secrets

Kubernetes provides a secure means to store sensitive data in the form of Secrets. However, there are some drawbacks to it, and before deciding to use secrets, you should consider them. Below are the drawbacks:

The sensitive data stored in Kubernetes Secrets is encoded in base-64. Simply put, this is a text-encoding technique used to store data.
If a malicious user gets access to a cluster, they can read all the secrets and decode the base64 encoded contents.
Kubernetes Secrets rely on a master key for encryption at the ETCD level. ETCD is the key-value store (a sort of database) used by the Kubernetes API server to store configuration.

How to Secure Kubernetes Secrets?

Nowadays, a common way to add an additional layer to Secret management on Kubernetes is to introduce a third-party Secret management solution, such as Azure Key Vault, Google Secret Manager, AWS Secrets Manager, and HashiCorp Vault. This approach might resolve some issues inherent in Kubernetes, but any third-party solution is not a silver bullet. With a third-party solution, it is still virtually impossible to ensure that:

We are restricting access to secrets. This is an RBAC problem, and third-party tools do not currently offer a solution for this problem.
Secrets are not stored on disk or in environment variables.
Applications don't continue to remain the weak point, as a compromised application can easily leak secrets.
TLS encrypts data in transit.
Secrets are automatically rotated.

Want to learn more about HarshiCorp vault?

HashiCorp Vault is one of the industry's top-rated Secrets Management tools whose adoption is growing exponentially.

Check out our HarshiCorp Learning path.

You’ll find courses that will help you master both the basic and advanced HashiCorp skills.

Configure Least-Privilege Access to Secrets

When working with RABC to secure your Secrets, consider the following:

Services: Restrict watch or list access to only the most privileged, system-level components. Only grant get access to Secrets if the component's normal behavior requires it.
People: Restrict get, watch, or list access to Secrets. Only allow cluster administrators to access etcd. This includes read-only access.

Looking to polish your Kubernetes skills? Check out the following course from KodeKloud: Kubernetes for the Absolute Beginner.

Conclusion

A Kubernetes Secret is an effective solution for storing sensitive data. It is important to choose the appropriate type of secret for the specific use case to ensure the security and confidentiality of the stored information.

Faizan Bashir

Nov 1, 2022 • 6 min read