puppet and kerberos keytabs

[Bjorge Solli]

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

[Bjorge Solli]

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

[Nigel Kersten]

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.

[Bjorge Solli]

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!