Every software application is guaranteed to have some secret data. This secret data can range from database credentials to TLS certificates or access tokens to establish secure connections.
The platform you build your application on should provide a secure means for managing this secret data. This is why Kubernetes provides an object called Secret to store sensitive data you might otherwise put in a Pod specification or your application container image.?
In this article, you will learn what a Kubernetes Secret is, its built-in types, ways to create, view, decode, and edit them, and how to use them in Pods. Also, in the end, you will learn the best practices to follow when using Secrets.
What are Kubernetes Secrets?
In Kubernetes, a Secret is an object that contains a small amount of sensitive data such as login usernames and passwords, tokens, keys, etc. The primary purpose of Secrets is to reduce the risk of exposing sensitive data while deploying applications on Kubernetes.
The following are key points about Kubernetes secrets:
- You create Secrets outside of Pods — you create a Secret before any Pod can use it.
- When you create a Secret, it is stored inside the Kubernetes data store (i.e., an etcd database) on the Kubernetes Control Plane.?
- When creating a Secret, you specify the data and/or stringData fields. The values for all the data field keys must be base64-encoded strings. Suppose you don’t want to convert to base64. In that case, you can choose to specify the stringData field instead, which accepts arbitrary strings as values.
- When creating Secrets, you are limited to a size of 1MB per Secret. This is to discourage the creation of very large secrets that could exhaust the kube-apiserver and kubelet memory.?
- Also, when creating Secrets, you can mark them as immutable with immutable: true. Preventing changes to the Secret data after creation. Marking a Secret as immutable protects from accidental or unwanted updates that could cause application outages.
- After creating a Secret, you inject it into a Pod either by mounting it as data volumes, exposing it as environment variables, or as imagePullSecrets. You will learn more about this later in this article.
Types of Kubernetes Secrets
The following are several types of Kubernetes Secrets:
- Opaque Secrets: Opaque Secrets are used to store arbitrary user-defined data. Opaque is the default Secret type, meaning that when creating a Secret and you don’t specify any type, the secret will be considered Opaque.
- Service account token Secrets: You use a Service account token Secret to store a token credential that identifies a service account. It is important to note that when using this Secret type, you must ensure that the kubernetes.io/service-account.name annotation is set to an existing service account name.
- Docker config Secrets: You use a Docker config secret to store the credentials for accessing a container image registry. You use Docker config secret with one of the following type values:
- Basic authentication Secret: You use this Secret type to store credentials needed for basic authentication. ?When using a basic authentication Secret, the data field must contain at least one of the following keys:
username: the user name for authentication
password: the password or token for authentication
- SSH authentication secrets: You use this Secret type to store data used in SSH authentication. When using an SSH authentication, you must specify a ssh-privatekey key-value pair in the data (or stringData) field as the SSH credential to use.
- TLS secrets: You use this Secret type to store a certificate and its associated key typically used for TLS. When using a TLS secret, you must provide the tls.key and the tls.crt key in the configuration’s data (or stringData) field.?
- Bootstrap token Secrets:?You use this Secret type to store bootstrap token data during the node bootstrap process. You typically create a bootstrap token Secret in the kube-system namespace and named it in the form bootstrap-token-<token-id>.
Best Practices for Handling Secrets in Kubernetes
- Encrypt Secrets at Rest: Configure encryption for etcd to secure Secrets in storage
- Limit Access with RBAC: Restrict who can view or modify Secrets using strict RBAC policies.
- Avoid Hardcoding Sensitive Data: Use Secrets to inject sensitive data dynamically.
- Use Minimal Permissions: Only provide the necessary permissions required by pods or users.
- Enable Automatic Secret Rotation: Automate Secret rotation using CI/CD pipelines or tools like SealedSecrets.
- Use External Secrets Manager for Critical Workloads: For highly sensitive data, rely on an external Secret management solution.
- Monitor and Audit: Continuously monitor for unauthorized access to Secrets and audit logs regularly.
- Disable Secrets Access to Unauthorized Pods: Implement network policies to prevent accidental exposure.
