SAS Viya 2020.1 (and later) has a different setup for encryption of data in-motion to previous releases. In this post we will look at some of the differences in technology and present at a high-level the different scenarios that can be configured. In future posts we’ll look at each scenario in turn and examine the configuration in more detail.
SAS Viya 2020.1 (and later) does not include the SAS Secrets Manager. There is no SAS provided software to generate signed certificates and associated private keys. Instead SAS Viya 2020.1 (and later) requires the use of cert-manager, a third-party package, to provide this functionality. The package cert-manager is a X509 certificate management tool for Kubernetes. It is described as:
Automate certificate management in cloud native environments cert-manager builds on top of Kubernetes, introducing certificate authorities and certificates as first-class resource types in the Kubernetes API. This makes it possible to provide 'certificates as a service' to developers working within your Kubernetes cluster.
Paired with cert-manager is the SAS provided SAS-certframe, which is deployed as an init container. Which means that cert-framework runs first inside all the SAS provided pods within Kubernetes. It is the SAS-certframe that is responsible for constructing trust stores, requesting certificate pairs (private keys and signed server identity certificates) from cert-manager, and making these available to the SAS service.
Also, SAS Viya 2020.1 (and later) as with SAS Viya 3.x does not include a HTTP Server. SAS Viya 2020.1 (and higher) requires a third-party Ingress Controller, i.e. nginx. The Ingress Controller provides the external HTTP access into the Kubernetes cluster. So, when an end-user accesses a SAS web application, they do this via the Ingress Controller. Thus, the Ingress Controller is the main "front-door" into the SAS Viya environment. There are other access points we will discuss later, but initially we will focus on the Ingress Controller. Now that we’ve reviewed the changes in technology, we will look at the supported scenarios for customers to enable TLS for encryption in-motion.
Scenario 1: Front door HTTPS with customer provided certificate
This is probably the most common scenario. The customer wants to access the SAS Viya web applications over HTTPS and they have their own private key and signed server identity certificate that they want to use on this connection. This certificate is probably signed by an external commercial Certificate Authority (CA) and will be trusted in most browsers.
This scenario does not require cert-manager.
Scenario 2: Front door HTTPS with customer provider certificate and internal TLS using a customer provided CA
Another common scenario extending the previous scenario to now include TLS on the services within the Kubernetes cluster. Customers will need to appreciate that nothing is free, and there will be a performance impact of using TLS on all the internal connections. This needs to be balanced with the network security already implemented by the Kubernetes provider such as Azure.
Unlike SAS Viya 3.x where the internal TLS used the SAS Secrets Manager CA certificate to sign the internal certificates now customers can use their own CA certificate. This provides additional flexibility for customers to decide on what CA certificate is used to sign the internal certificates.
Remember both the private key and associated issuing CA certificate or Intermediate will be required. These will be provided to cert-manager, and cert-manager will issue the certificate pairs (private key and signed server identity certificate) to all the SAS services.
Scenario 3: TLS everywhere using a customer provided CA
A less common scenario will be to just use a customer provided CA certificate. The customer will provide a private key and associated issuing CA certificate or Intermediate certificate, and this will be used to generate the signed server identity certificates for both the Ingress Controller and all the internal SAS services. Customers will need to ensure the CA certificate is trusted by their end-user’s browsers to prevent them displaying errors. This provides a simple mechanism to provide site-signed certificates for all services which might be useful for development or testing environments.
This scenario relies on cert-manager to issue certificate pairs (private key and signed server identity certificate) to all services including the Ingress Controller.
Scenario 4: Front door HTTPS with customer provided CA
Finally, the last scenario is where the customer provides a issuing CA certificate (and associated private key) to sign just the Ingress Controller certificate. The Ingress Controller certificate will be generated by cert-manager, and again the customer will need to ensure the end-user’s browsers trust the CA certificate. This could be a useful scenario for development or testing environments where only a limited number of end-users will be accessing the Ingress Controller.
The private key and the associated issuing CA certificate or Intermediate certificate will need to be provided to cert-manager for it to generate the Ingress Controller private key and signed server identity certificate.
What CA certificate
In the above scenarios we have talked about the different Certificate Authority (CA) certificates. The act of signing a certificate request (CSR) takes information from the request and encrypts that information with a private key. Only the corresponding public key can be used to decrypt that signature information.
The purpose of signing a certificate is to provide proof of who that certificate is provided to. The signature of a certificate has no impact on the actual encryption of the network traffic. But if you want to be sure you are really connecting to the service you want to connect to you look at the signature. For example if you browse to https://your.bank.com you want to be sure it is really your bank you are connecting to and not some scammer. So, your browser looks at the signature of the certificate and decides if it has been signed by someone it trusts. Commercial Certificate Authorities spend a lot of time and money getting trusted by your browser. They can then charge your bank to provide a certificate that will be trusted by your browser. Those Commercial Certificate Authorities will carefully vet the request to ensure they are only providing that certificate to your bank.
So, if you want to offer a HTTPS website to a wide range of users you will want to use a commercial CA, so it is trusted in a wide range of browsers. While if you are only offering the site to users inside your organization you might forego the cost of an external CA and use a CA internal to your organization. This decision is normally based around the control you have of the trust store for the browser. Inside your organization you have control of the trust store, while outside your organization you do not.
The cert-manager tool will require both the private key and issuing CA or Intermediate certificate to be able to automatically generate an identity certificate pair (private key and signed certificate). The private key is just that – something that must be kept safe and secure. Since with the private key a scammer could sign their own certificates and pretend to be someone else. The most common scenario is to generate a specific CA private key and self-signed certificate for use with cert-manager. The CA self-signed certificate can then be distributed to the end-users as necessary.
Issuers for cert-manager
The cert-manager package supports the following issuer types:
- SelfSigned
- CA
- Vault
- Venafi
- External
- ACME
The SelfSigned issuer doesn’t represent a certificate authority as such, but instead denotes that certificates will be signed through "self signing" using the given private key. This means that the provided private key of the resulting certificate will be used to sign its own certificate.
The CA issuer represents a Certificate Authority whereby its certificate and private key are stored inside the cluster as a Kubernetes Secret, and will be used to sign incoming certificate requests. This internal CA certificate can then be used to trust resulting signed certificates.
The Vault issuer represents the certificate authority Vault - a multi-purpose secret store that can be used to sign certificates for your Public Key Infrastructure (PKI).
The Venafi issuer types allows you to obtain certificates from Venafi Cloud and Venafi Trust Protection Platform instances.
The External issuer types are issuers that are not support by cert-manager by default, or are ‘out of tree’, however are treated the exact same as any other internal Issuer type.
The ACME issuer type represents a single account registered with the Automated Certificate Management Environment (ACME) Certificate Authority server. When you create a new ACME Issuer, cert-manager will generate a private key which is used to identify you with the ACME server.
Scenarios 2 & 3 would use the CA issuer type, but since certificates are required for all SAS services these scenarios do not apply to the Venafi or ACME issuer types. Scenario 4 could be changed by leveraging either the Venafi or ACME issuer types rather than the CA issuer; then the certificate for the Ingress Controller would be automatically generated by this third-party, such as Let’s Encrypt.
Additional Thoughts
For the scenarios where cert-manager is generating the certificate pairs (private keys and identity certificates) for all the SAS services within the Kubernetes cluster, there could be delays. When each SAS pod starts the SAS-certframe will request the certificate pairs from cert-manager. SAS-certframe will then wait until the certificate pair is created and the certificate is marked as valid. Only then, will SAS-certframe make the certificate pair available to the SAS service and complete. The SAS service container will only start after the SAS-certframe has completed. Obviously, if over one hundred SAS pods are starting at the same time, there could be some delay in all the certificate pairs being generated.
Other Access Points
So far, we have only focused on the Ingress Controller being the entry point into the SAS Viya environment. However, we have two other possible entry points; SAS Cloud Analytic Services and SAS/CONNECT Spawner. As well as clients within the Kubernetes cluster connecting to these two services customers might have external clients that need to connect securely.
For SAS Cloud Analytic Services there are the binary CASL connections and HTTP Rest connections, while for SAS/CONNECT there is just the TCP/IP connection. The CAS HTTP Rest connection will go via the Ingress Controller and so is covered in the scenarios outlined above.
For the binary CASL connection and SAS/CONNECT the method will vary depending on if the Kubernetes cluster has an automated load balancer. If the load balancer is available connections will be via this load balancer, otherwise connections are directly to the nodes of the Kubernetes cluster on a defined NodePort.
For both cases customers will be able to provide a private key and signed certificate. The complexity and differences are in the required Subject Alternative Names (SAN) that will be needed on the signed certificate. Alternatively, customers can rely on cert-manager to issue the certificate pairs (private key and signed server identity certificate) using the defined issuer.
Stuart Rogers
