The release of SAS Viya 2021.1.3 introduces significant security changes for SAS Cloud Analytic Services. These changes will also be included in the SAS Viya 2021.2 LTS release. The change we will discuss here is to make SAS Cloud Analytic Services more secure by default. This involves preventing, by default, the ability to run CAS sessions under a host identity. The changes in SAS Viya 2021.1.3 relating to TLS configuration were discussed in a previous article.
The ability to run CAS sessions under a host identity can be added to a SAS Viya deployment, but will require updating the kustomization.yaml, rebuilding the site.yaml, and applying the updated site.yaml. In this blog we will examine the situations when you would want to use host launched CAS sessions and how you enable them.
Default Session Launch
By default, the CAS session will run as the CAS service account, which defaults to the user "sas". This is irrespective of how the end-user connects to SAS Cloud Analytic Services. So, an end-user launching a CAS session from SAS Visual Analytics will see the same behaviour as an end-user directly launching a CAS session from some Python code. In this blog we are concerned with the scenarios where this default behaviour is not what is required. Instead in these scenarios the CAS session will be launched under a host identity.
Host Launch Scenarios
Before we discuss how to enable host launched CAS sessions with SAS Viya 2021.1.3 (and later) we will look at some scenarios for when you would want to use host launched sessions. Remember prior to SAS Viya 2021.1.3 all you needed to enable host launched sessions was to either specify the environment variable CASALLHOSTACCOUNTS or create the custom group with the ID CASHostAccountRequired and add users/groups to the custom group.
Scenario 1: Kerberos
When SAS Cloud Analytic Services is configured for Kerberos, including direct Kerberos connections, CAS automatically sets the CASALLHOSTACCOUNTS environment variable. Since when you authenticate with Kerberos you expect the CAS session to be running as the end-user that has used Kerberos to authenticate. As such, with SAS Viya 2021.1.3 and Kerberos, you must complete the additional steps to enable host launched sessions detailed below.
Scenario 2: Running Python code from MAS
SAS Micro Analytic Service supports modules that are written in the Python programming language. You and/or your users might be embedding a Python script inside a SAS decision within SAS Intelligent Decisioning. As the documentation makes clear users who are working with Python code files must have a host launched CAS session. So, again with SAS Viya 2021.1.3, you must complete the additional steps to enable host launched sessions detailed below.
Scenario 3: Host Access Control
If you have a large existing complex host access control model that has been applied to your SAS data sets you will need to ensure the CAS sessions are running with your end-user’s host accounts rather than the default CAS service account. So, you need to ensure you are running host launched CAS sessions so that the host access controls are applied correctly. Prior to SAS Viya 2021.1.3 you would just specify the CASALLHOSTACCOUNTS environment variable, and this would be sufficient. With SAS Viya 2021.1.3 (and later) you must also enable host launched CAS sessions as shown below.
Scenario 4: PAM Authentication
For some scenarios you might want to leverage Pluggable Authentication Modules (PAM) and the System Services Security Daemon (SSSD) to authenticate the username and password of users connecting to SAS Cloud Analytic Services. This might be to leverage stored credentials (more on this next) or to validate the username and password presented by direct connections from third-party programming languages like Python . Remember the direct connections will also authenticate with SAS Logon Manager.
Direct connections from programming clients, like Python, do not have to use PAM for authentication. In the default configuration these credentials are only validated with SAS Logon Manager. But if you have a large user base configured to authenticate to SAS Logon Manager and only want a small subset to be able to directly authenticate to SAS Cloud Analytic Services then using PAM could be an efficient solution.
For this scenario, prior to SAS Viya 2021.1.3, you would set the environment variable CASCLOUDNATIVE=0 and configure SSSD. Then either specify the environment variable CASALLHOSTACCOUNTS or create the CASHostAccountRequired custom group and assign users/groups to it. Now with SAS Viya 2021.1.3 in addition, you must also enable host launched CAS sessions as covered below.
Scenario 5: Stored Credentials
In some cases, you will want the CAS session to be launched using a username/password that you have stored in the DefaultAuth authentication domain for either users or groups. This might be to ensure all users in a group run their CAS sessions with the same host user. Or it might be because you rely on host access controls but with usernames that are different to the usernames your end-user log into SAS Viya with.
Prior to SAS Viya 2021.1.3, you would set the environment variable CASCLOUDNATIVE=0 and configure SSSD. Next you would either as an administrator store a credential for a group of users to use, or have individual end-users store a credential in the DefaultAuth authentication domain. Then either specify the environment variable CASALLHOSTACCOUNTS or create the CASHostAccountRequired custom group and assign users/groups to it. Now with SAS Viya 2021.1.3 in addition, you must also enable host launched CAS sessions as covered below.
Enabling Host Launched CAS Sessions
SAS Cloud Analytic Services can be configured to enable host launched session by including a patch transformer in your kustomization.yaml file. Further details can be found in the README.md file in the directory sas-bases/examples/cas/configure. In the same directory is a sample YAML file called cas-enable-host.yaml. You can copy this into your CAS server overlay directory, for example site-config/cas-server. Then you reference the relative path of the cas-enable-host.yaml in the transformers block of the kustomization.yaml file, it must appear before the sas-bases/overlays/required/transformers.yaml line. For example:
transformers:
...
- site-config/cas-server/cas-enable-host.yaml
...
- sas-bases/overlays/required/transformers.yaml
...
The cas-enable-host.yaml file contains a patch transformer that does the following:
- Adds a security context to the CAS controller template
- Adds the setting allowPrivilegeEscalation = true to the security context
- Adds a capabilities section to the security context
- Within the capabilities section adds
- Within the capabilities section drops all other capabilities
- Adds the setting privileged = false to the security context
- Adds the setting readOnlyRootFilesystem = true to the security context
Let’s look at what these items in the security context do. First the setting AllowPrivilegeEscalation, as per the Kubernetes documentation this controls whether a process can gain more privileges than its parent process. This is required to enable the setuid root process that will be used to launch the CAS session as the end-user.
Next the capabilities section, this adds and removes POSIX capabilities from running containers. As covered in the Kubernetes documentation. The patch transformer for CAS ensures only SETGID, SETUID, and CHOWN are the capabilities available to the CAS pod. Again, this is required to enable the setuid root process to launch the CAS session as the end-user.
The setting privileged, is a Boolean option whether to run the container in privileged mode. As the Kubernetes documentation states: Processes in privileged containers are essentially equivalent to root on the host. Defaults to false. So, the CAS patch transformer ensures the default value of false is used since the CAS container does not need to run as root.
Finally, the option readOnlyRootFilesystem controls whether the container has a read-only root filesystem. The Kubernetes documentation states that this defaults to false. The CAS patch transformer sets this to true. This means that the CAS pod cannot write to the file system within the pod. It will only be able to write to file systems presented by Kubernetes to the pod (i.e. persistent volumes).
The default security context for CAS with SAS Viya 2021.1.3 is:
- allowPrivilegeEscalation = false
- capabilities
- privileged = false
- readOnlyRootFilesystem = true
You can check the security context with the following kubectl command:
kubectl -n ${NS} get CASDeployments -o jsonpath='{.items[*].spec.controllerTemplate.spec.containers[0].securityContext}'
Where ${NS} is your namespace. This shows that applying the patch transformer is only really changing the value of allowPrivilegeEscalation and adding the SETGID, SETUID, and CHOWN capabilities.
Conclusion
With previous versions of SAS Viya, it was possible to enable host launched CAS sessions either with an additional environment variable (CASALLHOSTACCOUNTS) or with membership of a custom group (ID=CASHostAccountRequired). However, in this blog we have highlighted the security changes for SAS Cloud Analytic Services with SAS Viya 2021.1.3 that, by default, prevent the use of host launched CAS sessions. We have shown several scenarios where you will need to take additional actions to enable CAS host launched sessions – otherwise these scenarios will no-longer function. Finally, we have shown the simple steps to enable CAS host launched sessions and discussed what the patch transformer is doing.
Find more articles from SAS Global Enablement and Learning here.
