Restricting root-user system access

Description

To restrict root-user access to NSP system commands, you can create privileged users that can execute only specific NSP 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 NSP deployer host and cluster VMs; NSP auxiliary database; and on NFM-P main server, auxiliary server, and main database stations.

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

NSP commands named in the NSP documentation or used in an NSP 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 NSP system deployment, administration, or support. A superuser account is created for support use.

Defining privileged NSP user accounts

Restricted NSP 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 NSP cluster VMs from the NSP deployer host, as described in Disabling remote root access.

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

The following directory on an NSP deployer host contains NSP component-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 NSP cluster accounts

The account types required include the following, depending on the NSP component:

NSP admin user—on NSP deployer host and cluster VMs; performs deployment operations
NSP ansible user—on NSP cluster VMs only; for software rollout operations; can be disabled when system is operational
NSP super user—for general access with root-level privileges; in wheel group

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

Privileged accounts for ancillary components

Restricting root access on NFM-P and NSP auxiliary database stations has the following requirements and restrictions:

A privileged non-root user must belong to the local ‘nsp’ user group.
On an NFM-P main database station, the user must also belong to the database administrator group, for which the deployment default is ‘dba’.
The OracleSw_PreInstall.sh can be placed only in the /extra directory or a subdirectory of /extra. You must enable nsp group access to the directory, and must include the directory in the sudoers file.

Restricted commands

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

Note: Some NFM-P main database management scripts invoke low-level system or security functions. A non-root user may need to use ‘sudo -u oracle’ to run such a script, for example:

sudo -u oracle script

general—SELinux commands
NSP deployer host and cluster VMs
- Kubernetes deployment—kubectl, nerdctl, helm
- NSP deployment—nspregistryctl, nspk8sctl, nspdeployerctl
NSP auxiliary database
- auxdbAdmin.sh
- customdata.bash, customData.bash
- commands and scripts in /opt/vertica/bin
NFM-P
- deployment and control—dnf, yum, systemctl
- 'sam' commands such as samconfig, samupgradeDb, sambackupDb, samrestoreDb
- configuration scripts in /opt/nsp and subdirectories
- OracleSw_PreInstall.sh

Users and commands in procedure steps

For simplicity, NSP 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.

NSP example

Log in as the root or NSP admin user on the station.

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

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

Basic commands like ‘cd’ and ‘ls’ are entered as shown.
Enter the following:

# ./nspk8sctl config -l ↵

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

# sudo ./nspk8sctl config -l ↵
As the root or NSP admin user, enter the following:

# kubectl get pods -A ↵

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

# sudo kubectl get pods -A ↵

NFM-P example

Log in as the root or NSP admin user on the main server station.

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

# cd /opt/nsp/nfmp/server/nms/bin ↵

Basic commands like ‘cd’ and ‘ls’ are entered as shown.
Enter the following:

# ./nmsserver.bash stop ↵

‘sudo’ must precede an NFM-P .bash command, so the command you type is:

# sudo ./nmsserver.bash stop ↵
Enter the following as the root user:

# systemctl status nfmp-main-server.service ↵

‘sudo must precede the ‘systemctl’ command, so the command you type is:

# sudo systemctl status nfmp-main-db.service ↵

Disabling remote root access

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 NSP deployer host and cluster VMs; NSP auxiliary database; and on NFM-P main server, auxiliary server, and main database stations.

Note: NFM-P client delegate servers do not support restricted root access.

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