The context of the question is Secrets management.
As the title says, how do you know which secrets and credentials of your production services were used, and by whom/what?
DevOps Stack Exchange is a question and answer site for software engineers working on automated testing, continuous delivery, service integration and monitoring, and building SDLC infrastructure. It only takes a minute to sign up.Sign up to join this community
The short answer: you would need to use a secret management system that provides 'audit logs'.
There are many options for handling secrets out there, but unless the tool you use has audit logging, you'll never truly know for sure what credential was used where.
I see you mentioned using Hashicorp's Vault. That's a really good one. They have audit logging built in; they call it 'Audit Devices', which can be enabled with a simple command.
Again, there are many perfectly valid options for handling secrets: Chef vault, 1password, environment variables injected by your build instances, home-grown solution using encrypted files stored on object storage, etc.... However, unless the system specifically says it provides audit logging, you'll never truly know what was used when and where.
You can design a secrets system with the best intentions, and make many rules that employees have to follow in regards to have the secrets are accessed, but for auditing purposes, you want to know where the rules have been broken. If you have a firm requirement to always know when and where secrets where used, I recommend you stick with something like Hashicorp Vault, turn on Audit Devices, and then ship the log somewhere for storage or processing.
Totally stack dependent but as mentioned HashiCorp Vault will provide audit logs, and the other I am familiar with is AWS Parameter Store and Secrets Manager which will provide logs to CloudTrail. The AWS approach is a great one for those already using AWS and looking for an easy barrier to entry. Vault is more powerful but with that comes more complexity to install, run, and maintain (the open-source version at least.. enterprise is awesome but pricey last time a company i work for inquired). The worst thing you can do in my opinion is try to write your own tool for this. Whatever tool you decide on, or if you try to write it, logging is an absolute must