Sudo provides a granular access control mechanism on many *nix variants (if you run a Mac, sudo is the thing prompting for the password when you try to do something). The ability to centrally manage sudo rules and grant access via policy has recently been added to Okta Privileged Access. This article explores the new feature.
Introduction
To quote Wikipedia “sudo is a program for Unix-like computer operating systems that enables users to run programs with the security privileges of another user, by default the superuser.“. In most scenarios, it is used to elevate user privileges so that an ordinary user can run commands as the superuser.
This fits within the mantras of “least privilege” and “zero standing privileges”, where users do not need elevated privileges, but can be granted them through being assigned to groups mapped to sudo rules files containing allowed commands and restrictions. Most Linux systems (and MacOS machines) will have a default sudo rule that allows any user to run any command as long as they know their password.
Okta Privileged Access supports use cases where users connect to a server as themselves (account provisioned just in time) and being elevated to the appropriate level of access. You could have a spectrum of access methods:
- Individual access with no additional privileges,
- Individual access with some elevated privileges based on membership in sudo rules, and
- Individual access with full administrative access (i.e. they can run any command as root via sudo).
This was explored earlier in Leveraging Zero Standing Privileges and Shared Account Acces with Okta Privilefged Access.
Often the challenge with sudo is managing consistent rules across a large environment. Without good configuration management, there is a risk that someone could get more access than they need. There are tools that simplify this by centrally managing sudo rules tied to a directory and groups in that directory (like RedHat IdM). Okta Privileged Access also centrally manages sudo rules and ties them to users via security policies. But it also dynamically creates and destroys the rules on the servers so users cannot inadvertently get access they aren’t entitled to.
This help article explores how Okta Privileged Access manages and uses sudo rules.
If you are familiar with Okta Advanced Server Access and how it implemented sudo rules, this is similar and achieves the same outcome but in the context of the new Okta Privileged Access data model. This is one of the features to bring parity between the two products.
Configuration
This feature is generally available across all Okta Privileged Access tenants. To use sudo rules, you need to setup the Sudo Command Bundles and assign them to Policies.
Resource Management
There is a new menu item under RESOURCE ADMINISTRATION (available to anyone with the Resource Administration role) called Sudo Commands.
The term “Sudo Command Bundle” is used to refer to logical groupings of sudo commands. You may define bundles that relate to job role, such as DBA or Website administrator, and put in all the commands for that role. When you assign bundles to policies, you can have multiple bundles assigned to one user, so it may make sense to make the bundles fairly granular (like a job function).
Sudo Command Bundles are created, managed and deleted from this page. Note that once a command bundle is assigned to a policy, it cannot be modified or deleted (this is a security control). Each command bundle will have a name and description.
The name will be used to build the sudoers.d file on the relevant Linux servers.
Then there will be a set of commands that are restricted.
Commands can be Executables with any, none or specific arguments specified. They can also be Raw (specify the exact command to be executed (users can’t modify)) or Directory (execute any command in the specified directory).
The last section is the Advanced configurations.
You can run the commands as any non-root user and also specify how the commands are run. The default is NOPASSWD to allow the commands to be run without needing a password. See the sudo documentation for the other options.
Policy Management
With Sudo Command Bundles defined, they need to be assigned to security policies via a rule. Obviously it needs to be a SSH session rule.
The bundles are assigned in a new option under Access Methods.
There are now three radio buttons for individual accounts – you can set user-level permissions, admin-level permissions OR the new user-level with sudo commands.
Selecting this option allows assignment of one or more Sudo Command Bundles. This means that if you have multiple granular command bundles (tied to different job functions) you can collect them together here to give all relevant access to any users mapped as principals to this policy.
You also need to define a Sudo Display Name. This will appear to the user when then connect to a server defined by this policy.
Depending on the risk associated with the commands you’re granting via this rule, you may also want to enable controls like session recording, MFA or access request. These are the same as for any other policy rule.
Use
Lets look at the user experience and then what’s going on with the sudoers.d files whilst the user is connected.
User Experience
With the new rule and policy saved (and enabled), users are given an access method that includes the sudo command bundle. For example, the following screenshot shows different access methods offered to the user based on the policies he is assigned to. It includes the individual and admin-level individual access, but also individual access with sudo restrictions.
Note that the description includes the Sudo Display Name set in the policy rule – (sudo level individual account with user-management-commands).
When the user connects to the server with the sudo option, a sudoers.d file is dynamically created for them (along with the user account and user personal group). When they attempt to run a command that is not in that sudoers.d file, they are prompted for their password (the default sudo rules for a Linux server). But there is no password for that account, so they cannot run the command. However any command that is in that file can be run without requiring a password.
Thus granular user access can be controlled through the Sudo Command Bundles and Policies.
A Look at the sudoers.d File Created
Before closing out this article it’s worthwhile looking at how this is implemented on the Linux server. It is leveraging standard sudo on Linux. There are some rules files in the /etc/sudoers.d folder. This includes the 90-*** file shipped with the OS. There may also be 95-scaleft file for full administrative access on the server (from Okta Privileged Access) – used for the admin-level individual account option.
The new file, created as the user connected, is for the 10-user-management-commands bundle created earlier, for the user larry_linuxadmin. You can see this in the filename (bundle name + “okta” + user name + unique id).
The new 10_*** file contains some comments and two commands.
The first defines a command alias (Cmnd_Alias) that lists all of the commands from the command bundle.
Cmnd_Alias SCALEFT_LARRY_LINUXADMIN_60B360DC_A081_41D3_9470_1AC65F0FD80D_CMDS = /usr/sbin/addgroup *, /usr/sbin/delgroup *, /usr/sbin/deluser *, /usr/sbin/useradd *, /usr/sbin/usermod *
The second line maps the users personal group (%larry_linuxadmin) to that command alias with the option of ALL=NOPASSWD, which means the commands can be run without requiring a password.
%larry_linuxadmin ALL= NOPASSWD: SCALEFT_LARRY_LINUXADMIN_60B360DC_A081_41D3_9470_1AC65F0FD80D_CMDS
This file will be removed when the user session ends. If there are multple users connected from Okta Privileged Access with sudo entitlements you may see multiple files in this folder.
Conclusion
In this article we have introduced the new sudo capability with Okta Privileged Access. Being able to centrally manage sudo rules and assign them to security policy significantly reduces risk due to misconfiguration of sudo rules files across many servers and it also increases usability by tying it into the Okta Privileged Access framework, so users can decide how much entitlement they need to do a particular task.