What are Kubernetes Secrets?
A secret is a credential or other piece of confidential information (like a TLS certificate, password, or configuration file) that should only be seen or used by a designated application or user. This is different from a Kubernetes Secret.
A Kubernetes Secret is an object that is used to separate confidential data from an application's code, making that information safer because it isn’t exposed within the code itself.
To help keep this distinction clear for readers, we will use the word “credential” (meaning any type of confidential information) instead of “secret” wherever possible throughout this learning path, and will fully name Kubernetes Secrets as such when referencing them.
What will you learn?
- What Kubernetes Secrets are used for and how they work
- What the main security challenges associated with Kubernetes Secrets are
What can you use Kubernetes Secrets for?
Although Kubernetes Secrets are stored, by default, unencrypted in the etcd, organizations can protect them by enabling role-based access control (RBAC), which allows them to outline exactly who is allowed to view or use them. Because Kubernetes Secrets can be created and managed separately from the applications and workloads that use them, there is less risk of the sensitive data being exposed when people are working with or changing workload settings (like managing Pods). Additionally, organizations have more control over how Kubernetes Secrets are managed in the cluster, such as making sure they are not saved to a hard drive where they could be easily exposed.
Kubernetes Secrets can be used to set environment variables for a container or to provide credentials like SSH keys or passwords to applications running in your cluster. They can also be used to allow the kubelet (the agent that runs on each node in a Kubernetes cluster) to pull container images from private registries. The Kubernetes control plane bootstraps token Kubernetes Secrets as a way to automatically register new nodes to the cluster.
How do Kubernetes Secrets work?
To handle Kubernetes Secrets in a Red Hat® OpenShift® or Kubernetes cluster, application developers often use git (a version control system) as the primary source for managing configuration files that are deployed to the cluster. While access to this repository can be secured, it might not always be enough to protect sensitive information.
During deployment, Kubernetes Secret resources are created on the cluster by the API server and stored in etcd. These can then be used as:
- files that are mounted on containers;
- an environment variable for the container;
- by the kubelet (the agent on each node) when it needs to pull a container image
In all of these cases, sensitive information is decoded just before it's used by the application.
Learn more at: A Holistic approach to encrypting secrets, both on and off your OpenShift clusters
What are the main security challenges associated with Kubernetes Secrets?
By default, Kubernetes Secrets aren't truly secret—they're stored in base64, which is not a form of encryption. This means anyone with access to the cluster can easily decode the information and view sensitive data. This is a significant risk, as misconfigured access control can allow unauthorized users to retrieve them within a namespace.
While Kubernetes Secrets are stored in etcd, they're vulnerable if the database itself is compromised. Additionally, even if they are encrypted, the keys to decrypt them are often accessible to cluster administrators, which is another potential security risk.
Manual rotation is also a challenge. If an organization is not consistently and automatically rotating credentials, they can end up with outdated or compromised keys across clusters.
This means that DevSecOps administrators have two primary challenges:
- how to protect and manage sensitive data before it reaches the cluster during the build and deployment phases;
- how to secure sensitive data while applications are running inside the cluster
You are now ready to learn how Kubernetes Secrets are managed with Red Hat.
