SAS Viya – Access CAS from Outside the Viya Deployment

All Viya deployments have at least a CAS server (cas-shared-default), but the Viya administrator can add several CAS servers depending on the needs. All Viya deployment CAS servers can be easily accessed from inside the Viya deployment, but, by default, can be accessed from outside only using the CAS servers' default HTTP ingress that is configured by default (e.g.:cas-shared-default-http) that only allows REST-API access. This does not allow SAS 9.4, SAS Viya 3.5, or other SAS Viya deployments to access the CAS servers.

Viya administrator could allow access from outside to the Viya deployment CAS servers when it is required without using REST-API, or without using the default CAS servers ingresses.

In this post, I will show you how to access your Viya deployment CAS servers from outside its namespace...

The default HTTP ingress

By default, for each CAS server in a Viya deployment, an HTTP ingress is configured to provide access from outside the Viya deployment using the CAS REST-API.

The ingress enables connectivity to a CAS server, from outside the Viya deployment, using an HTTP path like: http://<viyaNamespace>.<hostname>/cas-shared-<CASInstanceName>-http/.

Tools like curl, Postman, or Jupyter could be used to access the Viya deployment CAS servers using CAS REST-API queries. As an example, we can list the cas-shared-default CAS server nodes from the gelcorp Viya deployment namespace:

curl query:

curl --user <username:pwd> http://gelcorp.xxxxxxxxxxx.race.sas.com/cas-shared-default-http/cas/nodeNames

[
 "controller.sas-cas-server-default.gelcorp.svc.cluster.local"
]

Postman query:

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

Note that the Viya administrator can disable the external HTTP ingress access using the /sas-bases/examples/cas/configure/cas-disable-http-ingress.yaml patchTransformer manifest provided by SAS through the Viya deployment assets. The external HTTP access can be set differently as you will see below.

Two kinds of external access

As it is illustrated in the diagram below, by default the Viya deployment CAS servers are accessible from outside only using their specific ingresses. Only REST-API queries can be used to query the CAS servers. From inside the Viya deployment, applications are allowed to access the CAS servers through the sas-cas-control pod.

The Viya administrator can decide to provide other external access to the Viya deployment CAS servers using two different services:

Binary service: to connect to CAS servers from another SAS Viya deployment, SAS Viya 3.5, or SAS 9.4. It also allows access using open programming clients such as Python, R, and Java.
HTTP service: to enable the HTTP REST communication, an alternative to the CAS server ingress that is configured by default.

Note that it is possible to enable one or both services in the Viya deployment regarding the requirements.

Binary Service

The binary protocol requires less conversion. Only the client must convert the objects that are transmitted and processed in the CAS binary format (binary CAS constructs). Typically, performance is better than HTTP because the data stream is more compact than REST (JSON format).

Clients can use a binary connection to the CAS server if they are set to use SAS TK subsystem.

The binary communication can be used by SAS 9.4, SAS Viya 3.5, another Viya deployment, or open-source programming clients (such as Python SWAT) that require libraries to use the binary connection. Refer to the documentation for the open-source programming client for information about the libraries.

HTTP Service

The REST protocol requires more conversions since communication is primarily done using JSON. Basically, all objects must be converted on both the client and server sides to be transmitted in JSON format. This requires more processing on both side (client/CAS server) and reduce the performance.

This service provides HTTP communication for REST. The HTTP service is an alternative to using the HTTP Ingress that is enabled by default.

Both the binary and HTTP services must be configured in the Viya deployment using patchTransformer through the kustomization.yaml file.

By default, these binary and HTTP services are enabled as NodePorts, but it is possible to define them as LoadBalancers. Please refer to the documentation for more details regarding LoadBalancer configuration. But note that setting the services to LoadBalancers affects all CAS services, including the publishDCServices and publishEPCSService if those are set for SAS/ACCESS and Data Connectors.

Set the CAS server external access

A single patchTransformer manifest file is provided by SAS through the Viya deployment assets to enable both binary and HTTP access to CAS servers. This patchTransformer manifest is $deploy/sas-bases/examples/cas/configure/cas-enable-external-services.yaml

---
apiVersion: builtin
kind: PatchTransformer
metadata:
  name: cas-enable-external-services
patch: |-
  # After you set publishBinaryService to true, apply
  # the manifest, you can view the Service with
  # `kubectl get svc sas-cas-server-default-bin`
  - op: add
    path: /spec/publishBinaryService
    value: true
  # After you set publishHTTPService to true, apply
  # the manifest, you can view the Service with
  # `kubectl get svc sas-cas-server-default-http`
  #- op: add
  #  path: /spec/publishHTTPService
  #  value: true
  # By default, the services are added as NodePorts.
  # To configure them as LoadBalancers, uncomment the following
  # service template and optionally, set source ranges.
  #
 # Note: Setting the service template to LoadBalancer
  #       affects all CAS services, including the publishDCServices
  #       and publishEPCSService if those are set for SAS/ACCESS and
  #       Data Connectors.
  # - op: add
  #   path: /spec/serviceTemplate
  #   value:
  #     spec:
  #       type: LoadBalancer
  #       loadBalancerSourceRanges:
  #       - 192.168.0.0/16
  #       - 10.0.0.0/8
  #
  # Note: Some cloud providers may require additional settings
  # in the service template. For example, adding the following
  # annotation lets you set the load balancer timeout on AWS:
  #
  # - op: add
  #   path: /spec/serviceTemplate
  #   value:
  #     spec:
  #       type: LoadBalancer
  #       loadBalancerSourceRanges:
  #       - 192.168.0.0/16
  #       - 10.0.0.0/8
  #     metadata:
  #       annotations:
  #         service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "300"
  #
  # Consult your cloud provider's documentation for more information.
target:
  group: viya.sas.com
  kind: CASDeployment
  # Uncomment this to apply to all CAS servers:
  name: .*
  # Uncomment this to apply to one particular named CAS server:
  #name: {{ NAME-OF-SERVER }}
  # Uncomment this to apply to the default CAS server:
  #labelSelector: "sas.com/cas-server-default"
  version: v1alpha1

By default, this patchTransformer manifest enables only the binary access as NodePort and is applied to all CAS servers in the Viya deployment.

To enable the CAS server(s) external access you will have to:

Copy the provided PatcheTransformer manifest file from $deploy/sas-bases/examples/cas/configure into the Viya deployment site-config directory
Edit the site-config/cas-enable-external-services.yaml manifest to:

Choose the type of access: binary (publishBinaryService), HTTP (publishHTTPService), or both.
Configure LoadBalancers instead of the default NodePorts.
Choose against which CAS server(s) this setting will be applied. Could require modifying the target filtering.

Reference the site-config/cas-enable-external-services.yaml manifest into the transformers field of the Viya deployment kustomization,yaml manifest.
Regenerate the SAS Deployment Custom Resource, if you manage your Viya deployment using the SAS Deployment Operator, or the site.yaml manifest, if you manually manage your Viya deployment. Then apply it.

When you enable at least one of these CAS server(s) external access, new Kubernetes service(s) will be created in your Viya deployment namespace:

sas-cas-server-<CASServerInstanceName>-bin: one by CAS server for the binary access.
sas-cas-server-<CASServerInstanceName>-http: one by CAS server for the HTTP access.

To find information regarding the binary service for the default CAS server in the Viya deployment namespace:

kubectl --namespace <namespaceName> get services sas-cas-server-default-bin

NAME                         TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
sas-cas-server-default-bin   NodePort   10.43.128.247   <none>        5570:2387/TCP   41m

To find information regarding the HTTP service for the default CAS server in the Viya deployment namespace:

kubectl --namespace <namespaceName> get services sas-cas-server-default-http

NAME                          TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)                                    AGE
sas-cas-server-default-http   NodePort   10.43.177.72   <none>        8777:7770/TCP,80:32080/TCP,443:25955/TCP   41m

To find information regarding both binary and http services for all CAS servers in the Viya deployment namespace:

kubectl --namespace <namespaceName> get services --selector "app.kubernetes.io/managed-by==sas-cas-operator" | grep -E "NAME | NodePort | LoadBalancer "

NAME                                   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                                    AGE
sas-cas-server-default-bin             NodePort    10.43.128.247   <none>        5570:9744/TCP                               41m
sas-cas-server-default-http            NodePort    10.43.177.72    <none>        8777:25193/TCP,80:26466/TCP,443:11816/TCP   41m
sas-cas-server-shared-gelcorp-bin      NodePort    10.43.70.61     <none>        5570:21821/TCP                              41m
sas-cas-server-shared-gelcorp-http     NodePort    10.43.130.189   <none>        8777:27955/TCP,80:19028/TCP,443:5120/TCP    41m

Access your Viya deployment CAS server(s) from outside

After the SAS Viya administrator enabled both the binary and HTTP services, it is possible to access the Viya deployment CAS servers:

Any client that uses the binary service, like SAS 9.4:

Any client that uses the CAS REST_API through the HTTP service, like Postman:

I hope this article has been helpful to you. Special thanks to SAS technical writers, and the CAS server development team.

References:

SAS documentation:

SAS® Viya® Administration

SAS® Viya®: SAS® / Deployment / Deployment / Installation / Configure External Access to CAS

SAS® Viya® Programming Documentation / Open Source Programming

Relative GEL Posts:

Using Postman Collections to Execute SAS REST APIs
Planning the URL names of your SAS Viya deployment – part 2 (most specifically the "How to access and expose the CAS and CONNECT ?" section)