Create group-specific and user-specific compute contexts – Part 1 – manual method

[#1]

Our team is sometimes asked how to create group-specific or user-specific compute contexts in SAS Viya, with permissions set so that users who are not in the group, or are not the user for whom the context was created, don’t see it. There are two aims for the permissions for these contexts:

• to avoid a user’s compute context menu in SAS Studio being so cluttered up with other users’ compute contexts that they have to look through a long list of contexts to find their own, and
• to avoid offering users the frustrating experience of being able to select a compute context in SAS Studio or SAS Model Studio which then fails to start.

In this post we will see a how to (mostly) manually create a new group-specific compute context, with permissions set up to meet these two aims. We will:

• Adjust the authorization rules which make all compute contexts visible to all users by default, in e.g. the SAS Studio contexts menu. To do this we will:
  • Disable* the rule that makes all compute contexts visible to all users
  • Run bash commands to make new rules for each out-of-the box compute context so that users can still see them and start sessions under them
• Create a new compute context for an existing group
• Create more new rules granting the group permissions to see (and use) their new compute context, while not giving other users or other groups access to it

To perform some of these steps, you will need to install the sas-viya CLI and its plugins, configure it with a connection profile and certificates to connect to your SAS Viya cluster, and authenticate the sas-viya CLI as a member of the SAS Administrators custom group. You will also see optional steps which use some of our pyviyatools, to simplify otherwise cumbersome tasks. Next time, in part 2 of this post, we will present another bash script that automates all of the steps above and iterate through lists of groups and users, so you can scale it up and script the creation of a larger number of group- and user-specific contexts.

  * SAS Administrators aren’t impacted by disabling the rule that makes all compute contexts visible to all users. There is an out-of-the-box rule which grants SAS Administrators access to all URIs in the system, which means they still see all compute contexts and still be able to create new sessions under each compute context. SAS Administrators will have to scroll through all compute contexts in the dropdown contexts menu in SAS Studio and there is no sensible way to avoid this – except perhaps by not using SAS Studio as a SAS Administrator, or by not opting in to the SAS Administrators assumable group when you sign in to use SAS Studio.

What about batch contexts? It is not possible in the current version of SAS Viya to configure permissions that work they way I'd like them to for group- or user-specific batch contexts, when used from the sas-viya CLI. I will save the topic of a batch context version of this post for another time. It may be that for now, we simply create group- or user-specific batch contexts, but do not attempt to secure them - all users see all batch contexts. It is possible that in future we may get the ability to set permissions for batch contexts that work nicely with the sas-viya CLI and allow us to better manage their visibility.

User-specific or group-specific?

Making group-specific compute contexts is a better idea than making user-specific ones. It is less work to set up, less effort to maintain, and still does the job in most use cases. If users really do need their own user-specific ‘context’, but not their own job queue, it may be sufficient for them to define their own user-specific autoexec code block which runs when their compute session starts, or their own user-specific preamble and post-amble code which runs before each code submission, in SAS Studio – see SAS Studio > User's Guide > Introduction to SAS Studio > Editing the Autoexec file. In this part 1, I will create a group-specific compute context. In part 2, we will include user-specific compute contexts - they are created in much the same way as group-specific ones - no special steps are required.

Starting simple

‘Out of the box’, SAS Viya has a rule granting Authenticated Users read access to all compute contexts. It’s neat, but it isn’t the best fit for a SAS Viya deployment with dozens of compute contexts, or more. So, we will begin by disabling that rule and adding new rules to make sure all Authenticated Users still have access to the out-of-the-box compute contexts.

We should only do this once, per deployment, and it is easier to do it before we create any user-specific compute contexts, because during the step where we create a new rule granting all Authenticated Users access to read each ‘out of the box’ compute context, we have to distinguish which contexts are ‘out of the box’ from those we created later. Before we create any new ones, that’s easy – all compute contexts that currently exist are 'out-of-the-box'. Later on, obviously you can still make rules for each of them, but it will require manual intervention to choose which contexts you want everyone to be able to see.

In this post, I am going to assume there are no extra compute contexts to begin with, and make a rule for all those that exist, granting all Authenticated Users access to read and create sessions under them, before we create any new compute contexts.

What does the contexts menu in SAS Studio look like for each user, out of the box?

Initially, all users see exactly the same set of compute contexts in SAS Studio.

Note that the set of pre-defined contexts seen here depends on which SAS products and solutions are deployed, and on the version of SAS Viya, so do not be surprised if your starting set of contexts differs from the screenshot below.

The screenshot below is what I see in one of our GEL workshop environments:

 Compute contexts for all users in my environment, 'out-of-the-box'. Here we see them as a SAS Administrator, geladm, but all users see the same set of compute contexts.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

Disable and replace rule granting all users read access to all compute contexts

We want to create new contexts without them becoming automatically visible to all users. So, in the Rules page of SAS Environment manager, while logged in as a SAS Administrator, remove (or better, disable) the general authorization rule granting Authenticated Users the Read permission on the URI /compute/contexts/*:

 Disable this authorization rule to remove all users' access to see all compute contexts automatically.

It’s easy to search for the rule: type /compute/contexts/* into the search box above the rules table. The rule that matches this pattern and is for the principal Authenticated Users, granting Read permission is the one we want to disable. Right-click the rule, choose Edit, and in the Edit Rule dialog, change the ‘Rule status’ toggle button to ‘off’ (disabled):

 Turn the 'Rule status' toggle button off to disable the rule.

Then click Save.

After disabling that rule, members of the SAS Administrators group, like geladm in my environment, are still able to use SAS Studio and get a compute context. They see no difference in behaviour, thanks to the rule that says they get all permissions (to perform all actions) on all URIs – in SAS Viya.

But disabling this rule creates a temporary problem for all non-administrator users. They get an error message when they open SAS Studio, saying “studio-commons-api-icu.client.compute.error.no.contexts.found.msg”:

We need to grant Authenticated Users permission to see, and use, all the out-of-the-box compute contexts again. The rules implementing those permissions will target the individual compute contexts by their IDs. Getting the compute contexts’ IDs is most easily done using the sas-viya compute contexts list command, so next we will do just that.

As a one-time task, from the command line we will list all existing compute contexts, store the results in a file, get the compute context IDs from that file, and iterate through them to create a new authorization rule for each one so to grant all Authenticated Users read access to each existing out-of-the-box context.

As mentioned above, before you can run this, you would need to install sas-viya CLI and its plugins, configure it with a connection profile to your SAS Viya cluster, and authenticate as a member of the SAS Administrators custom group. If you have done that, you can run these commands (adapted as necessary for your deployment)

As a bonus, the following also includes a scripted method of disabling the rule we just disabled above, using the getruleid.py pyviyatool, in case you prefer to do this in a script for your environment. It's no problem to attempt to disable a rule that is already disabled, so you can run it even if you did so already:

#######################################################################################
# Important: Do all this once, before creating user- and/or group-specific contexts.
#
# This fundamentally changes out-of-the-box behaviour that by default, all users see
# all compute contexts. After doing this, if you create a new compute context, you
# will have to create a new authorization rule granting non-SAS Administrator users
# permission to see it, otherwise they won't see it.
#######################################################################################

# If you did not do it already...
# Disable the rule granting Authenticated Users read access to all compute contexts (/compute/contexts/*)
id=$(/opt/pyviyatools/getruleid.py -u /compute/contexts/* -p "authenticatedUsers" | jq -r '.items[0]["id"]')
echo ${id}
sas-viya authorization disable-rule --id ${id}
# If you did this already, it does no harm to run this, and you will see a response saying something like " Rule 07633805-2c76-495a-9f38-a6c6c63eb628 is already disabled.". That is fine.

COMPUTE_CONTEXTS_FILE=/tmp/compute_contexts.txt
COMPUTE_CONTEXT_ID_FILE=/tmp/compute_context_ids.txt

# List the compute context IDs, and store the results (which have a header row) in a text file
sas-viya compute contexts list > ${COMPUTE_CONTEXTS_FILE}

# Remove the header row
tail -n +2 ${COMPUTE_CONTEXTS_FILE} > "${COMPUTE_CONTEXTS_FILE}.tmp" && mv "${COMPUTE_CONTEXTS_FILE}.tmp" ${COMPUTE_CONTEXTS_FILE}
cat ${COMPUTE_CONTEXTS_FILE}

# Make another file with just the compute context IDs (always the last field, which you can reference as $NF), in each line
awk '{print $NF}' ${COMPUTE_CONTEXTS_FILE} > ${COMPUTE_CONTEXT_ID_FILE}
cat ${COMPUTE_CONTEXT_ID_FILE}

# Add a new authorization rule for each original compute context granting Authenticated Users read access to it
while read id; do
  context="/compute/contexts/${id}"
  sas-viya authorization grant --authenticated-users --permissions read --reason "Authenticated users can read this original compute context" --object-uri ${context}
done <${COMPUTE_CONTEXT_ID_FILE}

#######################################################################################
#### End of section you should only run once, before creating user- and/or group-specific contexts.
#######################################################################################

After you do this, all other authenticated users can again see (and start compute sessions running under) all the out-of-the-box compute contexts in SAS Studio.  

Create a new compute context for a group

Now we can interactively create a new compute context for a group. We will create one manually for the HR group in my environment, based on the default SAS Studio compute context.

In SAS Environment Manager, as a SAS Administrator (geladm in my case), navigate to Contexts and choose the ‘Compute contexts’ view. Then, find the SAS Studio compute context in the list, right-click it, and choose Copy from the popup menu:

In the New Compute Context dialog:

• Change the name to e.g. “SAS Studio compute context for HR group”
• Change the description to e.g. “Compute context to be used by HR group for the SAS Studio service”
• Leave the Launcher context set to “SAS Studio Launcher context”

Under Identity type, click the radio button to select Identities, and at the top right of the identities area below it, click the “Choose identities” button and in the popup, select e.g. “Groups” and then your chosen group e.g. “HR”, and click OK:

The new compute context dialog looks like this just before you click Save:

Click ‘Save’ to save the new compute context for e.g. HR. You should see a brief popup message saying “Created compute context”. You should also see the new compute context appear in the list on the Contexts page in SAS Environment Manager.

Making the new context specific to your chosen group, e.g. HR, creates a new authorization rule for this context, granting members of the HR group permission to create new sessions under the context. Here is the new rule in my environment – note the ‘/sessions’ endpoint after the compute context ID:

However, because of the changes we made a moment ago, although members of HR have permission to create new compute sessions under the new compute context, they still cannot see it in e.g. SAS Studio.

At this point, Henrik’s list of available compute contexts in SAS Studio is the same as it was the last time we looked. Permission to see (Read) the new context has not yet been granted to HR, so we need to do that.

Back in SAS Environment Manager as geladm (my SAS Administrator), find the rule as shown in the screenshot above, granting HR Create permission on /compute/contexts/some-guide/sessions, right-click it, and Copy it. In the Copy Rule dialog, make the following changes:

• Remove the /sessions suffix from the end of the Object URI. For example the Object URI of the rule I copied was /compute/contexts/26d013e4-0a1e-4f56-9eba-c480714ee53b/sessions, so I deleted the last bit to just leave it as /compute/contexts/26d013e4-0a1e-4f56-9eba-c480714ee53b. Take care to leave the compute context ID intact – don’t accidentally delete any of that, and don't leave the trailing '/'.
• Leave the Principal Type as ‘Group’ and the Principal as your chosen group (in my case, ‘HR’)
• Click the ‘Choose’ button to change the Permissions from ‘Create’ to ‘Read’. (Your group only needs Read permission on the new compute context URI, there is no need to leave the ‘Create’ permission selected.)
• Edit the description to say something like “Users in group HR can see context 26d013e4-0a1e-4f56-9eba-c480714ee53b.”
• Leave all the other settings as unchanged – several fields are empty, which is fine.

Click Save.

Now there should be two rules for HR targeting that compute context, like this:

Having done this, both geladm (a SAS Administrator) and user like Henrik (a member of the HR group) can see the new compute context and can start a compute session under it in SAS Studio. Here is Henrik’s view of the available compute contexts in SAS Studio at this point, showing that he has successfully started a compute session after switching to the new HR compute context:

However, when user Sarah (a member of Sales, and not a member of HR) signs in, she does not see the “SAS Studio compute context for HR group”, she only sees the set of compute contexts she had access to out-of-the-box:

Success!

We have created a new compute context visible and useable to only users in a specific group (plus SAS Administrators). Most importantly, the new context is not visible to (or useable by) users who are not members of that group. It does not clutter up other users’ compute context menu in SAS Studio. However, that was quite a lot of clicking in the web interface, and we have only created one group-specific compute context. That probably felt like a lot of work for a relatively small gain.

In part 2 of this post, we will see an example bash script to automate the creation of many new compute contexts, all secured similarly to be visible to and useable by only members of their intended group or individual users.