This blog forms a part of a series looking at the encryption of data in-motion with SAS Viya (Version 2020.1 and later). In the last article, we discussed the different options customers have for customizing the configuration of TLS. In this post we will examine the default setup – only once we understand the default setup can we move onto further customizations.
We will start by looking at pre-requisites; the documentation currently states:
Install cert-manager version 1.0 or later before you start the deployment
This provides the lowest level of cert-manager that is required, version 1.0. Customers should be using version 1 or higher. The current release, at the time of writing, is version 1.0.3 which was released on 8th October 2020. Version 1.0.0 of cert-manager was released on 2nd September 2020. SAS Viya is tested on numerous releases of cert-manager from 0.11 up to and including the current production release. It should be noted that in this testing an issue has been found with cert-manager version 0.12 and this release should be avoided.
Note: cert-manager will be required inside the same Kubernetes cluster as SAS Viya. Therefore, if the customer is building a new Kubernetes just for SAS Viya, they will have to make sure to include cert-manager. If instead, the customer intends to re-use an existing cluster, it’s likely that they will already have cert-manager. At this point, it’s important to confirm they have a compatible version, or can upgrade cert-manager. Running multiple versions of cert-manager in a single Kubernetes cluster is not recommended.
What is meant by secured by default?
SAS Viya 2020.1 (and higher) unlike previous releases of SAS does not ship to customers the deployment definition. Customers download the deployment assets for their chosen cadence and version, and then following the documentation generate their own initial kustomization.yaml file. The kustomization.yaml file is where customers customize their Kubernetes deployment and allocate resources. So, it is in this kustomization.yaml file that we define the resources that will deliver a secure by default deployment of SAS Viya 2020.1 (and higher).
The initial copy of the kustomization.yaml provided in the documentation has the following TLS specific entries to provide Full-stack TLS by default:
- Under resources:
- sas-bases/overlays/cert-manager-issuer
- sas-bases/overlays/network/ingress/security
- Under transformers:
- sas-bases/overlays/network/ingress/security/transformers/product-tls-transformers.yaml
- sas-bases/overlays/network/ingress/security/transformers/ingress-tls-transformers.yaml
- sas-bases/overlays/network/ingress/security/transformers/backend-tls-transformers.yaml
- site-config/security/cert-manager-provided-ingress-certificate.yaml
Full-stack TLS means that all services will be configured to use TLS. Which in turn means that every service will require a certificate pair (private key and signed server identity certificate). Full-stack TLS includes the external entry points to SAS Viya as well as encrypting all network traffic between back-end services inside the Kubernetes cluster.
Only one of the files is customized for the customer’s specific environment. The cert-manager-provided-ingress-certificate.yaml file is located in the site-config directory. The documentation covers this customization. A provided example cert-manager-provided-ingress-certificate.yaml file should be copied to the created site-config/security directory and then edited. Within the file {{ CERT-MANAGER_ISSUER_NAME }} should be replaced with the name of the cert-manager issuer that will issue certificates for the nginx Ingress Controller. For example, sas-viya-issuer. If sas-viya-issuer is used, the same cert-manager issuer will be used for both the nginx Ingress Controller and all the SAS Viya services.
Details of Default Settings
Now let’s look in more detail at the default configuration. First the line sas-bases/overlays/cert-manager-issuer includes a directory into the kustomize. Within this directory is a single resources.yaml, with the following content:
---
# sas-viya-selfsigning-issuer.yaml
# ................................
apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
name: sas-viya-selfsigning-issuer
spec:
selfSigned: {}
---
# sas-viya-ca-certificate.yaml
# ............................
apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
name: sas-viya-ca-certificate
spec:
secretName: sas-viya-ca-certificate-secret
commonName: "sas-viya-root-ca-certificate"
duration: 43800h # 5 years
renewBefore: 1h # 1 hour
isCA: true
issuerRef:
name: sas-viya-selfsigning-issuer
kind: Issuer
---
# sas-viya-issuer.yaml
# ....................
apiVersion: cert-manager.io/v1alpha2
kind: Issuer
metadata:
name: sas-viya-issuer
spec:
ca:
secretName: sas-viya-ca-certificate-secret
This will define the following:
- A cert-manager self-signing issuer called sas-viya-selfsigning-issuer.
- Use the sas-viya-selfsigning-issuer to create a root CA certificate pair (private key and signed certificate) valid for 5 years and stored in the Kubernetes secret called sas-viya-ca-certificate-secret.
- A cert-manager CA issuer called sas-viya-issuer, that uses the CA created above to sign server identity certificates.
This sets up the TLS infrastructure for the SAS Viya environment; it provides the cert-manager issuer that will be used through-out the environment and a self-signed CA certificate to sign the issued certificate pairs (private key and signed server identity certificate). This means that each SAS Viya environment that is deployed will have its own root CA certificate specific to only that environment.
The second entry under resources, sas-bases/overlays/network/ingress/security, is responsible for setting up all the required resources for the SAS Security Certificate Framework. In the form of several Kubernetes Config Maps. The Kubernetes Config Maps provide required environment variables into both the service containers and the sas-certframe init container.
The three transformers files; for product-tls, ingress-tls, and backend-tls setup the SAS Viya services for TLS. The product-tls-transformers.yaml configures the readiness probes for each service to use HTTPS. The ingress-tls-transformers.yaml configures the ingress definitions for each service for TLS. The backend-tls-transformers.yaml configures each service to use TLS for service to service network communication and includes the sas-certframe init container.
The Results
Deploying with the recommended kustomization.yaml and setting the Ingress Controller cert-manager issuer to sas-viya-issuer will result in all network communication using TLS. All certificate pairs (private key and signed server identity certificate) for both the nginx Ingress Controller and all SAS Viya services will be signed by the automatically generated self-signed Certificate Authority.
However, since the CA certificate is generated within the SAS Viya environment it will not be trusted by anything outside the environment. So long as you have a Kubernetes identity that has roles that allow access to secrets the following command can be used to extract the CA certificate:
kubectl -n ${NS} get secret sas-viya-ca-certificate-secret -o jsonpath="{.data['ca\.crt']}" | base64 --decode > ca_cert.pem
Where ${NS} is your SAS Viya namespace. The resulting ca_cert.pem can then be added to the trust store of any client connecting to the SAS Viya environment. For example, for Google Chrome on a Windows host this would be the Windows trust store.
Deployment implication
In this scenario (Full-stack TLS, provided by cert-manger), all the communications will be encrypted via cert-manager issued certificates.
The advantages of this approach:
- All communications are encrypted
- No reliance on customer providing anything else other than a working cert-manager
The disadvantages of this approach:
- While the self-signed CA certificate is acceptable for the network traffic within the Kubernetes cluster, it adds complexity for external connections. For example, unless the CA certificate is extracted and then imported into every client browser the browser will prompt the end-user that their "connection is not private" (NET::ERR_CERT_AUTHORITY_INVALID).
For that reason, in a future blog, we will explore the option of Full-stack TLS with Customer-provided certificates for the nginx Ingress Controller.
Customizations
Now that we understand the default configuration in future blog posts we can look at exploring the different customizations that are required to enable the scenarios we discussed before.
Note: This article addresses features of SAS Viya 2020.1 (and later).
