I read a few different Discourse topics about this but can’t figure out why ansible/group_vars is not ignored, seeing as it contains sensitive db credentials. It seems to go against this Twelve-Factor App principle:
“A litmus test for whether an app has all config correctly factored out of the code is whether the codebase could be made open source at any moment, without compromising any credentials.”
For instance, if the Roots Example Project (https://github.com/roots/roots-example-project.com) was a real project, it looks as if those credentials would be freely visible for anyone inspecting the repo on GitHub.
I’m sure I’m misunderstanding it. Can anyone clarify for me?
1 Like
You aren’t misunderstanding it at all and it’s awesome that you’ve thought about this.
We do have a Wiki page which briefly talks about this.
Putting “secret” credentials in group_vars is a compromise basically. bedrock-ansible has a very wide scope of use. It could be used by:
- devs who want a Vagrant VM only
- individual developers to create server and then pass them off
- developers working on short term projects
- teams working on long term projects
When dealing with “secrets” it’s hard to design a proper solution when keeping it flexible. Take teams for example: you could Git ignore the files, but how would your team members also get the information?
Most credentials end up being stored in plain text somewhere. That might be in a private GitHub/Bitbucket repo, a private Git server, Amazon S3, etc. Or it might be people sending master passwords around via plain text email/chat. Or attaching them to some other unsecure software system (think Wiki, ticketing system, etc).
That being said, we should think about this again and maybe strongly recommend the use Ansible Vault more.
4 Likes