If you lock down everything, you either need to hand out keys, or plan on doing everything yourself, and getting overwhelmed.

Probably the single most power ful tool in Linux land to keep people from having to be “root” is the group concept. For example, if I want people to run Docker containers, they need to be able to talk to the Docker socket. The root user can do this by virtue of its global access. However, the more limited access approach is to add a user to the docker group.

Here is a short session I had on a newly provisioned machine:

docker ps
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json: dial unix /var/run/docker.sock: connect: permission denied
ansible@eng13sys-r111scc-lab:~/openstack-kolla-ampere-aio-scripts$ sudo docker ps
[sudo] password for ansible: 
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
scripts$ groups
ansible adm cdrom sudo dip plugdev lxd
ansible@eng13sys-r111scc-lab:~
scripts$ sudo usermod -a -G docker ansible
ansible@eng13sys-r111scc-lab:~
exit

Edit: Note that I added the -g flag. Otherwise, you remove the user from the sudo group, which breaks sudo.

Now when I log back in to the system:

ansible@eng13sys-r111scc-lab:~$ groups
ansible docker
ansible@eng13sys-r111scc-lab:~$ docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

This points out a couple of the shortcomings of the Linux approach. First, the group is specific to this particular workload, running docker containers, as opposed to the role that the user has in the organization. For example, we can think of (at least) two different types of users that need to run docker containers: database admins and web server admins. However, a web server admin does not get to play around with the storage subsystems the way that a DB admin can. Thus, in order to distinguish the power between these two users, we have to assign a specific user to either just the docker group, or the docker group plus whatever else he is going to do. We cannot just create a webserver group, and a docker group, and assign users at that level.

The second is that, in order to assign a user to a group, you need to be root. You cannot re-delegate some access you have already.

FreeIPA can actually provide this degree of group nesting and redelegation, but that does not help if you are administering a stand alone system.

You might notice that the name of my user in the example above is ansible. This is, again, collecting up a bunch of different users into a single account, much like doing everything as root is. The ansible user would then have to be a member of every group that has access to everything that every user needs to do.