There are many ways of managing secrets in Kubernetes, some ways are simpler than others but when researching this topic for my project at work I found that there are drawbacks to many of these approaches. When managing your secrets in any modern software system, one needs to think of a number of important aspects. For my project, these were the most important:

1. **All secrets must be stored in version control. **This is a vital aspect for any Helm-based deployment, in my opinion, if any of your pipeline steps involve manual intervention, i.e. populating secrets, you effectively diminish the benefits of an automated CD pipeline.
2. **All packaged Helm charts must be encrypted. **When publishing your charts to a chart museum for your project, it is important that no secrets are stored in the clear. This means that secrets must be encrypted before you package a chart and put it in a chartmuseum. Conversely, secrets should only be decrypted at runtime during the install/upgrade phase.
3. **One tool to rule them all — Helm! **Another requirement for me, and this is more of a personal one, was to rely only on Helm. In the case of Helm-secrets for example; non-CNCF projects tend to end up on the scrap-heap after some time or go in a different direction. Relying on small fringe tools has come back to bite me when incompatibilities arise when core software is upgraded, leaving you in the lurch.

#helm #kubernetes #helm-chart