Anshika Varshney takes us through some secrets management:
Secret management is a critical part of working with Kubernetes. When working with Kubernetes, you’ll often need to store and use sensitive information — like database passwords, API keys, and certificates. That’s where Kubernetes Secrets come in. But here’s the thing: while Kubernetes provides a way to store secrets, using them incorrectly can still expose your sensitive data.
This blog will walk you through:
- What Kubernetes Secrets are
- How they work
- Common mistakes (the wrong way)
- Best practices (the right way)
- Real-life examples and configurations
Read on for the full article. I do want to iterate what I consider the most important of Anshika’s points: these things should never go into source control. The problem is, source control history is a lot more permanent than people customarily think about, so if you accidentally checked in a password in a config file somewhere, then got rid of the line with the password in it, a bad person with access to your source control can still look at history and find that password. The mechanism to rewrite Git history to remove a line’s existence is purposefully difficult, so a lot of developers don’t even know that it’s possible. But even then, if you’re hosting on someplace like GitHub and forks are enabled, rewriting history in your fork doesn’t rewrite it in somebody else’s fork, so again, a bad person with a fork from the right time frame could still see your exposed password.
The only fix is to cycle credentials if you ever do accidentally expose a password or key in source control files.