Hi, we use kerberos with keytabs on our clients. We do *not* trust root on the clients! One client should never have access to any other client''s keytab. This is my proposed solution to get the keytabs to the clients, any comments welcome! 1. Use file to get /root/.ssh/authorized_keys 2. Use exported resource to let the client "notify" the server that it wants a keytab 3. On the serverside 3.1 Generate keytab (if not exist) 3.2 Push keytab using ssh with key Problems: 1. As far as I understand we can''t use file to get the keytab as local root on clients then could get other client''s keytabs. (solved in solution) 2. Reinstallation. How do I tell the server to push the key once more to the same client? (not solved in solution) A suggestion here is to use a custom fact => has og has not keytab. Any other suggetions? Regards Bjørge -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 15/09/11 10:34, Bjorge Solli wrote:> Hi, > > we use kerberos with keytabs on our clients. We do *not* trust root on > the clients! One client should never have access to any other client''s > keytab. This is my proposed solution to get the keytabs to the clients, > any comments welcome! > > 1. Use file to get /root/.ssh/authorized_keys > 2. Use exported resource to let the client "notify" the server that it > wants a keytab > 3. On the serverside > 3.1 Generate keytab (if not exist) > 3.2 Push keytab using ssh with key > > Problems: > 1. As far as I understand we can''t use file to get the keytab as local > root on clients then could get other client''s keytabs. (solved in solution) > 2. Reinstallation. How do I tell the server to push the key once more to > the same client? (not solved in solution) > > A suggestion here is to use a custom fact => has og has not keytab. > > Any other suggetions?A co-worker suggested using the certs with apache to deny access to all other than the requesting puppet client, and thus eliminate step 3.2 and problem 2 and negate problem 1:-) This will probably be our solution if noone has an even better idea. Regards Bjørge -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Sep 15, 2011 at 10:12 AM, Bjorge Solli <bjorge@solli.priv.no> wrote:> On 15/09/11 10:34, Bjorge Solli wrote: > > Hi, > > > > we use kerberos with keytabs on our clients. We do *not* trust root on > > the clients! One client should never have access to any other client''s > > keytab. This is my proposed solution to get the keytabs to the clients, > > any comments welcome! > > > > 1. Use file to get /root/.ssh/authorized_keys > > 2. Use exported resource to let the client "notify" the server that it > > wants a keytab > > 3. On the serverside > > 3.1 Generate keytab (if not exist) > > 3.2 Push keytab using ssh with key > > > > Problems: > > 1. As far as I understand we can''t use file to get the keytab as local > > root on clients then could get other client''s keytabs. (solved in > solution) > > 2. Reinstallation. How do I tell the server to push the key once more to > > the same client? (not solved in solution) > > > > A suggestion here is to use a custom fact => has og has not keytab. > > > > Any other suggetions? > > A co-worker suggested using the certs with apache to deny access to all > other than the requesting puppet client, and thus eliminate step 3.2 and > problem 2 and negate problem 1:-) > > This will probably be our solution if noone has an even better idea. >You could create custom fileserver mount points with explicit access privileges so only the specific clients can access those files. You could create a function that returned the correct keytab for a given host, so the content was only available in the catalogs, not as files. file { "/path/to/my_keytab": content => retrieve_keytab_for($certname), } or something along those lines. keytab distribution sucks :( -- Nigel Kersten Product Manager, Puppet Labs *Join us for **PuppetConf * <http://www.bit.ly/puppetconfsig> Sept 22/23 Portland, Oregon, USA. * * -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 15/09/11 23:06, Nigel Kersten wrote:> file { "/path/to/my_keytab": > content => retrieve_keytab_for($certname), > }Isn''t $certname set by the client? Then a client could "impersonate" another?> keytab distribution sucks :(Yes! -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.