External Binary Access to CAS: Understanding the Connectivity Model
SAS Cloud Analytics Services (CAS) is a powerful analytic engine in the SAS Viya platform, providing a run-time environment for data management and analytics. For this reason, you might want to enable access to CAS also for clients running outside the SAS Viya cluster.
This series shows you how to enable external binary access to CAS by applying core connectivity principles: a valid network route, proper DNS resolution, and trusted TLS certificates.
Across three posts, you’ll go from understanding the model to implementing cloud‑friendly automation and on‑prem‑friendly manual steps, including practical configuration examples.
Let’s start with the basics. As an analyst or developer, how can you connect to CAS in a default SAS Viya environment? Why, and how, would an administrator enable additional external binary connectivity?
You can find answers to these questions in multiple sources, from the official documentation, to a similarly focused article written a few years ago by Gilles Chrzaszcz: SAS Viya – Access CAS from Outside the Viya Deployment.
With this series, we want to build and expand on these sources, starting with the default CAS configuration, to show you the three essential requirements for successful external access: a working network route, correct DNS resolution, and trusted TLS certificates. This will set the stage for the more practical hands‑on patterns covered in the next articles. You will also see how to easily troubleshoot connection issues, avoiding any “magic box” confusion.
What’s available by default and what you can optionally enable
By default, every CAS server exposes two ports to internal applications (i.e., clients running inside the same SAS Viya cluster): port 8777 for HTTP connections, and port 5070 for binary connections. HTTP is leveraged via REST API calls. Typically, performance is better with binary connections because the data stream is more compact than REST, and binary data types can be shared using their native format, without any intermediate conversions.
For external clients that use REST, for example Python programs using SWAT, SAS Viya configures by default an HTTP Ingress that provides access to CAS from outside the cluster. The default CAS instance can be reached using a path like https://www.example.com/cas-shared-default-http/; if you create additional CAS servers, SAS Viya creates ad-hoc paths using the server instance name instead of the word “default”.
If you want to connect to CAS from a SAS 9.4 server, or any other external client using a binary protocol, then additional configuration is required.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
The “three requirements” model, and two ways to fulfill them
SAS Viya can be deployed on different infrastructure providers, permitting multiple architectural patterns that can change based on the chosen platform. Yet, independently of the actual architecture, there are 3 high-level requirements that need to be satisfied for an external client to reach a CAS server using the binary protocol:
- Network route: there should be a network route between client and server, that is, a routable path from the client to the external endpoint that then forwards the connection to CAS.
- Name and address resolution: clients connect via a DNS name alias or IP address that must resolve to the correct external endpoint.
- TLS trust: clients must trust the TLS certificate chain and the CAS server TLS certificate must include the name or IP used by the client.
In the next articles of the series, you will see how to fulfill these requirements in two generic cases: leveraging automation with SAS Viya deployed on cloud environments, and using manual steps tailored to on-premises datacenters.
In the first case, working in the cloud, if you define a Kubernetes service of type LoadBalancer, the Kubernetes cluster will trigger the cloud infrastructure to provision a network load balancer configured to route the incoming connections to the desired backend pod (that is, the CAS controller pod). This fulfils requirement #1.
If the environment has been properly configured, it can also automatically create a DNS record that resolves to the load balancer frontend. That’s requirement #2.
SAS Viya automates this process in cloud environments because the CAS Operator can create for you the LoadBalancer service and include the service name in the CAS server TLS certificate, all though simple declarative configuration settings. This latter step covers requirement #3.
A sample OpenShift on Azure environment showing the binary connection flow from an external client to CAS in the cloud.
In the second case, when working on premises, it might not be possible for Kubernetes to control the underlying infrastructure. In this case, an IT administrator might be responsible for configuring all the network artifacts (such as DNS records, IP addresses, load balancers, network routing) so that external clients can successfully resolve the service name and reach the CAS server running in the cluster. These are requirements #1 and #2.
When deploying SAS Viya on-prem, the Kubernetes administrator might want to create a CAS service as they would with any other Kubernetes service, bypassing any CAS Operator automation. This would also cover requirement #1.
Finally, during SAS Viya configuration, the SAS administrator must specify the external DNS alias and IP address as additional entries in the TLS certificate used to encrypt CAS communication. This fulfils requirement #3.
A sample OpenShift on-prem environment showing the binary connection flow from an external client to CAS.
You might have noticed how, with the automation exemplified on cloud environments, a SAS administrator might be able to work almost autonomously. The manual case, on the contrary, requires stricter collaboration between infrastructure, Kubernetes, and SAS administrators.
Preflight #1: validate internal CAS connectivity before making any changes
Before embarking on any configuration changes to enable external access to CAS, you might want to validate that internal, in-cluster connectivity works as expected. A simple way to do that is to log into SAS Studio and submit this short code:
/* --Create CAS Connection-- */
options cashost="sas-cas-server-default-client" casport=5570;
cas mySession;
cas mySession clear;
Looking at the log window, you should be able to identify a confirmation note such as the following:
...
NOTE: The session MYSESSION connected successfully to Cloud Analytic Services sas-cas-server-default-client using port 5570. The
UUID is bb5b1cc0-cb9e-e244-9db0-4a36683931e1. The user is Hugh and the active caslib is CASUSER(Hugh).
...
This confirms that you have connected to CAS using the default Kubernetes service name sas-cas-server-default-client, on the specified binary port 5570, re-using the same credentials you entered when logging into SAS Studio.
If you have access to the kubectl CLI, you can also inspect the Kubernetes service:
NS=gelcorp
kubectl -n ${NS} get service sas-cas-server-default-client -o json
Here is a sample output:
{
"apiVersion": "v1",
"kind": "Service",
"metadata": {
"creationTimestamp": "2026-02-09T16:31:51Z",
"labels": {
"app.kubernetes.io/instance": "default",
"app.kubernetes.io/managed-by": "sas-cas-operator",
"app.kubernetes.io/name": "sas-cas-server",
"casoperator.sas.com/instance": "default",
"casoperator.sas.com/server": "default",
"casoperator.sas.com/tenant": "shared",
"sas.com/deployment": "sas-viya",
"sas.com/tenant": "shared"
},
"name": "sas-cas-server-default-client",
"namespace": "gelcorp",
"ownerReferences": [
{
"apiVersion": "viya.sas.com/v1alpha1",
"blockOwnerDeletion": true,
"controller": true,
"kind": "CASDeployment",
"name": "default",
"uid": "bbb30efb-928a-4836-9be7-ed5e47647d51"
}
],
"resourceVersion": "59839",
"uid": "a5612b89-d085-4e17-a414-deea76a58ae7"
},
"spec": {
"clusterIP": "172.30.196.214",
"clusterIPs": [
"172.30.196.214"
],
"internalTrafficPolicy": "Cluster",
"ipFamilies": [
"IPv4"
],
"ipFamilyPolicy": "SingleStack",
"ports": [
{
"name": "cal",
"port": 5570,
"protocol": "TCP",
"targetPort": 5570
},
{
"name": "http",
"port": 8777,
"protocol": "TCP",
"targetPort": 8777
}
],
"selector": {
"casoperator.sas.com/controller-active": "1",
"casoperator.sas.com/node-type": "controller",
"casoperator.sas.com/server": "default"
},
"sessionAffinity": "None",
"type": "ClusterIP"
},
"status": {
"loadBalancer": {}
}
}
The definition confirms that:
- The service points to the default CAS primary controller pod (as highlighted in the .spec.selector fields)
- The service is listening on a TCP port 5570 (as highlighted in the .spec.ports fields)
- The service is managed by the CAS Operator via the CASDeployment custom resource (as highlighted in the .metadata.ownerReferences fields)
- You can reach the service endpoints only from inside the cluster (.spec.type is ClusterIP, .spec.clusterIP lists an internal IP address, and .status.loadBalancer is empty)
Preflight #2: ensure the client TLS trust chain works
A.k.a. distributing the SAS Viya CA certificate to clients
Many non-production environments leverage the default, self-signed SAS Viya root CA. This Certificate Authority is used to sign all server certificates, including CAS ones. Although convenient (it is configured by default at deployment time), it is unknown to any client external to the cluster because it is self-signed. Which means that these clients cannot trust SAS Viya server certificates and could abort any tentative to connect.
You can tell you are in this situation when, the first time you log into a web application such as SAS Studio, the browser presents you with a security warning that you have to accept before you can get in. In this case, to be able to connect to CAS from an external client, you have to obtain the SAS Viya root CA certificate and then import it into the client truststore. After that, the client will trust the certificates presented by SAS Viya servers. The official documentation lists a simple command to save the required certificate into a temporary file:
NS=gelcorp
kubectl -n ${NS} get secret sas-viya-ca-certificate-secret -o go-template='{{(index .data "ca.crt")}}' | base64 -d > /tmp/SASViya_ca.crt
Then you have to copy the resulting SASViya_ca.crt file to your client (you can email, ftp, network copy… ), and import it in the client truststore, for example following the instructions in the Encryption in SAS® Viya®: Data in Motion guide in the section Import CA Certificates into the Windows Trusted Root Certificate Authorities Store.
What’s next (Part 2 and Part 3)
Now that you have set the groundworks with high-level concepts, requirements and preliminary checks, you are ready to get your hands dirty with two complete scenarios presented in the next articles of the series. Part 2 showcases full automation on the cloud, thanks to the “LoadBalancer pattern”, while part 3 describe the manual steps to integrate a NodePort service with an external load balancer, paired with TLS certificates customization and comprehensive troubleshooting.
See you soon!
Find more articles from SAS Global Enablement and Learning here.
