[sudo-users] sudo central management

[Russell Van Tassell]

On Thu, Dec 15, 2005 at 11:12:57AM -0600, donald.ritchey at exeloncorp.com wrote:
> Our implementation of sudo uses one sudoers file that is distributed by
> rsync over ssh (using Public/Private key pairs).  
> 
> We have grouped our machines, users, and applications into classes and 
> use the Host_Alias and Cmnd_Alias lines to set up the groups of systems 
> and applications, then setup user IDs and UNIX groups to allocate the 
> low-level permissions.  It results in a fairly large and visually 
> complicated sudoers file, but it is the only method I can come up with 
> to manage the 50 or so UNIX servers that we control.  
> 
> Luckily, most of our applications run on limited sets of servers and 
> the applications run under their own application-specific user IDs, 
> so the mapping of permissions is fairly cut and dried.
> 
> The complicators are the administrative and maintenance users that have
> to have extra permissions on certain servers, but not others.  This results
> in more sudoers entries than I would like, but it is still manageable.

We do very similar things across a few hundred machines, distributing
the sudoers file over pretty much the same mechanisms (rsync over ssh,
cfengine, etc).

Our networks are wide enough that we can usually get a granular enough
host grouping based on things like subnet (even on segments less than
a /24) and name or likewise.  User groupings are then broken up on user
groups (ie. /etc/group) and/or user alias in the sudoers file (for many
of those cross-boundary priviledges).  Commands, in-turn, have their
own aliases as well as potentially nested aliases (eg. an alias like
FILE_OPS that includes aliases things like CP and RM that then contain
the acceptable command listings for each).

This tends to result in a rather large "definition" section that is
later written in a clear language as user priviledges... for example:

   DBAS   PROD_DB_HOSTS = (oracle) ORACLE_CMDS

As a means of trying to make things clear for other admins on the team
(as well as a "what was I thinking" sanity check), I've also included
a "troubleshooting" section in our hosts for the networks and the like.
For example:

   ALL   NET_PROD_DMZ = (nobody) /bin/echo "This is the Production DMZ"

...which helps admins in clearly identifying hosts/networks if need-be
without needing to go through all the CIDR masks, since they can just go
to the host and do a "sudo -l" and see this on their list of commands.
(Yes, I realize that's another block that then needs to be maintained,
but lists like these don't tend to change too much, over time)

Of course, it's also always good to have clear and copious comments on
the more obscure or complicated pieces (or, as someone said, it tends
more towards tedious than complicated).  And again, the goal here is to
try to make things more clear for all on the team (and multiple sudoers
files tends to make things more complicated, particularly as the files
tend to diverge between hosts).

Hope that helps...
Russell


-- 
Russell M. Van Tassell
russell at loosenut.com

"There are two ways of constructing a software design: One way is to
 make it so simple that there are obviously no deficiencies, and the
 other way is to make it so complicated that there are no obvious
 deficiencies. The first method is far more difficult."      - CAR Hoare