How to handle passwords
51 views
Skip to first unread message
Kurt Miebach
Oct 30, 2011, 7:04:09 PM10/30/11
to slack...@googlegroups.com
How do you handle passwords? Some roles create unix user accounts or database accounts and the easiest thing is to have the password in the role scripts.
But this way all servers receive the same passwords. And the passwords are part of the version controlled slack roles directory.
Any ideas you can share?
But this way all servers receive the same passwords. And the passwords are part of the version controlled slack roles directory.
Any ideas you can share?
Alan Sundell
Nov 1, 2011, 6:27:07 PM11/1/11
to slack...@googlegroups.com
That's a good question. I don't think I have a "one-size-fits-all secret distribution" answer for you. I've never seen anyone solve this all the way. But I can share some (unfortunately verbose) thoughts.
First, though, just to get this out of the way, for passwords, I presume that you meant distributing hashed passwords (or rather, I hope you're lucky enough that your use case permits this), with a suitably difficult hash algorithm, so that the secrets you are distributing are substantially less sensitive. And I presume you've looked at various centralized and/or asymmetric authentication schemes (but those really just push the problem up a level).
Anyway, the more general problem of how to distribute secrets (e.g. key material) securely and effectively is an old and much-discussed practical problem.
Some people just give up on this problem and copy secrets around manually. If you want to go that path, it can be helpful to have your preinstall check to see if the secret has been installed, and if not, exit 1 and maybe print some useful explanation/instructions/document URLs on STDERR in case an operator is looking at it.
If you want machines to get their secrets automatically, you need some reliable way to authenticate the machine, so you usually have some sort of enrollment step where a human verifies and attests that a certificate or other identifier is associated with a particular machine. And then you have some central server that uses that identity for authorization purposes and gives you the secrets you're allowed to have (or it serves secrets encrypted with the public half of your identity, or you use your identifying info directly, or you sign some other secret and have that be trusted -- lots of ways to skin that cat once you've enrolled and established identity).
The former part (enrollment) is the difficult, chicken-and-egg part. Ideally, this would happen when you can really verify the identity of the machine, for example when you first have physical access (e.g. between unboxing it and racking it), and some secure hardware module (like a TPM or smartcard) would generate a keypair internally, give out the public half for enrollment (possibly reinsertion of that public half signed by an authority), and allow insertion of some public keys for the infrastructure (so that the machine could check the signatures during OS install, which is a different, but related, problem). The operator could potentially just plug something into a USB port and scan a few barcodes and be done.
I've never seen this implemented all the way, though. Usually people cheat somewhere in the name of expedience.
For an example, Puppet's usual enrollment process is a pretty reasonable compromise -- it involves saving the first copy of the server cert it sees and sending a CSR to the server for an operator to sign manually. The "cheat" with this is that the initial key exchange is just happening over the network, and the operator is probably not verifying that the CSR really identifies the server in question and not some clever attacker impersonating it at the right moment so he can get your secrets and maybe prompt you to log in and give him some more. (The server cert has similar problems.) But, in practical terms, this does *greatly* narrow the window of attack (you have to strike during the enrollment of a new server), which is way better than nothing, especially if you don't enroll a lot.
Back to slack, it is of course very primitive and doesn't even do that much for you. All the setup is left up to you.
Since the default setup is to use rsyncd over ssh, you can use SSH host keypairs for authenticating both the clients and the slack master. I've heard of multiple people doing this; you generally need to enroll the SSH hostkeys for machine identity, anyway -- if people are going to be SSHing into the machines, you want them in a known_hosts database. So, you can take that known_hosts data and generate an authorized_keys file for sshd that calls rsync with the expected arguments via a wrapper. This is pretty simple to get going.
Storing the host keys locally somewhere that persists across installs is also handy (no more SSH complaints after a reinstall), especially if you reinstall a lot. Using the SSH authentication information to provide authorization for particular secrets I have not seen done, but you could insert something in the rsync wrapper being called from authorized_keys to tell rsync to grant or deny access to certain paths (maybe if someone has done this, they will share).
This doesn't address the point about keeping secrets in version control. However, it's worth noting that slack is just calling rsync on a bunch of files, so nothing says the entire repository has to be under the same version control system. Slack doesn't care where the files come from; just that they are there, so you can get your secrets into the source directory however you like.
If I wanted to do this "properly", though, I'd probably distribute the secrets outside of slack, with something that supported HTTPS client certs. It probably would be easier to build and maintain and would be a lot more flexible than rsyncd. And there's something to be said for not having your secret store be as simple as possible (i.e. not also being your config management server), and about not making slack overly complicated either. The two problems have different needs -- secret management needs authentication and authorization structure and of course secrecy; config management needs version control and benefits from transparency and ease of access.
Sorry that was so long; hope it helps :)
--Alan
First, though, just to get this out of the way, for passwords, I presume that you meant distributing hashed passwords (or rather, I hope you're lucky enough that your use case permits this), with a suitably difficult hash algorithm, so that the secrets you are distributing are substantially less sensitive. And I presume you've looked at various centralized and/or asymmetric authentication schemes (but those really just push the problem up a level).
Anyway, the more general problem of how to distribute secrets (e.g. key material) securely and effectively is an old and much-discussed practical problem.
Some people just give up on this problem and copy secrets around manually. If you want to go that path, it can be helpful to have your preinstall check to see if the secret has been installed, and if not, exit 1 and maybe print some useful explanation/instructions/document URLs on STDERR in case an operator is looking at it.
If you want machines to get their secrets automatically, you need some reliable way to authenticate the machine, so you usually have some sort of enrollment step where a human verifies and attests that a certificate or other identifier is associated with a particular machine. And then you have some central server that uses that identity for authorization purposes and gives you the secrets you're allowed to have (or it serves secrets encrypted with the public half of your identity, or you use your identifying info directly, or you sign some other secret and have that be trusted -- lots of ways to skin that cat once you've enrolled and established identity).
The former part (enrollment) is the difficult, chicken-and-egg part. Ideally, this would happen when you can really verify the identity of the machine, for example when you first have physical access (e.g. between unboxing it and racking it), and some secure hardware module (like a TPM or smartcard) would generate a keypair internally, give out the public half for enrollment (possibly reinsertion of that public half signed by an authority), and allow insertion of some public keys for the infrastructure (so that the machine could check the signatures during OS install, which is a different, but related, problem). The operator could potentially just plug something into a USB port and scan a few barcodes and be done.
I've never seen this implemented all the way, though. Usually people cheat somewhere in the name of expedience.
For an example, Puppet's usual enrollment process is a pretty reasonable compromise -- it involves saving the first copy of the server cert it sees and sending a CSR to the server for an operator to sign manually. The "cheat" with this is that the initial key exchange is just happening over the network, and the operator is probably not verifying that the CSR really identifies the server in question and not some clever attacker impersonating it at the right moment so he can get your secrets and maybe prompt you to log in and give him some more. (The server cert has similar problems.) But, in practical terms, this does *greatly* narrow the window of attack (you have to strike during the enrollment of a new server), which is way better than nothing, especially if you don't enroll a lot.
Back to slack, it is of course very primitive and doesn't even do that much for you. All the setup is left up to you.
Since the default setup is to use rsyncd over ssh, you can use SSH host keypairs for authenticating both the clients and the slack master. I've heard of multiple people doing this; you generally need to enroll the SSH hostkeys for machine identity, anyway -- if people are going to be SSHing into the machines, you want them in a known_hosts database. So, you can take that known_hosts data and generate an authorized_keys file for sshd that calls rsync with the expected arguments via a wrapper. This is pretty simple to get going.
Storing the host keys locally somewhere that persists across installs is also handy (no more SSH complaints after a reinstall), especially if you reinstall a lot. Using the SSH authentication information to provide authorization for particular secrets I have not seen done, but you could insert something in the rsync wrapper being called from authorized_keys to tell rsync to grant or deny access to certain paths (maybe if someone has done this, they will share).
This doesn't address the point about keeping secrets in version control. However, it's worth noting that slack is just calling rsync on a bunch of files, so nothing says the entire repository has to be under the same version control system. Slack doesn't care where the files come from; just that they are there, so you can get your secrets into the source directory however you like.
If I wanted to do this "properly", though, I'd probably distribute the secrets outside of slack, with something that supported HTTPS client certs. It probably would be easier to build and maintain and would be a lot more flexible than rsyncd. And there's something to be said for not having your secret store be as simple as possible (i.e. not also being your config management server), and about not making slack overly complicated either. The two problems have different needs -- secret management needs authentication and authorization structure and of course secrecy; config management needs version control and benefits from transparency and ease of access.
Sorry that was so long; hope it helps :)
--Alan
--
You received this message because you are subscribed to the Google Groups "slack users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/slack-users/-/9555HemFw2wJ.
To post to this group, send email to slack...@googlegroups.com.
To unsubscribe from this group, send email to slack-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/slack-users?hl=en.
Henning Sprang
Nov 6, 2011, 11:50:23 AM11/6/11
to slack...@googlegroups.com
Hi Kurt,
On Mon, Oct 31, 2011 at 12:04 AM, Kurt Miebach <kwmi...@gmail.com> wrote:
> How do you handle passwords? Some roles create unix user accounts or
> database accounts and the easiest thing is to have the password in the role
> scripts.
Interesting question and I thtought about that before,
Do you really mean user account passwords - or what types of passwords?
For small infrastructure where I actually used passwords, I had the
secret data on an encrypted memory stick and some scripts to deploy
them. I could access systems after fresh install because I deployed
ssh public keys.
On larger and enterprise infrastructures, I guess you really want to
use something like nis and/or ldap to manage access of users to the
systems.
Henning
Reply all
Reply to author
Forward
0 new messages