Accessing path-based data from CAS in Viya
The new SAS Viya brings a change for CAS in where users can read and write data. In this article, I will describe the change and its implications. From a CAS server, all access to file system paths is through caslibs. Path-based caslibs use as their source a directory on a file-system. As a security measure, CAS has the ability to limit the paths that are available to non-administrators (CAS super-users) when they create or edit a caslib. This ability is governed by the allowlist and the denylist.
These two lists are mutually exclusive, you can only have one implemented at a time. Here is what they do:
• denylist: specifies a list of paths that are not available to general users
• allowlist: specifies a list of paths that are available to general users.
In the prior version of SAS Viya (3.5), by default, the denylist (formerly the blacklist) is active and includes a small list of paths where users cannot create/edit caslibs. This leaves the system mostly wide-open in relation to where a user (who is authorized to do so) can create and edit path-based caslibs.
In the new SAS Viya , in order to provide a more secure deployment out-of-the-box, the allowlist is active instead of the denylist and the allowlist includes one path /cas/data/caslibs. This path in the new SAS Viya is typically on a persistent volume used by the CAS server. What this means is that, by default users cannot create/edit caslibs in any other location.
There are two options if you want to create caslibs in a different location:
- Viya administrators who has assumed the CAS super user role are not governed by the allowlist or denylist and can create caslibs that point to any available path.
- Viya administrators can make additional paths available by adding them to the allowlist.
The new SAS Viya runs on Kubernetes so for CAS to access data on the file system, the file system location has to be made available to the CAS pod. One of the ways to make data available to CAS is by mounting a directory into the CAS pods. In our Viya 4 administration class (soon to be released) we mount an NFS directory to make it available to CAS. There is an example of how to do this in this article.
Essentially the end result of the NFS mount is that we make a path on the NFS server /shared/gelcontent that contains our data, available to a mount-point /gelcontent inside the CAS pod. The change to implement the default allowlist means that if we want to define a caslib in that new location we either need to do it as a super-user or add the path to the allowlist.
For example, in the prior version of SAS Viya (3.5) we could do this and it would create a caslib:
./sas-admin cas caslibs create path --caslib salesdl
gelcontent/gelcorp/sales/data --server cas-shared-default --description
"gelcontent salesdl
Running the same code in the new SAS Viya (2020.1 and beyond) fails. To get an idea of what happened we need to add the --verbose option to the command
./sas-admin --verbose cas caslibs create path --caslib alesdl
/gelcontent/gelcorp/sales/data --server cas-shared-default --description
"gelcontent salesdl
{"errorCode":12299,"message":"The action was not successful. (2-0-2640595)",
"details":["traceId: bc84b4db0ccb1c09","path:
/casManagement/servers/cas-shared-default/caslibs
"ERROR: Cannot add caslib salesdl. It uses a path that is not in the allowlist
.","ERROR: The action stopped due to errors.","0x887fc253:PERM_ALLOWLISTED"],
"links":[],"version":2," httpStatusCode":409}
The action was not successful. (2-0-2640595)
The error message is very helpful! It is an easy fix, if the account your are using is a Viya administrator you can assume the super-user role and that will allow you to create caslibs in any location that is accessible. In code above that uses the command-line interface we can just add the -su option and the caslib creation will be successful. As a superuser we can create caslibs anywhere that CAS can access.
If you do not want to always define caslibs as a super user the other approach is to add paths to the allowlist. This can be done interactively using SAS Environment Manager or using an example overlay to update the CAS Deployment definition in site.yaml.
Add to the allowlist in Environment Manager
To perform the task interactively. Logon to SAS Environment Manager as an administrator.
In the Servers area: select the CAS server whose allowlist or denylist you want to access and click Superuser icon to assume the Superuser role.
Right-click on the server and select Settings.
In the Settings window make sure that the Paths List tab is selected. To modify the active list, or to switch between lists, on the right side of the Server Settings window, click the Edit icon. If you select an allowlist you can add or remove paths to the list.
To save any changes, click Save.
Add to the allowlist using kustomize and kubectl
As I described in my previous article, Viya administrators will have to get used to the kubectl and kustomize to administer Viya deployments. These tools allow us to update the kubernetes manifest (usually site.yaml) which describe the Viya environment. The overall flow of the process is:
- Create user-defined yaml files and store them in a directory (site-config) that is a sub-directory of the location where kustomization.yaml file resides.
- Edit the kustomization.yaml file to reference the newly created yaml file
- Use kustomize build to build the Kubernetes manifest (site.yaml)
- Use kubectl apply to update the environment with the changes.
To help with this process SAS delivers, with the software, many example files which can be used as a starting point for making configuration changes. Fortunately there is an example for adding to the allowlist. The example is located in the project directory at "../deploy/gelcorp/sas-bases/examples/cas/configure/cas-add-allowlist-paths.yaml.
Using the example overlay as input we create a new overlay under our site-config directory and add any paths to the list. In this case we add the /gelcontent path. The path is the mount point we configured inside the POD. The target definition indicates we want to apply this patch to all objects of the type CASDeployment.
To make the overlay available to kustomize we add the following line to the transformers section of our kustomization.yaml file
[...]
transformers:
[... previous transformers items ...]
- site-config/cas-add-allowlist-paths.yaml
[... more transformers items ...]
[...]
The partial kustomization.yaml looks like this:
With these changes made use kustomize build to build the Kubernetes manifest (site.yaml) and then use kubectl apply to update the environment (only the resources that have changed will be updated)
cd ~/project/deploy/gelcorp
site.yaml sitebefore.yaml
kustomize build -o site.yaml
kubectl apply -f site.yaml
We can look at the changes made to the manifest, by comparing before and after.
Typically with a change to CAS we need a restart to pickup the changes.
kubectl delete pod --selector='app.kubernetes.io/managed-by=sas-cas-operator'
With CAS restarted the allowlist is updated and users other than the super-user can create/edit caslibs in any path in the list. While this change is not a huge one it does result in different behavior in Viya 4 and can have an impact on existing scripts and functionality. Fortunately, it is easy to recognize and fix. For more information:
Manage Path Lists (Allowlists and Denylists)
