Create group-specific and user-specific compute contexts – Part 2 – scripted method

1 Like

Last time, in the first part of this two-part post I showed how to (mostly) manually create a new group-specific compute context, with permissions set up so that users only see group- or user-specific compute contexts they can use. We ran a one-time preparatory script that ensured all users could still see the original 'out-of-the-box' compute contexts.

This time, we will automate the steps and iterate through lists of groups and users to perform them, so you can scale up and create a larger number of group- and user-specific contexts. This would be tedious to do manually.

As we will seen, this makes it easy to create contexts which the SAS Administrator can then customize per group, or per user, to configure each with their own group-specific set of SAS options and autoexec statements. Yet users won't find their compute contexts menu in SAS Studio or SAS Model Studio cluttered with contexts they cannot (and are not supposed to be able to) use.

As before, we are going to use bash scripting and the sas-viya CLI. For this task you will again need the sas-viya CLI and its plugins, configured with a connection profile and certificates to connect to your SAS Viya cluster, and you must authenticate the sas-viya CLI as a member of the SAS Administrators custom group before proceeding.

Preparatory script already presented in part 1

In part 1, we already saw how to run an example bash script which uses the sas-viya CLI to:

Disable the rule granting Authenticated Users read access to all compute contexts (/compute/contexts/*), if it is not already disabled
List all existing compute contexts, and store the list in a file
Get the existing compute context IDs from that file, and iterate through them
For each existing compute context, create a new authorization rule to grant all Authenticated Users read access to it

I won't duplicate that script here. Before continuing, if you have not done so in your SAS Viya environment already, please review, adapt and run that script as a one-time task.

In the results section of this post, I will also assume that you have been through the manual steps in part 1 to create a group-specific compute context for HR, and will include that in the expected results where appropriate.

Bulk-create group-specific and user-specific compute contexts

In part 1, we also manually created one new compute context, for the HR group in our example environment. We named it "SAS Studio compute context for HR group".

Now we can scale this up a bit. It is much quicker to use a bash script and the sas-viya CLI signed in as a SAS Administrator if you need to make a set of group- (or user-) specific compute contexts.

The create_contexts.sh script shown below is an example, but you will need to adapt it to your own needs, in at least these ways:

You can choose which compute context you will use as your template – here I have chosen the SAS Studio compute context, but you can use a different one.
Here I deliberately did not choose a context with a limitation already set on which identities – which users and groups – can create a compute session under that context. A reader comfortable with the process could quite easily modify the code to be based on a template which does add this restriction.
Keep or delete whichever parts of the group-specific or user-specific context creation you need. The sample script below has both, but feel free to delete one or the other. (Suggestion: follow better practices and only use the group-specific part!)
Obviously, you will need to substitute the values in group_list and/or user_list with lists of IDs (rather than the names) of groups and users in your environment, for whom you wish to create specific compute contexts:

group_list='Finance Sales'

user_list='Henrik Fiona Sean'

Uncomment the ls and rm statements in the last two lines if you want to have a record of, and then clean up the temporary files this script creates in the /tmp directory. I like to be able to inspect the temporary files, so I commented those lines out.

Do this in a non-production environment first. There is no 'undo' script, so reversing these changes could take some effort.

Copy the following code, and save it as a new script file called ~/create_contexts.sh. The comments in the code below explain what each bit does:

#!/bin/bash

# Download the JSON definition for the original SAS Studio Compute Context
# and use jq to remove everything except the fields specified below.
# The fields we select in jq should be the only fields we need.
rm -f /tmp/sas-studio-context-template.json
sas-viya --output fulljson compute contexts show -n "SAS Studio compute context" | \
  jq 'with_entries(select(.key | in({"attributes":1,
                                     "description":1,
                                     "environment":1,
                                     "launchContext":1,
                                     "launchType":1,
                                     "name":1,
                                     "version":1})))' > /tmp/sas-studio-context-template.json

cat /tmp/sas-studio-context-template.json

# Set up the lists of users and groups we will create contexts for
group_list='Finance Sales'
user_list='Henrik Fiona Sean'

for group in ${group_list}
do
  rm -f "/tmp/sas-studio-context-${group}.json"
  cp "/tmp/sas-studio-context-template.json" "/tmp/sas-studio-context-group-${group}.json"
  sed -i -e 's/"name":.*,$/"name": "SAS Studio Compute Context for '${group}' group",/g' "/tmp/sas-studio-context-group-${group}.json"
  sed -i -e 's/"description":.*,$/"name": "Compute context to be used for the SAS Studio service by '${group}' group",/g' "/tmp/sas-studio-context-group-${group}.json"

  # Use the template to create a new context for this group
  sas-viya compute contexts create -r -d @/tmp/sas-studio-context-group-${group}.json > /tmp/new-context-created.json
  id=$(cat /tmp/new-context-created.json | jq -r '.id')
  
  # Grant the group permission to see their new context
  sas-viya authorization grant --group ${group} --permissions read --reason "${group} can read their own compute context" --object-uri "/compute/contexts/${id}"
  # Grant the group permission to create sessions under their new context
  sas-viya authorization grant --group ${group} --permissions create --reason "${group} can create sessions under their own compute context" --object-uri "/compute/contexts/${id}/sessions"
done

for user in ${user_list}
do
  rm -f "/tmp/sas-studio-context-${user}.json"
  cp "/tmp/sas-studio-context-template.json" "/tmp/sas-studio-context-${user}.json"
  sed -i -e 's/"name":.*,$/"name": "SAS Studio Compute Context for '${user}'",/g' "/tmp/sas-studio-context-${user}.json"
  sed -i -e 's/"description":.*,$/"name": "Compute context to be used for the SAS Studio service by user '${user}'",/g' "/tmp/sas-studio-context-${user}.json"

  # Use the template to create a new context for this user
  sas-viya compute contexts create -r -d @/tmp/sas-studio-context-${user}.json > /tmp/new-context-created.json
  id=$(cat /tmp/new-context-created.json | jq -r '.id')
  
  # Grant the user permission to see their new context
  sas-viya authorization grant --user ${user} --permissions read --reason "${user} can read their own compute context" --object-uri "/compute/contexts/${id}"
  # Grant the user permission to create sessions under their new context
  sas-viya authorization grant --user ${user} --permissions create --reason "${user} can create sessions under their own compute context" --object-uri "/compute/contexts/${id}/sessions"
done

# ls -al /tmp/*context*.json
# rm -f /tmp/*context*.json

For demonstration purposes, the example user IDs in user_list in the create_contexts.sh script above includes Henrik (who is in the HR group in my environment, and who we used for our manual example in part 1), plus two users we have not mentioned before: Fiona (who is in Finance), and Sean (who is in Sales). Also the user_list intentionally does NOT include a user named Sarah who exists in my environment, and is also in Sales. We will sign into SAS Studio as each of these users later, to show the effect of running the script as below in my environment.

Once you have created it, make the script executable, e.g.:

chmod u+x ~/create_contexts.sh

Check it carefully for errors, and then (in your non-production environment first!), after authenticating against the sas-viya CLI as a member of the SAS Administrators group, run your version of the create_contexts.sh script.

~/create_contexts.sh

It outputs quite a bit of JSON to the console (stdout). First is the content of the /tmp/sas-studio-context-template.json file, which should look something like this:

{
  "description": "Compute context to be used by the SAS Studio service",
  "environment": {},
  "launchContext": {
    "contextId": "d929db8a-dcb0-4220-9c15-86135a432db5",
    "contextName": "SAS Studio launcher context"
  },
  "launchType": "service",
  "name": "SAS Studio compute context",
  "version": 4
}

This is followed by two blocks something like the following for each group-specific compute context. Here is the pair of JSON output documents in my results, for the creation of the two authorization rules allowing Finance to read (i.e. see) and create sessions under (i.e. use) their new group-specific compute context:

{
    "acceptItemType": "",
    "acceptType": "",
    "contentType": "",
    "createdBy": "geladm",
    "creationTimestamp": "2023-12-19T18:07:13.178Z",
    "description": "",
    "enabled": true,
    "id": "b3ba3d8b-541a-47dd-aa69-2b5cd2b5b257",
    "mediaType": "",
    "modifiedBy": "geladm",
    "modifiedTimestamp": "2023-12-19T18:07:13.178Z",
    "objectUri": "/compute/contexts/437ac37a-c7d4-41ac-9683-ae98f8c2c300",
    "permissions": [
        "read"
    ],
    "principal": "Finance",
    "principalType": "group",
    "reason": "Finance can read their own compute context",
    "type": "grant",
    "version": 10
}
The authorization rule has been created.
{
    "acceptItemType": "",
    "acceptType": "",
    "contentType": "",
    "createdBy": "geladm",
    "creationTimestamp": "2023-12-19T18:07:13.433Z",
    "description": "",
    "enabled": true,
    "id": "2488cb29-e094-4eec-9632-bf803cf9a2f1",
    "mediaType": "",
    "modifiedBy": "geladm",
    "modifiedTimestamp": "2023-12-19T18:07:13.433Z",
    "objectUri": "/compute/contexts/437ac37a-c7d4-41ac-9683-ae98f8c2c300/sessions",
    "permissions": [
        "create"
    ],
    "principal": "Finance",
    "principalType": "group",
    "reason": "Finance can create sessions under their own compute context",
    "type": "grant",
    "version": 10
}
The authorization rule has been created.

There should be a similar pair of blocks in the script's output for each other group, and each user.

Results

In my example environment, after manually creating a group-specific compute context for HR in part 1 and then running the script above, let's see what compute contexts are available to our selected users.

Henrik

Henrik should see all of the default compute contexts, plus ones for HR and Henrik:

Compute contexts visible to Henrik - the original default set of contexts, his own, and the one for HR

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

Fiona

Fiona should see all of the default compute contexts, plus ones for Finance and Fiona:

Compute contexts visible to Fiona - the original default set of contexts, her own, and the one for Finance

Sean

Sean should see all of the default compute contexts, plus ones for Sales and Sean:

Compute contexts visible to Sean - the original default set of contexts, his own, and the one for Sales

Sarah

Sarah should see all of the default compute contexts, plus one for Sales (we did not create a personal compute context for Sarah):

Compute contexts visible to Sarah - the original default set of contexts, and the one for Sales. We did not create a personal compute context for Sarah.

geladm

geladm (a SAS Administrator) should see all of the default compute contexts, plus ones for HR, Sales, Finance, Henrik, Fiona and Sean:

Compute contexts visible to geladm (a SAS Administrator). He can see the original default set of contexts, plus all the other group-specific and user-specific compute contexts. His list of compute contexts is longer than everyone else's, and has a scrollbar as a result.

This shows the script created the contexts we asked it to, they are visible to the users who need to use them, and crucially NOT visible to non-SAS Administrator users who don't need to (and should not be allowed to) use them.

Next steps

Having created all these contexts, the SAS Administrator is now able to customize each of them with, for example:

group-specific SAS Workload Orchestrator queues
group-specific SAS options (perhaps options which you only wish to set for some groups, and not for all)
librefs and macros in the autoexec statement

Yet the list of compute contexts visible in each user's context menu in SAS Studio is not cluttered up with contexts they cannot and should not be able to use.

See you next time!

Find more articles from SAS Global Enablement and Learning here.