Kubectl Create Secret: How to Create, Use, and Access
Kubernetes is an open-source container orchestration platform that is 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.
In this article, we’ll discuss what a Kubernetes Secret is and how to create and use it. We’ll also discuss some of the best practices to follow when working with it.
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.
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 for storing 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
How and 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.
Now that we know why we need Secrets in Kubernetes let's dive into how to create them.
We can create secrets using two methods:
- Creating a secret using the command line utility
- Creating a secret from a .yaml secret definition file.
Creating a Secret Using the Command Line Utility
Below are examples demonstrating how to create different secret types using the
kubectl CLI utility.
Application Data or Generic Secrets
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
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 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==
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. This, simply put, 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.
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.
Click the 'Subscribe' button to get more Kubernetes and DevOps articles.
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.
Looking to polish your Kubernetes skills? Check out the following course from KodeKloud: Kubernetes for the Absolute Beginner
You can also test your Kubernetes expertise with our FREE, fun, and challenging set of hands-on challenges.