What's the best way to manage and track secrets created years ago?
Asked by
CuriousCoder42
I'm curious about how teams effectively manage the lifecycle of their secrets. Recently, we spent quite a bit of time troubleshooting a legacy system that broke due to an API key created back in 2022 by someone who no longer works here. This key was hardcoded in a configuration file, never rotated or tracked, and just sat there until it expired. We've faced this issue multiple times, with database credentials, API keys, and tokens scattered across repos, Slack threads, and old .env files. When someone leaves or a service is decommissioned, it becomes challenging to know which secrets need to be revoked. I'm looking for real-world workflows. How do others handle this? Do you have a system for tracking creation dates and owners of secrets? Do you auto-expire them after a set time? What tools or processes actually help you identify which secrets are still in use? We use AWS Secrets Manager, but I'm curious about other effective strategies to tackle the "forgotten secret" issue.
Answers
You might want to check out Vault Radar; it was created specifically to address problems like this.
Reply to this answer
Our team manages secrets through infrastructure-as-code, utilizing SOPS with version control. This way, we enjoy all the benefits that come with version control for our secrets.
Reply to this answer
A lot of secret managers offer version control, like Vault or AWS Secrets Manager. You might want to rethink your approach. Services like Vault also provide plugins for key rotation and temporary access, which can be super beneficial.
Reply to this answer
To be honest, many teams haven’t really solved this. Usually, secrets are assigned a team owner in the metadata rather than an individual, since employees come and go. It's crucial to enforce this at the secrets manager level to prevent creating secrets without designated owners. If your manager can't show when a secret was last accessed, you're basically blindfolded. AWS Secrets Manager does integrate with CloudTrail, so setting up alerts for secrets that haven't been used in over 60 days is a good step. As for the hardcoded config issue, that’s best addressed with tools like TruffleHog or GitLeaks during CI and regular scans of deployed configs.
Reply to this answer
It seems Vault Radar might not fully address the issue at hand, but if you're using a cloud service like AWS, relying heavily on machine roles could help. Ensuring your pipelines run on machines with specific roles is a smart move.
Reply to this answer
Add your answer
Answers are reviewed before publication.
Related Discussions