Sudo command bundle
By default, *nix operating systems support two levels of user access: user level and superuser (root) level. The sudo command bundle enables admins to grant granular permissions to users without giving them full root access. With sudo, Okta Privileged Access security admins can create a layered permission system that specifies the exact commands a user can run as another user or with superuser permissions.
Resource admins can create, modify, and delete sudo command bundles. Security admins can use pre-created sudo command bundles to specify a specific type of access method for an individual account within a policy rule.
Types of sudo commands
There are three types of sudo commands:
- Raw: This type of sudo command allows users to execute only the exact command as defined by the admin when creating the sudo command. The admin can provide any input as the command to be used. Users can't modify the command in any way.
- Directory: This type of sudo command allows users to execute any command within the directory defined by the admin when creating the sudo command. This may be any legal UNIX directory that's defined by a string that begins and ends with a / character, including the root directory defined by /.
- Executable: This type of sudo command allows users to run the executable defined by the admin when creating the sudo command. The admin can choose whether this command accepts Any, None, or Specific arguments. This command must be a legal UNIX path defined by a string that begins with a / character.
Sudo command bundle rules
The sudo command bundles follow these rules:
- Only Okta Privileged Access resource admins can create sudo command bundles.
- Only Okta Privileged Access security admins can add the sudo command bundles to a policy, which grants users sudo permissions on target servers.
- Executable type sudo commands also support Any, None, or Specific arguments. Raw and directory sudo commands don't allow extra arguments to be specified.
- Sudo command bundles must specify the full directory path of the binary to be executed.
- Sudo command bundle names can contain any alphanumeric character except spaces.
- Sudo command bundle descriptions may contain any combination of alphanumeric characters.
How sudo command bundles work
When Okta Privileged Access users attempt to establish an SSH connection with a Linux server, they're presented with a list of available access methods. If the sudo command feature is configured and users are granted sudo access through the policy settings, they can sign in with sudo-level access if they meet the required conditions.
The following examples demonstrate how connection requests are evaluated based on different security policy configurations and the access methods presented to the user.
Examples
Consider a scenario where an SRE engineer is on call and requires sudo access to certain resources for three days. ON-CALL and SRE are the display names for a collection of sudo command bundles as defined in the security policy. SRE contains sudo command bundles 1, 2, and 3, and ON-CALL contains sudo command bundles 4, 5, and 6.
- Security policies with different sudo and conditions
-
- Security policy 1: Requires Access Requests and MFA conditions for sudo-level access to the collection of sudo command bundles under SRE.
- Security policy 2: Requires Access Requests and MFA conditions for sudo-level access to the collection of sudo command bundles under ON-CALL.
Based on the policies, the user is presented with the following access methods to gain sudo-level access:
The following access methods are available to access "S": 1: john.doe via SSH (sudo level individual account - SRE) Conditions: Condition Met? Approval - MFA - 2: john.doe via SSH (sudo level individual account - ON-CALL) Conditions: Condition Met? Approval - MFA -
- Security policies with same sudo and different conditions
-
- Security policy 1: Requires Access Requests condition for sudo-level access to the collection of sudo command bundles under SRE .
- Security policy 2: Requires MFA condition for sudo-level access to the collection of sudo command bundles under SRE .
Based on the policies, the user is presented with the following access methods to gain sudo-level access:
The following access methods are available to access "S": 1: john.doe via SSH (sudo level individual account - SRE) Conditions: Condition Met? Approval - 2: john.doe via SSH (sudo level individual account - SRE) Conditions: Condition Met? MFA -
- Security policies with same sudo and no condition
-
- Security policy 1: Requires Access Requests condition for sudo-level access to the collection of sudo command bundles under SRE .
- Security policy 2: Doesn't have any conditions and grants sudo-level access to the collection of sudo command bundles under SRE .
Based on the policies, the user is presented with the following access method to gain sudo-level access:
The following access methods are available to access "S": 1: john.doe via SSH (sudo level individual account - SRE)
Sorting order for sudo command bundles
When you list a sudo command bundle in the /etc/sudoers.d/ directory, the output is sorted in a lexicographic order based on the sudo command bundle name. The filename follows this structure: <sudo_commands_bundle_name>-okta-<user_name>-<random_hash_value>.
The sorting order is established by analyzing the values in lexicographical order, which is similar to how parsing is done for files within the /etc/sudoers.d/ directory on Linux systems. Prioritization is based on the following sequence: 0–9, A-Z, and then a-z.
For example, consider the following list of files that are defined in the sudoers.d directory in a *nix system.
01_abc_nginx-okta-user_name-d6e13ad78522b789a7f510eae4dbdc73 ABB_nginx-okta-user_name-de67ee27c291c25adb659937b1407368 01_ABc_nginx-okta-user_name-de67ee27c291c25adb659937b1407368 xyz_nginx-okta-user_name-de67ee27c291c25adb659937b1407368 01_FULL_NGINX-okta-user_name-d8cb7fddad549121afcf00d25fb75a36 01_full_nginx-okta-user_name-348c6f1a9070b4e1c4a65234ce223dbe 012_nginx-okta-user_name-de67ee27c291c25adb659937b1407368The files will be listed in the following order.
user@12345:/etc/sudoers.d$ sudo visudo -c 012_nginx-okta-user_name-de67ee27c291c25adb659937b1407368: parsed OK 01_ABc_nginx-okta-user_name-de67ee27c291c25adb659937b1407368: parsed OK 01_FULL_NGINX-okta-user_name-d8cb7fddad549121afcf00d25fb75a36: parsed OK 01_abc_nginx-okta-user_name-d6e13ad78522b789a7f510eae4dbdc73: parsed OK 01_full_nginx-okta-user_name-348c6f1a9070b4e1c4a65234ce223dbe: parsed OK ABB_nginx-okta-user_name-de67ee27c291c25adb659937b1407368: parsed OK xyz_nginx-okta-user_name-de67ee27c291c25adb659937b1407368: parsed OK