Using SAS Analytics Pro with CAS

2 Likes

While SAS Analytics Pro doesn’t ship with the SAS Cloud Analytic Services (CAS) server, it is possible for Analytics Pro to use CAS. In this blog we will explore the configuration required to use a CAS Server from Analytics Pro. To enable the connectivity, configuration is required for both SAS Viya and SAS Analytics Pro.

Before we get into the configuration of SAS Analytics Pro, I want to take a moment to remind you that as of April 2022 (Stable 2021.2.6) there are two versions of Analytics Pro: SAS Analytics Pro and SAS Analytics Pro Advanced Programming. SAS Analytics Pro Advanced Programming contains the same SAS Foundation components as SAS Analytics Pro plus the following additional components:

SAS/IML
SAS/OR
SAS/QC, and
SAS/ETS.

Configuring access to CAS

To connect to a CAS Server from Analytics Pro, Analytics Pro must trust the certificate being used by the CAS Server. Along with the CA certificate, the SAS Viya platform needs to be configured to allow access to the CAS Server.

We will start by looking at the SAS Viya configuration.

If you want to connect to CAS in SAS Viya 4 from clients such as SAS Viya 3.5, SAS 9.4, or with open programming clients such as Python, R, and Java, you need to enable the binary CAS communication. In this case the connection is from Analytics Pro.

With SAS Viya now running on Kubernetes, the external connectivity requires additional configuration to enable external connections to CAS (connections from outside of the Kubernetes cluster).

For SAS Viya 4, you enable the CAS connectivity by including the cas-enable-external-services.yaml transformer, which is added to the transformers section of the 'kustomization.yaml' file.

The patch transformer is required to expose the CAS client connectivity ports. This can be done using either a NodePort configuration or a LoadBalancer configuration. For instructions on how to implement this see the SAS Viya Administration manual, Configure External Access to CAS.

You need to copy the example from the sasbases ($deploy/sas-bases/examples/cas/configure/cas-enable-external-services.yaml) to your deployment site-config directory.

The default configuration defines the services as NodePorts, this is shown in the image below. If the SAS Viya platform is running in the cloud, on one of the Cloud Provider platforms (AWS EKS, Azure AKS or Google GKE), using a Loadbalancer configuration is the recommended approach.

The patch transformer (cas-enable-external-services.yaml) contains example configurations to enable the LoadBalancer configuration, see the highlighted code block below.

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

You need to uncomment the service spec to define the service type of Loadbalancer.

As part of updating the patch transformer, you should specify the allowed source CIDR ranges to secure the connections to the CAS server, see lines 32 to 34. This is used to define the firewall rules, such as the Azure Network Security Group (NSG) rules.

Note, some cloud providers may require additional configuration. For example, adding metadata annotations.

After the patch transformer has been applied, the following command can be used to get the port mappings for the CAS Server. You will need the port information for the 'sas-cas-server-default-bin' port to connect to CAS.

kubectl -n viya-namespace get svc | grep sas-cas-server

The output for a NodePort configuration will look similar to the following (using egrep to format the output).

And looks like the following for a LoadBalancer configuration. The public IP addresses for the LoadBalancer service are shown in the yellow box.

As can be seen, the LoadBalancer service has two public (External) IP addresses.

You would, or could, use a NodePort configuration when running On-Premises. For example, using RedHat OpenShift or the ‘Open Source Kubernetes’ support. However, it is important to note that when using a NodePort, the port mapping is exposed on ALL nodes within the cluster. Also, the IP address and port mapping is not static, if you redeployed SAS Viya, you would get a new mapping.

Hence, the Loadbalancer configuration is a better approach as it exposes a single public IP address for each service. However, the public IP address will change each time you do a SAS Viya deployment, it is not static. Therefore, it is best to assign a DNS alias to the public IP address, so end-users have an unchanging reference – but you’ll still need to keep that DNS alias up-to-date if the load balancer changes at some point in the future.

A customer could use their own DNS, or if running in one of the Cloud Providers a DNS name can be set against the LoadBalancer resource. For example, in Azure you can use the following to assign a DNS name to the public IP address of the binary communication endpoint for CAS.

node_res_group=MC_xxxxxxxxx_xxxxxxxxxx_xxxxxx
SUBSCRIPTION=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
NS=viya-namespace

# Get LoadBalancer External IP
CASBIN_LBIP=$(kubectl get service -n ${NS} | grep sas-cas-server-default-bin | awk '{print $4}')
# Get the Public IP resource name
PublicIPName=$(az network public-ip list --subscription ${SUBSCRIPTION} --out table | grep ${CASBIN_LBIP} | awk '{print $1}')
# Get the ID for the Public IP
PublicIPID=$(az network public-ip show -g ${node_res_group} -n ${PublicIPName} --query "id" -o tsv)

# Create the DNS name
az network public-ip update \
  -g ${node_res_group} \
  --ids $PublicIPID --dns-name cas-bin-${NS}

For my environment, this gives a DNS name of ‘cas-bin-test.eastus.cloudapp.azure.com’ when using the viya namespace name (test) as part of the name prefix. You can check the DNS name assignment in the Azure Portal, see the screenshot below.

Note, the prefix must be unique so you could also use the resource group name as part of the DNS name. This would give ‘cas-bin-resource-group.eastus.cloudapp.azure.com’ as the name.

Now you have a logical name to use when connecting to the CAS Server.

Similarly, the following code would set the DNS name for the public IP address of the http communication endpoint for CAS.

node_res_group=MC_xxxxxxxxx_xxxxxxxxxx_xxxxxx
SUBSCRIPTION=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
NS=viya-namespace

# Get LoadBalancer External IP
CASHTTP_LBIP=$(kubectl get service -n ${NS} | grep sas-cas-server-default-http | awk '{print $4}')

PublicIPName=$(az network public-ip list --subscription ${SUBSCRIPTION} --out table | grep ${CASHTTP_LBIP} | awk '{print $1}')
PublicIPID=$(az network public-ip show -g ${node_res_group} -n ${PublicIPName} --query "id" -o tsv)

az network public-ip update \
-g ${node_res_group} \
--ids $PublicIPID --dns-name cas-http-${NS}

Before we look at the Analytics Pro configuration, let’s looking in more detail at the resources that are created. In Azure, the Public IP addresses are defined in a specific resource group, starting with “MC_”. For example, the two highlighted in the screenshot are for the CAS services. The third public IP address shown in the image was created to support the ingress access to the Viya web applications.

Looking at the Kubernetes Load balancer, you will see all the public IP addresses. Again, the highlighted ones are for the CAS services.

Finally, if you look at the NSG, you will see the rules that were created. You can see the rules for ports 5570 and 8777 using the source CIDR addresses that were defined in the patch transformer.

The screenshots confirm that the patch transformer has successfully configured the AKS cluster for my environment.

SAS Analytics Pro configuration

Now that SAS Viya has been configured to allow client accesses, or in this case access from Analytics Pro. The next task is to configure Analytics Pro.

As stated earlier, Analytics Pro needs to trust the certificate being used by the CAS Server. The first step is to obtain the SAS Viya Root CA (Certificate Authority), then you need to include it in the Analytics Pro trusted certificates, in the 'trustedcerts.pem' file. You need a running instance of Analytics Pro to do this.

Step 1. Obtaining the SAS Viya Root CA

The steps to get the CA certificate are detailed in the SAS Viya Administration manual, see: Obtain the Truststore Files or the SAS Viya Generated Root CA Certificate. The following command can be used to retrieve the SAS Viya CA certificate value from the secret:

kubectl -n viya-namespace get secret sas-viya-ca-certificate-secret -o=jsonpath="{.data.ca\.crt}"|base64 -d

Note, you need to run the command above from a client that has been configured to connect to the Kubernetes cluster (i.e., has the kubectl configuration for the cluster where SAS Viya is running).

You can pipe the output of the command to a file to save the certificate – ideally to a local directory corresponding to the mounted volume inside the sas-analytics-pro container referred to as “/sasinside”.

Step 2. Update Analytics Pro to trust the Viya certificate

Now, the Viya CA certificate needs to be included in the Analytics Pro trusted certificates, in the 'trustedcerts.pem' file. This file is found in the sas-analytics-pro container in the /opt/sas/viya/config/etc/SASSecurityCertificateFramework/cacerts/ directory.

To include the Viya certificate you need a running Analytics Pro environment. The easiest way to do this is to ‘exec’ into the Analytics Pro container. You can use the following command to append the certificate information. The example assumes that the Viya CA is stored in the Analytics Pro configuration ‘sasinside’ folder.

docker exec -u=root -it sas-analytics-pro bash \ 
-c "cat /sasinside/ca_cert.pem >> /opt/sas/viya/config/etc/SASSecurityCertificateFramework/cacerts/trustedcerts.pem"

If you want to confirm that the 'trustedcerts.pem' file has been updated, use the following command.

docker exec -u=root -it sas-analytics-pro bash \ -c "cat /opt/sas/viya/config/etc/SASSecurityCertificateFramework/cacerts/trustedcerts.pem"

Note, the docker commands assume that the Analytics Pro container is called ‘sas-analytics-pro’.

It is possible to write a script to get the Viya certificate and update Analytics Pro as part of launching Analytics Pro.

Now that Analytics Pro has been updated, it can handle encrypted communication with the CAS server in your Kubernetes cluster. The last part of the configuration is to tell Analytics Pro where to find CAS with the following connection string.

options cashost='dns_alias_for_cas' casport="port" authinfo='~/.authinfo'

For information on creating a ‘authinfo’ file see: SAS Help Center: Client Authentication Using an Authinfo File

For testing I used one of our GEL environments.

You should see the following:

You have successfully started a session called 'TEST'.
The session is using 3 workers, and
You will see that the client user is 'sastest2', this was defined in the authinfo file.

I hope this is useful and thanks for reading.

References

SAS Help Center: Welcome to SAS Analytics Pro

SAS Help Center: Client Authentication Using an Authinfo File

Find more articles from SAS Global Enablement and Learning here.