Moving to the cloud with SAS/CONNECT
SAS/CONNECT has been available to connect a SAS client to a SAS server for longer than I have been a SAS employee (and I joined SAS more than 20 years ago). Yet, it keeps evolving to simplify modernization efforts and to support the migration path to SAS Viya. Legacy on-prem environments can easily leverage SAS/CONNECT to share data and programs with SAS Viya deployments, whether on-prem or in cloud environments, fully leveraging Kubernetes capabilities.
All are welcome
Beginning in the Stable release 2021.2.1 (November 2021), external clients connecting from outside the SAS Viya Kubernettes cluster can leverage backend server sessions launched by the SAS launcher service in their own pod, and not in the SAS/CONNECT spawner pod. This capability is also available to Long Term Support releases 2022.1 and later (May 2022). What does this mean, and what are the implications?
A previous post introduced how SAS/CONNECT works with SAS Viya 2020 and later, describing two different ways the spawner may use to start a backend server. Only clients co-located in the same Kubernetes cluster with the backend could use the “modern process” - which was referenced as “Use case (1)” in that post. Starting with version stable-2021.2.1, this “modern” behavior has been promoted to become the only one available by default. The legacy behavior of spawning SAS servers inside the spawner pod - referenced as “Use case (2)” - has been disabled and should only be enabled in specific cases to support legacy clients.
This is possible because fixes have been created for – and should be applied to – SAS 9.4M7, SAS Viya 3.5, SAS Viya 2020 and later. Also, the SAS/CONNECT spawner has been enhanced to act as a proxy between SAS/CONNECT clients and servers. Thanks to these changes, it makes no difference whether the client is external or internal to the Kubernetes cluster hosting SAS Viya.
If you are a visual person, here are a couple of diagrams to show the difference between the two methods:
Launched SAS/CONNECT servers – the default since stable 2021.1.2 and LTS 2022.1
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
Spawned SAS/CONNECT servers – the legacy, disabled behavior
Version compatibility
I admit I exaggerated a bit when I titled the previous section “All are welcome”. Actually, there are some requirements – and, as a consequence, some exclusions.
SAS 9.4 M7 and Viya 3.5 clients require a fix to be able to use the new “proxying” capability of the spawner, otherwise the connection will fail with a message: “Error: Cannot start remote process”. This is documented in SAS Usage Note 68611. The fix for SAS 9.4M7 clients is available at https://tshf.sas.com/techsup/download/hotfix/HF2/I9R.html#68611, while Viya 3.5 clients should be updated to use a sas-base1 rpm later than December 2021
In order for a SAS/CONNECT client using older releases (SAS 9.4M6 and older) to successfully connect to a SAS Viya 2021.1.2 and later spawner, you must re-enable the legacy behavior. This can be accomplished in two high-level steps:
- Change the security settings of the container for the SAS/CONNECT spawner back to the previous, less secure state, by including the provided
enable-spawned-servers.yamltransformer in kustomization.yaml - Change the SAS/CONNECT spawner configuration in Environment Manager to disable the
-nolocallaunchflag.
As a result of these changes, SAS/CONNECT servers will be spawned in the same pod as the SAS/CONNECT spawner. More details can be found in the “Allow the Ability to Spawn Servers within the Spawner Pod” section of the “Configure SAS/CONNECT Spawner in SAS Viya” README file located in your deployment at $deploy/sas-bases/docs/configure_sasconnect_spawner_in_sas_viya.htm.
To summarize, here are two tables that show how the two methods are available to different clients – before and after this change:
Before stable 2021.2.1 + before LTS 2022.1
| SAS/CONNECT client | Spawn servers within the spawner pod | Launch servers in their own pod |
| SAS 9.4M6 and earlier | Default behavior | Feature not available/not an option |
| SAS 9.4M7 with fix | Default behavior | Feature not available/not an option |
| SAS Viya 3.5 with fix | Default behavior | Feature not available/not an option |
| SAS Viya 2020 and later in a different cluster | Default behavior | Feature not available/not an option |
| SAS Viya 2020 and later in the same cluster | Ad-hoc configuration required | Default behavior |
Starting with stable 2021.2.1 and later, LTS 2022.1 and later
| SAS/CONNECT client | Spawn servers within the spawner pod | Launch servers in their own pod |
| SAS 9.4M6 and earlier | Ad-hoc configuration required | Feature not available/not an option |
| SAS 9.4M7 with fix | Ad-hoc configuration required | Default behavior |
| SAS Viya 3.5 with fix | Ad-hoc configuration required | Default behavior |
| SAS Viya 2020 and later in a different cluster | Ad-hoc configuration required | Default behavior |
| SAS Viya 2020 and later in the same cluster | Ad-hoc configuration required | Default behavior |
Security considerations
One of the drivers of this change is enhanced attention to security considerations. The SAS/CONNECT spawner used to require special privileges, while now it is a “normal” process compliant with container security scans:
- No more root-owned setuid processes inside the container
- The pod can use the secure "capabilities: drop: ALL" spec
- On OpenShift, it is possible to use the default, secure, “Restricted” security context constraint; the legacy behavior required a custom SCC to grant additional capabilities, as described in the “Granting Security Context Constraints on an OpenShift Cluster for SAS/CONNECT” README file located in your deployment at
$deploy/sas-bases/docs/granting_security_context_constraints_on_an_openshift_cluster_for_sasconnect.htm
A possibly unrelated consideration, but still in the context of modern cloud security: SAS/CONNECT now supports TLS 1.3. When a SAS/CONNECT client that supports TLS 1.3 connects to a SAS Viya SAS/CONNECT spawner, SAS Viya tries to encrypt the connections using TLS 1.3. Otherwise, TLS 1.2 is used. This support is available since Stable version 2021.1.6 (October 2021) and Long Term Support version 2021.1 (May 2021).
Architecture considerations
The new default of dynamically launched servers permits better scalability and resource allocation, as shown by the following two animations.
As you can see in the first diagram, the dynamically launched pods are similar in workload to the SAS Compute Servers, and, by default, the launched pods run on the Compute nodes. However, the second diagram shows that spawned servers all run in the spawner pod, which can consume significant resources. For this reason, the SAS/CONNECT spawner used to have a dedicated workload class and the suggested topology called for a dedicated nodepool.
With the new default, that’s not required anymore; hence, beginning in version stable 2021.2.6 (April 2022), the SAS/CONNECT Spawner is deployed in the stateless work class by default and does not require any dedicated node. A connect workload class is only required if you disable dynamically launched pods to support legacy clients.
You can find more about this topology change in Mike Goddard’s post SAS Viya topology changes with Stable 2021.2.6.
Cloud-native authentication
By default, in SAS Viya 2020 and later the SAS/CONNECT spawner supports a cloud native authentication mode that enables a client to authenticate via an OAuth token. No more usernames and passwords in your code! This optional capability becomes mandatory in an environment that uses the System for Cross-Domain Identity Management (SCIM) standard.
Initially, this was only available to SAS Viya 2020 and later clients; starting with Stable 2021.2.2 (December 2021), enhancements to SAS/CONNECT have made it available to SAS 9.4M7 and SAS Viya 3.5 clients. To leverage OAuth authentication, clients have to be updated as documented in SAS Usage Note 68741:
- SAS 9.4M7 requires two fixes, available at https://tshf.sas.com/techsup/download/hotfix/HF2/I9R.html#68741 and https://tshf.sas.com/techsup/download/hotfix/HF2/J7I.html#J7I005.
- Viya 3.5 clients should be updated to use SAS rpm packages later than January 19, 2022
Clients co-located within the same SAS Viya environment as the spawner will probably already have an authentication token available; they got it when the user initially authenticated with the Viya client. In this case, the code to authenticate can be as simple as:
%let session1=sas-connect-spawner 17551;
SIGNON session1 user="_OAUTH_";
Other clients will have to get a valid token, then include it in the SIGNON statement as the password:
%let session1=sas-connect-spawner.example.com 17551;
%let TOKEN=PASTE_HERE_THE_STRING_WITH_THE_TOKEN;
SIGNON session1 user="_OAUTH_" passwd="&TOKEN";
Conclusion
SAS/CONNECT has really embraced a Continuous Delivery approach, and we all benefit from the results! Dynamically launched servers by default, security compliance out of the box, support for modern cloud authentication methods... and additional improvements are already in the works! Stay tuned for a subsequent post, where we will see actual code examples to show how to leverage these exciting new capabilities with SAS/CONNECT in SAS Viya.
Find more articles from SAS Global Enablement and Learning here.
