Secrets are so widely used in DevOps environments that there simply can’t be a one-size-fits-all for managing them. We have development secrets used by developers, build secrets, application secrets, infrastructure secrets, etc.
Even for the most mature DevSecOps organizations or teams, secrets management is very difficult to master, because it is a matter of striking a right balance between security and accessibility. This second point is very important for one simple reason: in modern development teams, secrets are required by everyone. Making it hard to use secrets will inevitably lead to the bypassing of the protective layers in place, and lead to practices such as hardcoding them.
In practice, it is easy to see that there is a gap between theory and practice when it comes to handling and sharing credentials in a team, a department, or an organization. For example, the organization may pay for a cloud-based secrets manager, a vault, or maybe even for a dedicated team to administrate these tools, which makes it falsely think it has solved this problem. But under further scrutiny, it would realize that the long-lived credentials are also stored on the devs’ local machines for convenience.
There are various ways with which secrets can be managed in the software development lifecycle. Explore the following options with DevOps, Site Reliability Engineering, or Platform Engineering teams before deciding which one is the right approach for your organization and various development teams:
Hard-coded in source code and templates(please, don't.)
- Grouping secrets in common, unencrypted configuration files, such as
.env(outside of the git repository)
- Encrypting secrets in a GitOps or sealed secrets approach, with decryption key stored in a vault
- Storing secrets in a vault and distributing them through a secrets management service
- Generating (ephemeral) secrets just-in-time, through a complex secrets management infrastructure