Chapter 7. Secrets Management
Your application code often needs access to secret information, like credentials, in order to do its job. For example, if you run an e-commerce site, some components will need access to a product database, and other components likely will need to be able to manage user or payment information. These components will need the right access tokens or username/password combinations so they can access the data they need to view or manipulate.
In this chapter, we consider the options for passing secret information into your code running under Kubernetes. Kubernetes provides a “secret” resource for this purpose, but there are different ways of using these secrets that you will want to weigh. In addition, you also need to be aware of some aspects of the Kubernetes secrets implementation from a security perspective.
Applying the Principle of Least Privilege
The principle of least privilege has two consequences on secrets management in Kubernetes:
We want to ensure that containerized code can read only the secrets that it needs.
It’s a good idea to have a different set of secrets for different environments (like production, development, and testing). The development and test credentials can be shared with a wider set of team members without necessarily giving them full access to the production credentials.
Since secret values protect sensitive data, we want them to be hard to access. Ideally, they should by protected at rest and in ...