The Stable release of SAS Viya 2021.1.4 introduces a new certificate generator to SAS Viya. A certificate generator is required unless you deploy in no TLS mode. The new certificate generator is supported alongside the default certificate generator of cert-manager. The new certificate generator is based on OpenSSL and is provided by SAS. This eliminates the need for the cert-manager third-party software prerequisite. The provision of a second certificate generator gives customers more choice in the setup of their SAS Viya environment. In this blog we will look the requirements of the OpenSSL certificate generator and how it can be used.
What is a certificate generator? A Certificate Generator is a software application, hardware device or system that creates the certificate and key pairs (the Kubernetes secrets) used to secure network connections.
Remember with the cert-manager certificate generator customers must deploy this third-party software into their Kubernetes cluster. The deployment of cert-manager requires some additional security settings in terms of Role-Based-Access-Controls that some customers do not want to grant on their Kubernetes clusters. Equally, customers will need to monitor and update cert-manager on a regular basis. This means, that if the customer is not already using cert-manager, these requirements could be a blocker to deploying SAS Viya.
As such, with SAS Viya 2021.1.4, SAS now provides the OpenSSL certificate generator. The OpenSSL certificate generator is proprietary SAS software that utilizes the OpenSSL open-source project . The OpenSSL certificate generator creates a unique CA certificate and private key during SAS Viya deployment. To use the Openssl certificate generator, you must:
This means the OpenSSL certificate generator can be used for the following scenarios:
To be able to leverage the OpenSSL certificate generator you make changes to your kustomization.yaml file. From the initial kustomization.yaml file in the documentation you must:
generators: - site-config/security/customer-provided-ingress-certificate.yaml - site-config/security/customer-provided-merge-sas-certframe-configmap.yaml
Where the customer-provided-ingress-certificate.yaml file provides your Ingress controller certificate pair (signed server identity certificate and associated private key). Then the customer-provided-merge-sas-certframe-configmap.yaml file contains the following:
--- apiVersion: builtin kind: ConfigMapGenerator metadata: name: sas-certframe-user-config behavior: merge literals: - SAS_CERTIFICATE_GENERATOR=openssl
The customer-provided-merge-sas-certframe-configmap.yaml file may also contain literals for the certificate duration, additional Subject Alternative Names (SAN) DNS and SAN IP values.
If you use the rest of the initial kustomization.yaml file contents from the documentation, your SAS Viya environment will be configured for Full-Stack TLS. If instead you only want to configure Front-Door TLS, you would alter the content in the components section.
Also, remember if you use the initial kustomization.yaml file contents from the documentation you will have configured your environment to use the cert-manager certificate generator.
When you apply the site.yaml built from this kustomization.yaml you will have configured the OpenSSL certificate generator. This changes the behaviour of the SAS Certificate Framework init container. Instead of requesting the certificates from cert-manager, the init container will use the SAS provided OpenSSL to generate the certificates. But first a Certificate Authority (CA) private key and self-signed certificate must be generated.
Every instance of the SAS Certificate Framework init container will check for the existence of the sas-viya-ca-certificate-secret. If this Kubernetes secret does not exist in the namespace then all of the running init containers will attempt to auto-generate the Certificate Authority (CA) private key and CA certificate using OpenSSL. The private key will be a 2048-bit RSA private key. The CA certificate will have a 5 year lifetime, the CA:TRUE flag will be set, and the signature algorithm will be sha256WithRSAEncryption. Once the SAS Certificate Framework init container generates these, they will be written to the Kubernetes secret sas-viya-ca-certificate-secret. The first init container to write the sas-viya-ca-certificate-secret secret wins the race. Other instances of the init container will find that the secret has now been written and so restart.
When the SAS Certificate Framework init container finds content in the sas-viya-ca-certificate-secret secret, the private key and CA certificate are loaded into the init container. The CA certificate is added to the trust stores that will be presented to the service by the init container as either /security/trustedcerts.pem or /security/trustedcerts.jks. The init container then uses OpenSSL to generate the private key for the service and the associated server identity certificate which is signed with the CA private key. The service private key and signed server identity certificate are stored in a Kubernetes secret and made available to the service as /security/tls.crt and /security/tls.key.
The use of the OpenSSL certificate generator should not be any slower than the cert-manager certificate generator. In fact, depending on the resources allocated to cert-manager, the OpenSSL certificate generator could be faster. In the environments I use for workshops, looking at the SAS Certificate Framework init container logging for the sas-consul-server-0 pod we can see the following:
The additional time for the cert-manager issuer could be down to network traffic within the cluster as all the services request certificate pairs and the workload of generating the certificate pairs.
As we have described the OpenSSL certificate generator first looks at the Kubernetes secret sas-viya-ca-certificate-secret. If this secret already exists it will just automatically be used to sign the individual service server identity certificates. Therefore, it would be possible to pre-load this Kubernetes secret with a private key and CA certificate. This could be a root CA or a signing Intermediate CA. This would allow for the same CA private key and certificate to be used in multiple SAS Viya environments. This would simplify the trust store setup for third-party programming clients connecting to SAS Cloud Analytic Services in these SAS Viya environments.
With SAS Viya STABLE 2021.1.4, and with the next LTS 2021.2, customers have a choice of certificate generator. Customers who already have invested time and effort into deploying cert-manager and perhaps want to use the cert-manager external issuers for their Ingress controller certificates can still leverage the cert-manager certificate generator. For other customers that have issues with some of the requirements for cert-manager or just want a simpler deployment experience, they can now leverage the OpenSSL certificate generator.
We have shown what is required in the kustomization.yaml to configure the OpenSSL certificate generator. We have also discussed the different processing that occurs with the SAS Certificate Framework init container when using the OpenSSL certificate generator. Hopefully, this provides some useful additional information to help you choose the certificate generator that will work best for your environments.
Find more articles from SAS Global Enablement and Learning here.
Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.
If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.