There are these relevant questions questions:Strategy for keeping secret info such as API keys out of source control?How do you deal with configuration files in source control?How to version control config files pragmatically?But as far as I can tell, they deal with the opposite side of the problem. So yes, we've designed a good application that has no secrets stored in it or its repository. They either pull them from the environment variables or from files stored on the system. Great, awesome, secure, right?But what about our secrets? Where do they come from? Do we store these in another vcs repository? Do they only exist in an encrypted database?Obviously we want developers to have their own credential sets - but we're going to need to have credentials for our test/preprod/prod servers.How do we keep those secure? Of course we want them accessible to the systems that need them...
Where should you store/how should you control access to application secrets?
security;configuration
If you're asking how to manage your own keys then there are 2 places to store them:For dev/test - you might as well put them in the SCM repo. Unless your repo is publicly accessible.For production, you want to store them with a single point of authority, either somebody (with a deputy) who keeps the originals on a CD or USB drive in a firesafe or similar. Copies of these can then be given to the relevant people who need to deploy them. So (eg) a DBA who creates the DB and sets up the user accounts associated with it will be given the passwords and accounts to use. This can be emailed to him, assuming you trust your email provider, or handed on a scrap of paper that is eaten immediately afterwards if you are really paranoid.In many cases you don't need to be quite so secure - the DBA may create the passwords and user accounts to use himself, but he must them tell someone (preferably the contact who keeps this information) what they were in case of accident. Otherwise, you use the OSs features to secure the details - either creating accounts using LDAP or AD, or putting certificate files into protected directories and ensuring they are secured so only the correct user accounts can access them.