Re: [Puppet Users] Managing private key files; content=>file vs. binary content.
On Nov 10, 2010, at 4:29 AM, Chris wrote: > How are other people getting around this? Do you just allow all > clients to access all keys? Is there a native type, or an auth.conf > trick, that I'm missing? Or a more binary-friendly encoding than JSON/ > PSON ? I send a different message with a rather long hack as a workaround, but I would also file a bug for this. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Managing private key files; content=>file vs. binary content.
> All good, except that in 0.25 and up (which we're slowly migrating > to), this often doesn't work. The rest APIs require UTF-8 content, and > keys are binary, so catalog requests fail if the key happens to > contain bytes which aren't valid UTF-8. (http:// > projects.puppetlabs.com/issues/4832 talks about this a bit, and > includes the observation that "So there’s a design decision after all: > If PSON is to be JSON compatible – no binary data.". > > How are other people getting around this? Do you just allow all > clients to access all keys? Is there a native type, or an auth.conf > trick, that I'm missing? Or a more binary-friendly encoding than JSON/ > PSON ? I also suffer from this problem distributing binary GPG private keys. I would propose Puppet automatically base-64 encode/decode when a parameter's value (in this case a file's content but it could be anything) does not contain valid UTF-8 bytes. Would that fix the problem completely? Would it break anything? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Managing private key files; content=>file vs. binary content.
Hi Chris, 2010/11/10 Chris > [...] > file{"/path/to/foo.key": source=>"puppet:///keys/foo.key"} , because > any valid puppet client could access foo.key. > [...] > you are not sticked to the puppet file server, you can also use something like this: file { "/path/to/file": source => "/nfs/$host/file"; } Make an export for each connected server and restrict access to this one. Put all private files on the NFS server and you're done. Kind regards, Thomas -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Managing private key files; content=>file vs. binary content.
Hi all, Hi all, We use puppet for, amongst other things, managing the private-key files needed for things like SSL certificates for HTTPS web servers. We have a few constraints on how these are handled, and changes in recent versions of puppet are making this harder than it perhaps ought to be to implement, so I'm curious to know how others are handling it. A site's private key file should obviously be kept private, and only those nodes which are running the site should have access to it. This would seem to rule out using something like file{"/path/to/foo.key": source=>"puppet:///keys/foo.key"} , because any valid puppet client could access foo.key. It's possible to secure the file server, but not (as far as I can see) in a way which is aware of the node's manifest. So either we'd have to keep updating auth.conf with a list of nodes that were allowed to access each key file (error-prone, we have hundreds of both, and the node<=>required keys relationship is many-to-many ), or accept that other nodes could access keys that they shouldn't be able to. So, we currently do this: file{"/path/to/foo.key": content=>file("/keys/foo.key")} Since (AIUI) nodes can only access the catalog for the FQDN which matches their certificate, the puppetmaster will ensure that the key is available only to the hosts that need it. All good, except that in 0.25 and up (which we're slowly migrating to), this often doesn't work. The rest APIs require UTF-8 content, and keys are binary, so catalog requests fail if the key happens to contain bytes which aren't valid UTF-8. (http:// projects.puppetlabs.com/issues/4832 talks about this a bit, and includes the observation that "So there’s a design decision after all: If PSON is to be JSON compatible – no binary data.". How are other people getting around this? Do you just allow all clients to access all keys? Is there a native type, or an auth.conf trick, that I'm missing? Or a more binary-friendly encoding than JSON/ PSON ? thanks! Chris -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.