Proper management of an application's secrets has always been a challenge. New challenges came with the adoption of the cloud. There's a great OWASP presentation about the reality and challenges of storing secrets in the cloud.
You might be surprised to hear that storing secrets into the source code is one of the solution (or "architecture") presented. That's because, right now, there is no perfect architecture or way of doing this. In the end, your secrets might be encrypted... but what is guarding the encryption key? "Turtles all the way down", they said.
Every type of secret management has its strengths and weaknesses and the presentation already covers that. Instead, I'll try to go over some of the features you might be looking for in an secret (credential) management solution:
- Access control: can you give write access to admins and read access to applications? Can you limit what applications are able to read (application A has access only to those secrets)?
- Audit logs: required for many compliancy reports and a good way to figure if something is awry
- Secure storage of the secrets: how is the solution storing the secrets? Encrypted DB? Encrypted FS? Who/what holds the encryption key, if any? How is this key used - once at startup and then securely discarded?
- Keys/passwords rotation or renewal: if a secret is compromised, can you revoke it and send an updated secret to the applications? Can/should the applications pool the secret management service?
- Compatibility: Some of these solutions offer tight integration with certain languages or framework. Some offer REST API. Are you interested in this?
By looking at these items, how they are important to you and how they are implemented by the solution, you will be able to choose one of the secret management service out there.