3

There are multiple answers that effectively say that ldap should be used instead of puppet for managing actual users. I'm inclined to agree based on a scaling perspective. Onboarding new staff members should be done by support teams, not by sysadmins adding new user resources.

However, managing ssh keys and authorized keys (along with sudo access and user config files) seems like a job perfect for puppet.

What is the standard way of managing keys and config per user? Can puppet augment ldap here? What happens if an employee turns rogue and we need to revoke their key from 1000 different authorized_keys files?

Community
  • 1
Josh Smeaton
  • 1,330
  • 2
  • 19
  • 31

3 Answers3

5

I disagree with Graig Watson.

Creating copies of accounts means you've then got problems keeping them in sync. Having a single source for authentication information eliminates a lot of complications and LDAP is much easier to integrate into other services (web, mail etc).

In terms of sudo access - if you configure your sudoers based on groups rather than individuals then access to the facilities can easily be controlled via LDAP. It requires more forward planning - but is much easier to manage in the longer term - you manage the security policy not data files.

Making ssh keys available on other machines is best handled by using some sort of network file system - it might be NF/Samba, but replicating or shared filesystems provide the same goal (with different side-effects).

The first step should always be defining your security model - allowing local configurations gives huge scope for undermining that model.

symcbean
  • 19,931
  • 1
  • 29
  • 49
1

I'd actually say that Puppet is a better solution than LDAP, as it doesn't have a SPoF (logins are local, but managed centrally).

In any case, for your "rogue user" scenario, you could use the ssh_authorized_key Puppet resource and ensure => absent on their key. Then use Mcollective/cron to populate this.

See doc: http://docs.puppetlabs.com/references/latest/type.html#sshauthorizedkey

The difficulty is having Puppet manage a file in the users' home directories (which may or may not exist). You could mitigate this by customising the authorized_keys file location in your SSH config (i.e. /var/lib/ssh/authorized_keys/%u).

Craig Watson
  • 9,370
  • 3
  • 30
  • 46
  • After a lot of reading and troubleshooting issues across puppet, LDAP, & NFS for a year now I am inclined to agree with this unpopular opinion. Puppet isn't ideal nor the "right" tool for this but for small organizations it ends up being the best of bad options. I prefer a big puppet manifest over an unmaintained LDAP server & undocumented config any day. – 7yl4r Aug 07 '18 at 14:24
1

I am very happy with: http://www.freeipa.org/page/Main_Page

It contains everything you need - users, sudoers, ssh keys, even selinux configuration.

Yarik Dot
  • 1,543
  • 12
  • 26