How To Manage sudo Permissions On Scale?

Managing sudo access can get tricky when your team grows and you have users who need to run specific commands without having full admin privileges. That’s exactly the situation I found myself in. Developers, sysadmins, and support engineers all needed different levels of access, and at first, I was just adding them directly into sudoers files with the specific commands they needed. But soon enough, it turned into a mess.

Let me walk you through how I cleaned things up and made managing sudo permissions way easier by using Unix groups and keeping the config modular.

1. The Situation

Here’s what I was dealing with:

  • Web developers needed to restart services like Apache or Nginx when deploying updates.
  • Sysadmins needed to run commands for system updates and service management.
  • Support engineers needed access to log files for troubleshooting.

Each role needed limited sudo access, but giving everyone blanket sudo rights wasn’t an option. I also didn’t want to be constantly editing sudoers files every time someone’s role or access needs changed.

2. The Problem

At first, I created separate files under /etc/sudoers.d/ for each role, like webdev_commands and sysadmin_commands. The idea was to list the allowed commands in each file. But this quickly turned into a hassle:

  • Too Much Repetition: I was listing users in multiple files, which was not only redundant but made things harder to maintain.
  • Rigid Setup: Every time someone needed new access, I had to dig into multiple files and update them, which was annoying and error-prone.
  • Messy Configuration: With users scattered across different files, it became hard to keep track of who had access to what.

3. The Fix

I realized I could avoid all that chaos by organizing everything around Unix groups. Here’s the approach that worked for me:

Step 1: Separate Command Groups into Their Own Files

Instead of cluttering files with user names, I focused on grouping commands by role and referencing Unix groups in those files.

For example:

File: /etc/sudoers.d/webdev_commands

Cmnd_Alias WEBDEV_CMDS = /usr/bin/systemctl restart apache2, /usr/bin/nginx -s reload
%webdevs ALL=(ALL) NOPASSWD: WEBDEV_CMDS

File: /etc/sudoers.d/sysadmin_commands

Cmnd_Alias SYSADMIN_CMDS = /usr/bin/apt-get update, /usr/bin/systemctl restart mysql
%sysadmins ALL=(ALL) NOPASSWD: SYSADMIN_CMDS

By using %webdevs and %sysadmins, I could manage access via Unix groups instead of hardcoding user names into these files.

Step 2: Manage Users with Unix Groups

Adding users to the right groups became super simple. If a developer needed access, I just added them to the webdevs group:

sudo usermod -aG webdevs username1

If they needed sysadmin-level access too, I just added them to both groups:

sudo usermod -aG webdevs,sysadmins username2

Now, whenever someone’s role changes, I don’t need to touch the sudoers files—I just update their group membership.

Step 3: Enjoy a Cleaner, Scalable Setup

With this setup, the sudoers files are focused purely on defining command sets, while user management happens through Unix groups. It’s way cleaner and easier to maintain. I don’t have to dig through multiple files when someone needs a change, and adding new roles or users is straightforward.

Why This Worked So Well

  • No More Repetitive Configs: Sudoers files are organized by commands, not cluttered with user names.
  • Simple User Management: Everything is handled through Unix groups, so adjusting access is quick and painless.
  • Scalable: As more users and roles were added, the config didn’t get out of control—it stayed organized and easy to manage.

Wrapping Up

Switching to this setup made managing sudo access so much easier. I went from juggling a bunch of messy sudoers files to a clean, modular approach that’s flexible and scalable. If you’re dealing with similar headaches, give this method a try—you’ll thank yourself later.

Table of Contents