Containerlab should be able to run as non-root user (without sudo) on supported platforms

[vista-]

At the moment, Containerlab checks whether its running as root (uid==0) when running certain privileged commands, such as clab deploy:

containerlab/cmd/root.go

Line 70 in aaee747

func sudoCheck(_ *cobra.Command, _ []string) error {

It would be nice to be able to remove this requirement to allow users to run Containerlab instances without giving them sudo access.

Motivation

There are some administrators who would like to give the ability to users to run Containerlab without necessarily granting them full sudo rights. They can, in theory, allow a given user group to perform sudo and run Containerlab, but it would be great if this could be done out of the box, without having to perform additional system administration tasks.

Initial observations

• The user should be able to spin up Docker containers.
• The user needs to create network interfaces, adjust their attributes and such, which might involve poking sysctls
• The user needs to be able to interact with nftables/iptables, including loading their respective kernel modules
• The user performs a write to sysfs, to enable LLDP on the Linux bridge created for management
• The user creates a directory (if it does not exist yet) and symlinks network namespaces from procfs into /run/netns/
• Container names and their assigned IPs are written to /etc/hosts
• Finally, the default system SSH config is expanded in /etc/ssh/ssh_config.d/ with the node SSH information

Possible solutions

Breaking this down with some potential solutions other than running Containerlab as root:

• The first requirement is satisfied by having the user running Containerlab in the appropriate docker user group (in most cases, docker)
• A CAP_NET_ADMIN capability set on the executable would give us the ability to manipulate network interfaces + nftables.
• CAP_SYS_MODULES capability lets us load the ip_tables and ip6_tables kernel modules, if they are not loaded yet.
• Using tmpfiles.d would give us the ability to ensure /run/netns directory always exists and is writable to all users
• Moving the SSH config from /etc/ssh/ssh_config.d/ to be under the user's home instead would help us separate containerlabs in a multi-user environment.

Caveats

This still leaves a few unsolved issues, where there's no easy fix from what I can tell:

• The sysctl write allowing LLDP on Linux bridges
• /etc/hosts
• The workaround for /run/netns requires an additional dependency to be installed, which also has to run as a system service

Alternative workaround

Another way to approach this is to still run Containerlab as root, but through the setuid bit being set. To avoid containerlab being a method for privilege escalation for users who don't have sudo, or even docker privileges (because having access to the docker user group is essentially granting root access, this is even documented in the Docker docs: https://docs.docker.com/engine/security/#docker-daemon-attack-surface), some additional steps should be taken.

Two different methods come to mind:

• Limit execution of the containerlab binary by user group membership:
  This would be the easiest way, but would gate off containerlab functionality that does not require root privileges, such as clab graph, from non-privileged users.
• Allow anyone to run containerlab, but limit privileged actions through some means, such as group membership checking:
  I can see this being built on top of the existing PreRunE functionality in Cobra, replacing the sudoCheck function. On top of this, by handling privileges inside the application, we can drop (and acquire) them when we need to perform privileged actions, and be able to perform certain actions, such as creating the Lab Directory, to be done as the executing user. Additionally, a check could be implemented whether this group exists at all, and if not, just let all users use the privileged operations of Containerlab.

Some other bits and pieces should be also given some thought, such as moving the SSH config from the system-wide SSH configuration directory to the user's own. Since users would need not need to sudo or run Containerlab as root, there would be much less utility to this.