Troubleshooting HTTPS Certificate Issues in SAS Viya: Kubernetes objects involved in SSL

In the previous post, we covered the SSL Process within a SAS Viya environment, focusing on how encrypted communication flows between the client, Ingress controller, and backend services. Now, we’ll take a closer look at the key Kubernetes objects that play a critical role in managing SSL/TLS encryption within the cluster.

In this post, we will explore certificates, certificate authorities (CA), and ConfigMaps, three essential components that ensure secure communication in a Kubernetes environment. Understanding how these objects interact with one another is crucial for maintaining the security and integrity of your SAS Viya platform. By the end of this post, you’ll have a solid grasp of how Kubernetes handles SSL configurations and the role each object plays in the process.

Note: The $viya environment variable is used on kubectl commands that require the --namespace flag. Make sure that the environment variable is created before you use these kubectl commands.

Certificate and Certificate Authority (CA) Kubernetes objects involved

Here is, as a reminder, the diagram I used in the previous post :

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

1. Ingress Controller SSL Termination

Certificate location: The SSL certificate used by the Ingress controller for terminating HTTPS requests is typically stored in a secure location, such as Kubernetes secrets or mounted volumes. If the certificate is provided manually, it may come from a trusted CA, or services like Let's Encrypt can automate certificate generation and renewal.

In SAS Viya, here are some commands you can run to determine the Kubernetes objects involved in the Ingress Controller SSL Termination process.

This is how you would determine the TLS mode for your deployment:

TLS_MODE=$(kubectl -n $viya get ing sas-logon-app -o=jsonpath='{.metadata.annotations.sas\.com/tls-mode }')
echo Your SAS Viya deployment run in \"$TLS_MODE\" mode

If you are using one of the TLS modes (Front-Door or Full-Stack), then this is how you would determine the Kubernetes secret object that holds your Ingress certificate:

# Get the secret name
INGRESS_CRT=$(kubectl -n $viya get ing sas-logon-app -o jsonpath='{.spec.tls[*].secretName}')
echo Your SAS Viya deployment use \"$INGRESS_CRT\" secret to hold the Ingress certificate

If the secret name holding your Ingress certificate has random number at the end (i.e. sas-ingress-certificate-xxxxxxxxxx) then your certificate might have been provided by your IT department.

If not, here is how to determine what “Certificate Generator” has been used to generate your ingress certificate:

# Determine the configmap that holds the configuration
CM_CERT_USER=$(kubectl -n $viya get cm -o NAME | grep sas-certframe-user-config)
CERT_GEN=$(kubectl get $CM_CERT_USER -n $viya -o jsonpath='{.data.SAS_CERTIFICATE_GENERATOR}')
echo Your SAS Viya deployment used \"$CERT_GEN\" to generate your Ingress certificate

CA involvement: The client (e.g., a web browser) uses the CA's root certificate to validate the authenticity of the SSL certificate provided by the Ingress controller during SSL termination.

In most case, the CA used to issue the Ingress certificate need not be stored on your Kubernetes cluster. It only needs to be known by the client (e.g. your web browser).

If you were using the SAS OpenSSL Certificate generator to generate your Ingress certificate, the CA root certificate is hold by the Kubernetes secret called sas-viya-ca-certificate-secret.

If you were using Cert-Manager, the CA root certificate has been defined in the Issuer configuration for Cert-Manager.

Note: In case you want to use an existing CA to issue your Ingress certificate, you can overwrite the sas-viya-ca-certificate-secret secret by providing the Certificate and the associated Private Key. This CA will then be used to issue your Ingress Certificate.

2. SSL Passthrough or Re-encryption (Full-Stack TLS)

Certificate location (if re-encryption is used): If the Ingress controller is configured to perform SSL passthrough or re-encryption, another SSL certificate may be required on the backend services to handle encrypted traffic. This certificate would typically be stored with the backend service or its Kubernetes configuration, such as secrets.

In SAS Viya, if you are using full-stack mode, you can determine what object (here a Kubernetes secret) represent your service pod certificate running the following commands.

In this example we will look specifically at the sas-logon-app certificate:

LOGON_SECRET=$(kubectl -n $viya get pods -l app=sas-logon-app -o jsonpath='{.items[0].metadata.name}')
kubectl -n $viya describe secret $LOGON_SECRET

You should get something similar as output:

Name:         sas-logon-app-5579fdc5bf-bhb96
Namespace:    gelenv
Labels:       
Annotations:  

Type:  kubernetes.io/tls

Data
====
ca.crt:   1147 bytes
tls.crt:  1432 bytes
tls.key:  1704 bytes

CA involvement: If SSL re-encryption is used, the backend service's certificate may also be validated by the client using a CA chain.

In SAS Viya, you can determine what object (here a Kubernetes secret) represent your Certificate Authority used to issue the pod certificates running the following commands:

# Determine the configmap that holds the configuration
CM_CERT_USER=$(kubectl -n $viya get cm -o NAME | grep sas-certframe-user-config)
CERT_GEN=$(kubectl get $CM_CERT_USER -n $viya -o jsonpath='{.data.SAS_CA_CERTIFICATE_SECRET_NAME}')
echo Your SAS Viya deployment used \"$CERT_GEN\" to generate your Service certificate

Out-of-the-box the secret for both Cert-Manager and SAS OpenSSL Generator will be named sas-viya-ca-certificate.

3. Ingress Controller to Client (SSL):

Certificate location: The Ingress controller encrypts the response back to the client using the same SSL certificate mentioned in the SSL termination step. This certificate must still be valid and trusted by the client’s system, validated using a trusted CA.

Main other Kubernetes objects involved

In your SAS Viya environment, the sas-certframe-user-config and sas-certframe-ingress-certificate-config are Kubernetes ConfigMaps related to SSL and certificate management.

The sas-certframe-user-config contains custom user-specific certificate and key information, allowing administrators to override default certificate configurations for internal communication between services. This configuration can include certificates for non-default domain names or different CA authorities.

Here is the list of properties that can be customized:

SAS_CERTIFICATE_GENERATOR
SAS_CERTIFICATE_DURATION
SAS_CERTIFICATE_ADDITIONAL_SAN_DNS
SAS_CERTIFICATE_ADDITIONAL_SAN_IP
EXCLUDE_MOZILLA_CERTS

More information on these properties can be found on SAS® Help Center - Configure Certificate Attributes.

On the other hand, the sas-certframe-ingress-certificate-config is responsible for managing certificates used by the ingress controller to handle external HTTPS traffic to the SAS Viya services.

It stores the necessary secret name that will contains SSL certificates and private keys to ensure secure communication from external users to the platform.

Conclusion

In this post, we explored the critical role of certificates, certificate authorities (CA), and ConfigMaps in securing communication within a SAS Viya environment on Kubernetes. By understanding how these objects work together, whether managing SSL termination at the Ingress controller or handling re-encryption in a full-stack TLS setup, you can better manage and troubleshoot SSL configurations for your platform. Whether you're using certificates generated by Cert-Manager, SAS OpenSSL, or a customer-provided CA, knowing where these objects reside and how they are configured is key to maintaining secure communications.

Stay tuned for the next post, where we’ll dive into a common and often challenging issue: Expired Certificates and how to address them in your SAS Viya environment.

For a deeper understanding, I highly recommend the comprehensive 'Advanced Topics in Encryption on SAS Viya' training. This course provides a thorough exploration of encryption, covering everything from core concepts to advanced techniques. It also includes hands-on exercises and an associated lab environment, allowing you to apply what you've learned in real-world scenarios and further strengthen your knowledge of secure communication within SAS Viya.

Be sure to check out the complete series on Troubleshooting HTTPS Certificate Issues for your SAS Viya platform to guide you through various common challenges and their resolutions.

Find more articles from SAS Global Enablement and Learning here.