4 ms·

>> "The simplest hack is to use a configuration management tool" >> "You can also use a credential management suite for a more robust solution" > Imagine this

by dozzie 10y ago

>> "The simplest hack is to use a configuration management tool" >> "You can also use a credential management suite for a more robust solution" > Imagine this, you use consul to store your secrets, as you wrote up a script for Ansible to look things up, this include secrets. Great, but you need to authorize. So you need to keep the token somewhere. You see, the problem springs from you mistaking Ansible for configuration management tool. It is not, it is somebody's deployment script. What you want is CFEngine, Puppet, or Chef, and you need it download configuration templates and fill them with secrets on the server that you want configured. (CFEngine can easily do that; Chef -- probably, since it's not a standalone tool, but a Ruby framework, so you have ERB at your disposal; Puppet? no idea if it can use ERB in masterless mode.) Now you need to solve the problem how to get the secrets to the server being configured. This would be easy if you had a specialized database service that ships credentials, and only the ones that are relevant to the server are sent. It's a pity we don't have such a database (or at least I am not aware of any), but it's not exactly a famine problem to solve, it's just juggling with access lists and some simple log replication protocol.

yeukhon 10y ago
When you said > "You see, the problem springs from you mistaking Ansible for configuration management tool. It is not, it is somebody's deployment script." You lost credibility from my PoV. Ansible is capable of doing what Chef can do. Ansible can use dynamic inventory which means Ansible can use dynamic secret infrastructure. That's not the default mode of Ansible out of box, but much like Chef and Puppet, Ansible is made up of somebody's deployment script as well. You and I didn't just write up Puppet out of no where, and there are community plugins available for used, and those plugins are just somebody else's deployment script/component.
- dozzie 10y ago
  > Ansible is capable of doing what Chef can do. So is gawk, except nobody tries to shoehorn it to do so or claim that it's designed for this. Ansible's very architecture and operation model are causing troubles where should be none, like applying configuration changes to hosts that happened to be temporarily down. > [...] much like Chef and Puppet, Ansible is made up of somebody's deployment script as well. I don't know the history of Chef, but I assure you that Puppet was never somebody's deployment script that happened to be published and gain traction. It was designed ground up as a configuration management tool, after its author deemed cfengine 2.x too troublesome, which again was a configuration management since its early 2.0 days (and probably since 1.0 version). Configuration management requires completely different operation mode than deployment; one is asynchronous and unattended, the other is a synchronous list of steps to take and often needs to stop on the first trouble to appear.
chousuke 10y ago
Puppet can do templates just fine in masterless mode. Though nowadays, you should use EPP instead of ERB for robustness (strong typing helps a lot) Your puppet master can be your credential "database" if you use eg. hiera+eyaml. You still need to secure your puppetmaster, obviously, but since it uses public key crypto, you don't even need to make it possible for developers to decrypt secrets. Master key leaks would still be a problem, though. There are various caveats when working with sensitive data in Puppet (4.something added the "Sensitive" data type which prevents things from leaking into catalogs) but since puppet clients are authenticated with client certificates, you can control which server should have have access to what data.
eamann 10y ago
> you need it download configuration templates and fill them with secrets on the server that you want configured. Ansible can also use configuration templates just fine. It can also support secrets management, depending on how you want to store the secrets. The first tool covered in the series itself was Credstash (https://tozny.com/blog/crypto-tools-for-devops-credstash/ https://tozny.com/blog/crypto-tools-for-devops-credstash/). Ansible supports retrieving secrets from Credstash natively, either for use in commands or when populating templates: http://docs.ansible.com/ansible/playbooks_lookups.html#the-credstash-lookup http://docs.ansible.com/ansible/playbooks_lookups.html#the-c... Git-crypt is but one solution for storing secrets _next to_ the code that uses them. Credstash is another for storing secrets in another, server-accessible location. Both can work with tools like Ansible (or Puppet or Chef or Salt). From the tone of the above (and your other responses) you're not a heavy Ansible user. That's fine. Use the tool you're comfortable with. But don't try to turn people away from an equally useable alternative to something you _do_ use just because it's not your tool of choice.

by dozzie 10y ago

yeukhon 10y ago

When you said > "You see, the problem springs from you mistaking Ansible for configuration management tool. It is not, it is somebody's deployment script." You lost credibility from my PoV. Ansible is capable of doing what Chef can do. Ansible can use dynamic inventory which means Ansible can use dynamic secret infrastructure. That's not the default mode of Ansible out of box, but much like Chef and Puppet, Ansible is made up of somebody's deployment script as well. You and I didn't just write up Puppet out of no where, and there are community plugins available for used, and those plugins are just somebody else's deployment script/component.

dozzie 10y ago
> Ansible is capable of doing what Chef can do. So is gawk, except nobody tries to shoehorn it to do so or claim that it's designed for this. Ansible's very architecture and operation model are causing troubles where should be none, like applying configuration changes to hosts that happened to be temporarily down. > [...] much like Chef and Puppet, Ansible is made up of somebody's deployment script as well. I don't know the history of Chef, but I assure you that Puppet was never somebody's deployment script that happened to be published and gain traction. It was designed ground up as a configuration management tool, after its author deemed cfengine 2.x too troublesome, which again was a configuration management since its early 2.0 days (and probably since 1.0 version). Configuration management requires completely different operation mode than deployment; one is asynchronous and unattended, the other is a synchronous list of steps to take and often needs to stop on the first trouble to appear.

chousuke 10y ago

Puppet can do templates just fine in masterless mode. Though nowadays, you should use EPP instead of ERB for robustness (strong typing helps a lot) Your puppet master can be your credential "database" if you use eg. hiera+eyaml. You still need to secure your puppetmaster, obviously, but since it uses public key crypto, you don't even need to make it possible for developers to decrypt secrets. Master key leaks would still be a problem, though. There are various caveats when working with sensitive data in Puppet (4.something added the "Sensitive" data type which prevents things from leaking into catalogs) but since puppet clients are authenticated with client certificates, you can control which server should have have access to what data.

eamann 10y ago

> you need it download configuration templates and fill them with secrets on the server that you want configured. Ansible can also use configuration templates just fine. It can also support secrets management, depending on how you want to store the secrets. The first tool covered in the series itself was Credstash (https://tozny.com/blog/crypto-tools-for-devops-credstash/ https://tozny.com/blog/crypto-tools-for-devops-credstash/). Ansible supports retrieving secrets from Credstash natively, either for use in commands or when populating templates: http://docs.ansible.com/ansible/playbooks_lookups.html#the-credstash-lookup http://docs.ansible.com/ansible/playbooks_lookups.html#the-c... Git-crypt is but one solution for storing secrets _next to_ the code that uses them. Credstash is another for storing secrets in another, server-accessible location. Both can work with tools like Ansible (or Puppet or Chef or Salt). From the tone of the above (and your other responses) you're not a heavy Ansible user. That's fine. Use the tool you're comfortable with. But don't try to turn people away from an equally useable alternative to something you _do_ use just because it's not your tool of choice.