In this article I want to review the changes to encryption in-motion with SAS Viya 3.3. We will consider what is configured by default, what addition items we can configure, and how configuration can be changed.
We will start by looking at the different network connections in our Viya 3.3 environment. The diagram below illustrates these connections:
By default, almost all the network connections shown in the diagram above are secured using Transport Layer Security (TLS). Only the SAS Cloud Analytic Services inter-node communication and SAS Embedded Process communication is not secured by default. This is due to the large performance impact of enabling the CAS inter-node encryption. But, this can be enabled through configuration changes.
Clarification: For encryption in-motion with the SAS Embedded Process, the configuration on the CAS side is complete by default. However, the SAS Embedded Process configuration, on either Hadoop or Teradata must be updated to enable it. The DCTCPMENCRYPT option defines if encryption will be used, see the Encryption Guide for further details.
TLS is used as the mechanism to provide encryption in-motion. As we know to use TLS we require both a private key and a signed server certificate. The signed server certificate contains the public key. The server certificate is signed so that the client can attempt to ascertain if the server it is connecting to is really the server. The signature is performed by a trusted party and that trusted party is assuring the client that the server certificate as issued to a certain server.
In our SAS Viya 3.3 environment the SAS Secret Manager is the trusted party that signs the server certificates. SAS Secret Manager is new with SAS Viya 3.3. The SAS Secret Manager generates both a root Certificate Authority certificate and private key as well as an Intermediate Certificate Authority certificate and private key. The Intermediate Certificate Authority is used to sign the individual server certificates. The defaults are illustrated here:
Although the Server certificate has a default maximum lifetime of 7 years, the SAS Viya 3.3 microservices and web applications only request a server certificate with a lifetime of 1 year.
The easiest button of all – it’s turned on by default. But, if for some reason you want to turn off parts of the encryption in-motion you can perform this via SAS Environment Manager. There are four settings:
These four toggles enable (default) or disable encryption in-motion for different parts of the SAS Viya 3.3 environment. The table below details these four settings:
Family Name | Description | Ports Controlled |
---|---|---|
databaseTraffic | Port family that,needs to control traffic to database servers that might be located on,different network segments. | SAS Infrastructure,Data Server, EP Data Connectors |
sasData | Port family that,controls traffic transporting data to SAS servers.,The SAS Workspace,Server and the SAS Object Spawner use this port family to enable and disable,AES encryption at on startup. | CAS Client, SAS,Compute Server, SAS/CONNECT Server, SAS/CONNECT Spawner, SAS Event Stream,Processing (ESP) Server, SAS Workspace Server, SAS Object Spawner |
serverControl | Port family that,controls traffic sent between clustered servers to maintain the cluster. | SAS Launcher Server |
web | Port family for any,network associated with machines running web applications | Apache HTTP Server,proxy settings, all web apps and microservices, SAS Cache Locator, SAS,Message Broker, CAS Rest, ESP App, SAS Studio |
However, the ports for SAS Secret Manager and the SAS Cloud Analytic Services inter-node communication are exempt from the family of ports that can have TLS enabled or disabled in this way. SAS Secret Manager is always secured. Also, SAS Configuration Server is controlled via the settings in the vars.yml for SECURE_CONSUL (enables port 8501 with HTTPS) and DISABLE_CONSUL_HTTP_PORT (disables port 8500).
Unfortunately, the deployment process is not quite magical and there are still some tasks to complete to make the environment work well for you. Most people will want to:
The first two tasks you will want to complete to make your SAS Viya 3.3 environment useable by your end-users. You will want to use your own signed certificates for the two entry points into the SAS Viya 3.3 environment. The Apache HTTP Server will be the entry point for the Visual Interfaces and so will be the most important item for you. Then if you are going to access CAS from outside the Visual Interfaces, either from a third-party language like Python, Java, or Lua or you want to directly access from SAS 9.4 Maintenance 5, you will want to update the private key and server certificate used by CAS.
The third task should also be important for most people. You will need to provide security on the connection from the SAS Viya 3.3 environment to your LDAP Provider. This means you need to use LDAPS on those connections and we need to ensure SAS Viya 3.3 correctly trusts the certificate presented by the LDAP provider.
Finally, for all three tasks you are going to need to ensure the trust stores used through-out the SAS Viya 3.3 environment are correctly updated. You will want to ensure any new certificates are correctly trusted by the different components. To do this you will need to update the trust store.
The public documentation provides instructions for these tasks and we may well look at them in future posts as well. Certainly, we will address the topic of managing the trust stores in a future article.
Join us for SAS Innovate 2025, our biggest and most exciting global event of the year, in Orlando, FL, from May 6-9.
Lock in the best rate now before the price increases on April 1.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.