SAS Viya Network Security on Kubernetes: A TLS Primer

2 Likes

Even if you have a solid understanding of security options for SAS 9.x and SAS Viya 3.x, many aspects of SAS security have changed with the recent evolution of SAS Viya on Kubernetes. SAS Viya 2020.1 and later relies on a set of components that we call the SAS Security Certificate Framework. This collection of software applications and supporting YAML files was designed to secure your SAS Viya deployment and your Kubernetes cluster.

Glossary

The following terms and definitions are used in this primer:

TLS

Transport-Layer Security, an internet protocol that defines how data privacy can be ensured by the application of encryption to network traffic flowing between known endpoints. SAS Viya applies TLS to the deployment automatically unless you opt out.

Certificate Authority

The business entity or organization that safeguards the private keys that are used to sign Certificate Authority Certificates (CA Certificates) and supplies identity certificates signed by these private keys. TLS identity certificates are files that enable verification of the owner of an encryption key.

Root CA Certificate

The top certificate in a certificate chain of trust; a self-signed certificate that is used to issue (sign) either intermediate CA certificates or server identity certificates. When this certificate is placed in a trust bundle, software applications that are using that trust bundle will accept and trust server identity certificates that it has issued.

Trust bundle

A file containing one or more root CA certificates. The trust bundle might also contain one or more intermediate CA certificates.

Intermediate CA Certificate

A CA certificate that is not the root (or top-level) CA certificate. This certificate can be used to issue other intermediate certificates or server identity certificates. Intermediate CA certificates can form a chain that looks like this:

Server Identity Certificate

A certificate that establishes the identity of a specific machine (server) by name or IP address.

Chain of Trust

The set of certificates in a chain of certificates that leads from the server identity certificate to the root CA certificate. Trust is established when a machine presents a server identity certificate whose root CA certificate is in the trust bundle that the application is configured to use. The certificate chain for back-end servers in a SAS Viya deployment has no intermediates, so the chain of trust looks like this:

Certificate Issuer

The issuer of a certificate is the CA certificate that signed it. The issuer of a certificate acts something like a parent of the certificate. A certificate’s Issuer attribute displays the issuer certificate’s subject. By itself, the issuer's subject is not a reliable way to identify an issuer certificate because there can be many different certificates with an identical subject value.

Certificate Generator

A software application, hardware device, or system that creates the certificate and private key pairs used to secure network connections. SAS Viya supports two certificate generators: openssl and cert-manager.

Front-door component

An application (a web server, an analytics server) that is reachable from both inside the Kubernetes cluster and outside the Kubernetes cluster. The ingress controller is a front-door component, as are other components such as CAS and the Connect Spawner, both of which are reachable via configured load balancers or node ports.

Back-end component

An application (usually a web application, web service, database server) that is not reachable from outside the cluster. To reach back-end components data must travel through the ingress controller.

SAS Viya Security Configuration Modes

SAS Viya supports three options for configuring TLS to secure network connections:

"Full-stack" TLS. All SAS Viya network communication requires TLS connections.
"Front-door" TLS. Only the “front-door” components require TLS connections. “Back-end” components that handle network traffic contained entirely within the cluster use unencrypted connections and will not accept TLS connections.
"No TLS". None of the SAS Viya components accepts TLS connections. No network traffic is encrypted. This mode should only be used with demo data and demo credentials because passwords flow over the network in clear text.

In this primer, we use the metaphor of a bank to explain the three TLS modes that you can configure for SAS Viya.

Understanding TLS Modes

Thinking of your Kubernetes cluster as a bank provides a powerful metaphor for how Ingress security works in Kubernetes. Think of the Kubernetes pods as the offices in a bank and the containers running in these pods as employees in the offices doing work.

When you want to conduct business with a bank, you come in from the public streets through the front door of the bank. The tellers in a bank perform a function that is similar to that of an ingress controller.

You give the tellers a request to complete a task--for example, to make a wire transfer. The teller accepts your request and asks you to wait. The teller then examines the request and determines which office in the bank handles wire transfers. The teller takes your request to the back offices behind the teller window and delivers it to the specialist in the wire-transfer office.

The hallway leading to the wire transfer office is private. It is inaccessible to the public and can only be accessed by bank workers like the teller and the wire-transfer specialist.

The wire-transfer specialist works inside an office whose office number helps the teller locate it. Its walls isolate it from other offices so that the workers in other offices cannot interfere with the work being done by the wire-transfer specialist. All the work necessary to complete the requested task is performed inside the bank’s many offices. In each office, one or more specialized workers perform a specific task.

In this case, the teller passes the request to the wire-transfer specialist, who does the work and hands the results back to the teller. The teller returns to the bank lobby with the results and gives them to you through the teller window.

Often a particular task requires the work of multiple specialists. For example, the wire-transfer specialist needs to know whether the customer has sufficient funds to send the wire transfer. To verify this information, the wire-transfer specialist needs to collaborate with the account-balance specialist. The wire-transfer specialist sends a request for account balance information down the same secure, internal hallway to the account-balance office. The account-balance specialist does the required work and delivers the answer to the wire-transfer specialist’s office through the internal hallway. The teller is not involved in these internal, back-office communications.

How Does Any of This Relate to SAS Viya?

When performing a task--for example, scoring a data model--SAS Viya uses analogous methods for keeping transactions secure and keeping data private. The ingress controller functions like a bank teller; the internal cluster network functions like the private, employee-only hallway; and the web application containers running inside the pods function like the bank specialists working inside the offices.

To use SAS Viya, you connect with the ingress controller from a web browser across the public network and submit a request (for model scoring, for example). The ingress controller determines which pod handles model-scoring requests and sends the request through the private cluster network to that pod. The container in the pod that runs the model-scoring web application (or the model-scoring service) receives the request and does the work. It sends the results back to the ingress controller through the internal cluster network. Then the ingress controller sends the results across the public network and back to you.

To accomplish anything useful usually requires the combined effort of multiple web applications or services. For example, the model-scoring service needs to know whether the individual requesting the score has permission to access the requisite data. In order to verify permissions, the model-scoring service must collaborate with the authorization service. Running inside its pod, the model-scoring service can use the internal cluster network to communicate directly with the authorization service inside another pod. The ingress controller is not involved with this internal, service-to-service, pod-to-pod network traffic.

In our bank example, the back-office workers never interact directly with the customers. They only receive instructions from the teller. Tellers work inside their offices and interact with the public through windows. They are specially trained to handle the public and know how to stay behind the protective glass of their offices if bad actors enter from the public network.

Similarly, ingress controllers are specifically designed to thwart bad actors on public networks and protect the back-end services in a cluster. The back-end services in a SAS Viya deployment are only allowed to communicate with other applications on the internal cluster network and with the ingress controller. They cannot be reached directly from the public network.

Handling Private Data

When you interact with a bank, you provide personally identifiable information (PII) to the bank. This PII is necessary to establish your identity, and it might include your name, your online banking password, your bank account number, your social security number, and more. You trust the tellers to protect this data and keep it private. The back-office specialists also need to know your PII in order to perform their jobs. The wire-transfer specialist needs to know your name, bank account number, and account balance. While a partially completed task is being shuffled up and down the internal hallway among the offices that house back-end workers, the private data associated with the task travels with it.

When TLS is enabled for SAS Viya, network transmissions are encrypted so that anyone listening in on the network cannot read their contents. Encryption is a standard way to protect private data as it moves from one location to another, preventing that data from being read by the public. You would not want your name or social security number to be visible as you take your request to the bank. So you place the data inside an opaque envelope before you leave your home and you hand the envelope to the bank teller through the teller window. The teller does not open the envelope until it is safely inside the office. This allows the bank to keep your information private.

Just as it takes time to continually open and seal the envelopes, continually encrypting and decrypting data requires additional processing cycles and can degrade performance. When applying TLS, you must balance the need for performance against the need for security.

The owners of some banks believe that while it is traveling within the internal bank hallways, it is safe to leave the data visible to all bank employees. After all, the teller, the wire transfer specialist, and the account balance specialist must be shown your data in order to verify your identity. It is reasonable to assume that most bank employees already have access to private data. This access is acceptable if the bank has very tight perimeter security so that only authorized bank employees can get access to the hallways inside the bank.

In cases where it is acceptable for data that stays entirely within the bank’s hallways and back offices to be left unencrypted, encryption is only applied to the data that passes through the teller window onto the public streets.

Other bank owners believe that the security of the hallways inside the bank cannot be trusted. Rogue elements might find a way to penetrate the bank’s security perimeter. These owners believe that all bank-related data, whether it is traveling within the bank or outside of it, must be encrypted.

Security and SAS Viya

A SAS Viya deployment can be configured to protect your data in similar modes. SAS uses Transport Layer Security (TLS) to secure SAS Viya network communications. TLS uses cryptographic techniques to allow servers to validate your data without actually being able to read it.

You can configure SAS Viya to encrypt all network traffic, whether it is confined to the internal cluster network or travels onto the external network. We refer to this configuration as “full-stack TLS”.

In some public cloud platforms, the cloud provider’s infrastructure encrypts all network traffic. On these platforms, it might not be necessary for the SAS servers to encrypt all traffic. For this type of situation, you can configure SAS Viya to encrypt only the network traffic that will travel on the external network: the traffic that travels between the ingress controller and the external clients (usually web browsers). We refer to this type of configuration as “front-door TLS.”

When you configure SAS Viya in front-door TLS mode, the ingress controller is configured to encrypt the network traffic between the ingress and connecting clients, but the traffic between the ingress controller and the back-end servers is not encrypted.

Overview of Certificate Trust

Bank customers are required to provide private data to the tellers. They provide their IDs, passwords, and other private data that is necessary to conduct business with the bank. As a result, they should require assurance that the bank staff is trustworthy.

Here are some reasons why we trust banks in practice:

A customer has access to a list of banks that are judged to be trustworthy by the FDIC (a trusted government regulatory agency).
The customer can see the teller’s employee identification badge.
The customer can validate that the photo on the identification badge matches the teller’s face, and that the name of the bank on the identification badge matches the bank’s name.
The customer can verify that the bank’s name is on the FDIC list of banks that are judged to be trustworthy.

Certificate Trust and SAS Viya

To secure your environment, TLS uses certificates to establish a relationship of trust among all parties that must communicate with each other over the network.

Typically, clients that seek to connect to SAS Viya are web browsers. Each browser must verify that the certificates that are used to secure the SAS Viya front-door servers are trusted. This means these certificates must be issued by a CA certificate in the trust bundle that the browser is configured to use.

When a connection that is secured and encrypted by TLS is established, a “handshake” procedure occurs between two connecting parties. In order to perform the TLS handshake that enables you to connect to SAS Viya from a SAS user interface in a web browser, here’s what has to happen:

Your web browser possesses a list of certificate authorities that are deemed trustworthy.
You enter the web address for a SAS Viya deployment into your web browser (for example, https://myviyadeployment.mymachine.mycompany.com/SASDrive).
The web browser connects to the web server on the specified machine and requests its server identity certificate.
The server sends its server identity certificate to the browser.
The browser validates that the web address in the provided server identity certificate matches the web address specified by you in the URL that you entered.
The browser verifies that the certificate authority (CA) that issued the server identity certificate is in the list of certificate authorities that multiple parties have judged to be trustworthy.
A connection between the web server on your machine and the SAS Viya ingress port is established. You can now start performing tasks with SAS Viya.

SAS Viya provides a certificate generator to generate TLS certificates instantly, whenever pods are scheduled. Two certificate generators are supported. Both certificate generators work with the SAS Security Certificate Framework, which constructs truststores, requests certificate pairs (private keys and signed server identity certificates) from the certificate generator, and makes these certificates available to the SAS Viya services. SAS Viya therefore automates and simplifies most of the process of applying TLS to your deployment.

You also have the following options:

Provide your own CA certificates, including the root CA certificate, which the certificate generator can then use to issue the certificate pairs to all the SAS Viya services.
Allow SAS Viya to generate all certificates, including the root CA certificate that is used by the certificate generator. The certificate generator uses the root CA certificate to issue the server identity certificates that are then used by the back-end SAS Viya services.

Certificate Trust for the Clients

If you configure SAS Viya for either front-door TLS or full-stack TLS, clients are required to use TLS when connecting to SAS Viya from outside the Kubernetes cluster. As described above, “front-door” SAS Viya components accept connections from outside the cluster. These SAS Viya components include the following:

The ingress controller, which routes traffic to SAS Viya web applications, such as SAS Drive and SAS Studio
The CAS server
SAS/CONNECT Spawner

Clients (typically web browsers) that attempt to connect to these servers will verify that the server identity certificates presented by these servers are trusted. To be trusted, the server identity certificates must be issued by a root CA certificate that is in the browser’s trust bundle. If not, the browsers will issue errors to that effect.

If you use a SAS Viya auto-generated ingress certificate, you will see these errors until you configure your client to trust that certificate. This means the root CA certificate for SAS Viya must be accessible to every browser or client that accesses SAS Viya. You must install it on each SAS Viya user’s desktop machine or mobile device.

To avoid these browser trust errors, configure SAS Viya front-end servers to use IT-provided certificates that are included in your organization's CA certificate trust infrastructure.

Default Settings

We’ve discussed several options for securing your SAS Viya deployment with TLS. But it’s important to stress that you can get up and running with TLS applied to your Kubernetes cluster right away, with minimal effort.

By default, the deployment manifest is ready to enable TLS. Required components are included in the SAS Viya kustomization.yaml file to enable full-stack TLS for an NGINX ingress using openssl as the certificate generator. You simply specify the TLS mode to apply (full-stack or front-end) and add a reference to the openssl-generated-ingress-certificate.yaml file to the resources block. Your SAS Viya deployment is secured by TLS as soon as it completes.

Read more about TLS and all the other ways SAS secures your environment in the official deployment documentation.