Securing OS Resources in SAS Viya
Users of SAS Software are used to accessing external resources. Many of them store their SAS code and data in files located in directories in the file system. They then access the data in SAS libraries and path-based CAS libraries and the code from SAS clients. In SAS Education this is also the case for our workshop environments. In developing the Viya 4 Administration workshop our initial goal was to take our Viya 3.5 Administration environment and get functional equivalence in Viya on Kubernetes. In this post, I will look at how we secured our OS resources in Viya and Kubernetes.
In our Viya 3.x workshops we use a fictional company Gelcorp that has multiple business units Sales, HR, Finance, etc. Each BU has a group in LDAP and the Viya and OS resources are secured to the groups so the Sales cannot see Marketing and vice-versa. In Viya 3.x:
- Identities come from LDAP and users are grouped into Business Units (Sales, Marketing, etc.)
- System Security Services Daemon (SSSD) is configured on the LINUX server
- data and files are stored on a Network File System (NFS)
I don't want to go into detail about how the security mode is implemented. To summarize the access pattern for a user is established based on their group and secondary group membership.
The permissions structure is shown in the table below. The impact of the settings is that a user can access resources for the groups they are members of, but cannot access resources for other groups. For example, Sally a member of the Sales group can access files in /gelcontent/gelcorp/sales/code but not in /gelcontent/gelcorp/hr/code.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
Storage in Viya 4
Viya 4 runs on Kubernetes, it is different. The way you make the physical locations available is different. External storage can be made available using Persistent Volumes. My colleague Steve Foerster also provides a really nice summary in this article.
In Viya 4 (like Viya 3.x) these OS resources must be secured so that they can be accessed by service accounts running SAS processes and by specific users and groups.
Identities
In Viya 4 identities can be either read from LDAP or loaded from a SCIM provider. In our case, we use the same LDAP provider as in our Viya 3 environment. The LDAP provider holds the users' POSIX attributes including primary and secondary group IDs. The data on our NFS share is secured using the identities of the provider.
In Viya 3.5 SSSD is the method we use to return identity information from LDAP to the OS. System Security Services Daemon is a system daemon. Its primary function is to provide access to local or remote identity and authentication. By default in Viya, SSSD is turned off for CAS and Compute, and all identity information is returned by the Identities service.
Let's look at one user on the system, Henrik to see how identity information is returned
Outside the pod on the NFS server, the id command shows the identity information of Henrik(4015) who has a Primary Group of sasuser(2003) and is a member of one secondary group HR(3001)
id Henrik
We can use a new pyviyatool getposixidentity.py to get the identifier information for Henrik that is stored in the Identities service. The names of the groups are not available from identities but the group IDs match what was returned by the id command.
/opt/pyviyatools/getposixidentity.py -u Henrik -o simplejson
What Identity Runs the Process?
In order to determine how to secure the content on the filesystem we need to understand what identity runs the process. By default, it is different for CAS versus Compute.
Compute sessions:
- sessions are launched by the SAS Launcher Service and run as the requesting user by default.
- All Operating system access is by default by the user account.
CAS sessions:
- by default, run as a process inside the CAS controller as the CAS service account (sas: uid=1001, gid=1001).
- All Operating system access is by default by the service account.
To see this in operation and understand the implications for securing our OS content we can use the user Henrik and launch a compute and a CAS session. In Studio we run a SAS Program that will list our user ID, home directory, and the name of the compute pod that was launched. The program also starts a CAS Session.
To see the user running the compute session use kubectl to exec into a container in the pod that was launched to perform the SAS processing. Inside the container run the id command. The result is that the process is running as Henrik (4015) and the primary and secondary groups have been returned by the identities service.
kubectl exec -it $(kubectl get pod -l launcher.sas.com/requested-by-client=sas.SASStudio,launcher.sas.com/username=Henrik --output=jsonpath={.items..metadata.name}) -- bash -c "id"
For CAS we don't get a separate POD per session, we get a different process inside the CAS container on the CAS controller. We exec into the CAS container in the CAS controller pod. and execute the ps command we can see a CAS session running under the shared account (1001).
kubectl exec -it $(kubectl get pod -l casoperator.sas.com/node-type=controller --output=jsonpath={.items..metadata.name}) -c cas -- bash -c "ps -ef | grep 1002"
As you can see CAS and Compute behave differently. CAS, by default, uses the shared account, and Compute uses the requesting user's account.
Standardize Configuration
For the compute server our setup is done. The OS permissions on the mounted directories will be honored because the compute sessions run as the requesting user and the Viya environment is using identity information from the same LDAP server as the NFS server. For CAS we have some choices to make.
Firstly, we could ensure that in LDAP the Shared account has the group membership of all the business units via its secondary groups. If that were the case then the shared account would be able to access the data for the requesting user. If the current shared account does not have this access pattern CAS can be configured to run as a different account.
Perhaps a more straightforward approach is to configure CAS so that the sessions run as the identity of the requesting user. To configure all CAS sessions to run as the requesting user's identity, set the CASALLHOSTACCOUNTS environment variable. Alternatively, adding specific users to the CASHostAccountRequired custom group will make CAS sessions for those users run as the identity of the requesting user. To test the difference let's use the last approach for the user Henrik.
Firstly, create the CASHostAccountRequired group and add Henrik as a member.
sas-viya --output text identities create-group --id CASHostAccountRequired --name "CASHostAccountRequired" --description "Run CAS as users account"
sas-viya --output text identities add-member --group-id CASHostAccountRequired --user-member-id Henrik
Now run the SAS Program again and use the same command to check the process owner of the CAS session. Now we will see there is a process for Henrik(4015) in the CAS container of the CAS controller. The CAS session is running under the identity of the requesting user and the access pattern will be governed by that user's identity information.
kubectl exec -it $(kubectl get pod -l casoperator.sas.com/node-type=controller --output=jsonpath={.items..metadata.name}) -c cas -- bash -c "ps -ef | grep 4001"
With CAS and Compute standardized and the Viya deployment using the same LDAP server as the NFS server we can use the same group and secondary group membership techniques to secure resources that we do in a non Kubernetes Viya deployment.
This post has talked about securing data on NFS using POSIX attributes. In the cloud, there are many more storage options available and other options for identities where POSIX attributes are not available. That is a topic for another day.
For more information:
- Stuart Rogers blog on SAS Viya Secondary Groups and Posix Considerations
- CASHOSTACCOUNTREQUIRED and CASCLOUDNATIVE documentation
I would like to thank my colleagues @GillesChrzaszcz and @StuartRogers, who were companions on this journey during the early releases of Viya 4.
Find more articles from SAS Global Enablement and Learning here.
