It is common sense not to store passwords/credentials into SCM.
I would like to know then what would be a good strategy for storing passwords/credentials in the context of continuous delivery.
- Where and how do I store credentials?
- How do I retrieve and use those credentials/passwords?
It’s not “common sense” not to store credentials in source control. That really depends on your situation. It’s a perfectly acceptable practice if the developers would already have access to production resources, or if the accounts are read-only and there’s no privacy issue, or if the credentials are encrypted in some way.
If you’re going as far as building your own deployment pipeline, then you would usually use a configuration management tool, which will handle all of the storage, encryption, users/privileges, etc. There are open-source tools like ESCAPE which provide this in a REST API, and other commercial tools (and possibly some other open-source tools) that provide similar functionality.
Some teams go with full-blown release management software like those from Atlassian, Red Gate, Thoughtworks, Serena, DevOpsGuys, Octopus, Cachet, etc. I’m not going to recommend a specific one because it depends entirely on your business structure and technology stack. But suffice it to say that most if not all of them will integrate configuration management into the process, and allow you to define “environments” and configurations to go with those environments; when you deploy a specific component to a specific environment, it takes the configuration files and replaces/transforms them with the correct settings for that environment.
Basically it depends on your budget and time. If I had low time/low budget, I’d keep storing them in source control; encrypt them if necessary. If I had lots of time but still a low budget, I’d build a deployment pipeline using an off-the-shelf configuration management tool. And if I had plenty of money to throw around then I’d just invest in one of the commercial release management tools; they really do save a lot of time and it’s easier for a paranoid IT infrastructure team to trust a well-known commercial tool than it is for them to trust something you hacked together in a few days.
I found good ideas here such as:
- Encrypting/decrypting data (see nice and detailed post here by John Resig)
- Using a separate configuration data repository