To restrict root-user access to CLM system commands, you can create privileged users that can execute only specific CLM system commands. If a user other than the privileged non-root user attempts to execute a restricted command, the command fails and an error message is displayed.

Restricted root-user access:

• meets an important CIS security benchmark

• assigns sudo privileges for only the required commands per user

• ensures that any configuration or control actions are traceable to a specific user

You can restrict root-user access on the CLM deployer host and cluster VMs.

Note: Client delegate servers do not support restricted root access.

CLM commands named in the documentation or used in a CLM script support execution as a non-root user under the conditions described in this topic.

Note: The root user creates the privileged users, but is not required afterward for CLM system deployment, administration, or support. A superuser account is created for support use.

Restricted CLM root access requires multiple privileged non-root user accounts for different types of system access. You can enlist technical support to create and enable a default set of privileged non-root user accounts, or use accounts that you create.

You can also opt to disable only remote root access to the CLM cluster VMs from the CLM deployer host, as described in Disabling remote root access.

Note: Each user must belong to the local ‘nsp’ user group.

The following directory on a CLM deployer host contains CLM specific example sudoers files that list the restricted commands and functions:

/opt/nsp/NSP-CN-DEP-release-ID/NSP-CN-release-ID/tools/sudoers

Privileged CLM cluster accounts

The account types required include the following, depending on the CLM entity:

• CLM admin user—on CLM deployer host and cluster VMs; performs deployment operations

• CLM ansible user—on CLM cluster VMs only; for software rollout operations; can be disabled when system is operational

• CLM super user—for general access with root-level privileges; in wheel group

Note: The CLM super user is required by customer support teams for troubleshooting the system, so must always be enabled.

The following are the restricted commands and scripts, by element; the list is not exhaustive, but summarizes the commands used in the CLM documentation.

• general—SELinux commands

• CLM deployer host and cluster VMs

  • Kubernetes deployment—kubectl, nerdctl, helm

  • CLM deployment—nspregistryctl, nspk8sctl, nspdeployerctl

For simplicity, CLM procedure steps that involve restricted root access are minimally formatted, as shown in the following examples.

Note: Depending on the sudoers configuration, the operator may be prompted for the password of the privileged user when executing a command.

CLM example

1. Log in as the root or CLM admin user on the station.

   The step text indicates that if root access is restricted, you must log in as the CLM admin user.

2. Enter the following:

   # cd /opt/nsp/nsp-k8s-deployer-release-ID/bin ↵

   Basic commands like ‘cd’ and ‘ls’ are entered as shown.

3. Enter the following:

   # ./nspk8sctl config -l ↵

   You must enter a CLM command such as ‘nspk8sctl’ using ‘sudo’, so the command you type is:

   # sudo ./nspk8sctl config -l ↵

4. As the root or CLM admin user, enter the following:

   # kubectl get pods -A ↵

   If root access is restricted, the CLM admin user must execute the command and use ‘sudo’., so the command you type is:

   # sudo kubectl get pods -A ↵

To comply with the CIS RHEL benchmark “Ensure SSH root login is disabled”, you can also disable root-user SSH, and by extension, SCP, access on the CLM deployer host and cluster VMs.

To disable remote root access, during CLM cluster deployment you specify a designated non-root user and security key in the cluster deployment configuration. The user requires sudo privileges on each CLM station.