Can you keep a secret? It’s an important ability for IT pros running a Kubernetes environment.
No, we’re not talking about your personal secrets. That would be weird. Rather, we’re talking about the cleverly named Kubernetes object that is one of the container orchestration platform’s built-in security capabilities. In short, a “secret” in Kubernetes is a means of storing sensitive information, like an OAuth token or SSH key, so that it’s accessible when necessary to pods in your cluster but protected from unnecessary visibility that could create security risks.
What is a Kubernetes Secret?
As the Kubernetes documentation notes, “Putting this information in a Secret is safer and more flexible than putting it verbatim in a Pod definition or in a container image.”
[ Want to help others understand Kubernetes? Read also: How to explain Kubernetes in plain English and How to explain Kubernetes Operators in plain English. ]
Secrets could be thought of as a relative of the least privilege principle, except instead of focusing on limiting the access of individual users to that which they actually do to get their work done, they focus on giving your applications the data they need to properly function without giving them (and the people that manage them) unfettered access to that data.
Put another way, Secrets help fulfill a technical requirement while solving a problem that rises out of that requirement: Your containerized applications need certain data or credentials to run properly, but how you store that data and make it available is the kind of thing that keeps security analysts up at night.
“Sensitive data like passwords or keys are often required for operation of workloads in Kubernetes,” says Tsvi Korren, field CTO at Aqua Security. “Kubernetes Secrets are the mechanism that facilitates the use of the sensitive data, in a way that does not expose them when defining or viewing the operations of Kubernetes itself.”
[ Kubernetes terminology, demystified: Get our Kubernetes glossary cheat sheet for IT and business leaders. ]
Kubernetes Secrets defined, three ways
Let’s add a few more clear-cut definitions of Secrets to your arsenal that should help you either get up to speed as necessary or explain the concept to others on the team.
1. “As applications run in Kubernetes, apps need credentials to interact with the surrounding infrastructure or another application. Those credentials are kept in Kubernetes, and your applications can use a credential by specifying the name of a Secret as opposed to having the application keep the contents of the Secret.” –Eric Han, VP of product management at Portworx. (Han was also the first Kubernetes product manager when it was still an internal system at Google.)
2. “Kubernetes Secrets provide a means to protect sensitive information in a way that limits accidental exposure and provides flexibility in how the information is utilized. Secrets are only accessible to Pods if they are explicitly part of a mounted volume or at the time when the Kubelet is pulling the image to be used for the Pod. This prevents the need to store sensitive information in a Pod image, which mitigates the risk that data is compromised and makes it easier to vary things like credentials, cryptographic keys, etc. for different pods.” –Jonathan Katz, director of customer success & communications at Crunchy Data
3. “Kubernetes Secrets are a way to store and distribute sensitive information – think passwords, or an SSL certificate – that are used by applications in your Kubernetes cluster. Importantly, the declarative nature of Kubernetes definitions allows third-party solutions to be integrated with the Secret management.” –Gary Duan, CTO at NeuVector
[ Also read: Kubernetes terminology explained. ]
How and why to create Kubernetes Secrets
The process for creating a Secret is also relatively simple. (You can get specific instructions for using Secrets in the Kubernetes documentation.) Korren from Aqua Security describes it thusly, and following along can also help illuminate the purpose and benefits:
“The process is that a trusted person or source defines a Secret by creating a logical name and entering the sensitive data,” Korren explains. “From then on, when a workload is defined to use that data – for example, web server login to a database – the workload definition will refer to the logical name. That way, the operators of Kubernetes never see the actual sensitive data. Other benefits are that the Secret can be updated independently from the workloads and by other authorized users.”
Secrets are getting into the nitty-gritty of Kubernetes functionality, so it’s possible you won’t need to explain how they work to non-technical folks very often. On the other hand, if you’re in the earlier phases of running containerized application in a production environment, you might be fielding questions from different stakeholders about security and other data management concerns.
Being able to explain the Secrets concept is a good way to illustrate Kubernetes’ native security features. Plus, Han notes (like Duan above) that multiple cloud providers have their own Secrets management systems that integrate with Kubernetes Secrets too: “This allows centralization of additional functionality, and in the end, results in a more robust and safer system.”
Kubernetes Secrets security: The browser analogy
If you do need to explain the concept to non-technical folks, or if someone just isn’t grasping the idea, Han recommends comparing it much more widely known tool – your web browser and how it stores and auto-fills passwords for the various sites you use.
"When you make a purchase online, your browser can remember the passwords to all your online accounts. This auto-fill feature makes it possible to have more complex and unique passwords while making the experience easy,” Han explains. “Because we have so many passwords, your browser labels each account with a name and stores the password. If you look for the password in your browser, those passwords will appear to be blanked-out, like a Secret. The experience with Kubernetes Secrets is like what’s happening in your browser.”
Like most security tools and strategies, Secrets aren’t foolproof. Simply putting sensitive information in a Secret is no guarantee that it will be secure. Rather, Secrets should be used as part of a larger Kubernetes security strategy.
[ Want more security pointers? Read Kubernetes security: 4 strategic tips and Multi-cloud: 8 tactics for stronger security. ]
The least privilege principle again applies here, both for users (someone has to be responsible for creating and managing Secrets, which means they have access to the information) and for applications. Duan from NeuVector and Korren from Aqua Security both describe it as a matter of access control: Don’t grant it willy-nilly, and keep tabs on which users and services have it.
What are some other Kubernetes Secrets best practices? Let’s dig in:
