Custom OpenShift SCCs in SAS Viya: Security by Design

[#1]

Deploying SAS Viya on Red Hat OpenShift brings together two enterprise-grade platforms, each with robust security models. One of the most common questions from SAS customers and OpenShift administrators is: Why does SAS Viya require custom Security Context Constraints (SCCs)? And, crucially, does this requirement conflict with Red Hat’s security best practices?

The short answer: Custom SCCs are compatible with Red Hat’s approach. They are essential for enforcing the principle of least privilege and achieving tighter, more auditable security.

What Are Security Context Constraints (SCC) in OpenShift?

Security Context Constraints (SCCs) are a core OpenShift feature that control the privileges granted to pods. Every pod in OpenShift runs under a service account, and administrators can assign an SCC to a service account, thereby controlling what the pod can and cannot do.

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

OpenShift ships with several predefined SCCs, such as restricted, nonroot, anyuid, hostmount-anyuid,and others. These are designed to cover most use cases, with restricted being the most secure and the default for all pods unless otherwise specified. Importantly, cluster administrators should not modify these default SCCs. Instead, they can define custom SCCs as needed for specific workloads.

Why Does SAS Viya Need SCCs Other Than Restricted?

Most SAS Viya pods (especially stateless microservices) run perfectly well under the default restricted SCC, which denies access to all host features and enforces the highest security. However, some SAS Viya components might require additional runtime privileges to support advanced capabilities, such as:

• Running with a specific user ID (UID)
• Mounting NFS or host path volumes
• Running privileged containers for specialized tasks

These permissions might be required only when the business use cases ask for specific features. In most cases, administrators can assign one of the pre-defined OpenShift SCCs to the service accounts used by the pods that provide these capabilities. As an example, to run SAS Event Stream Processing projects with a user other than "sas", bind the sas-esp-project service account to the standard nonroot OpenShift SCC.

A key factor to consider is that business data needed by SAS users (including traditional SAS datasets) is often file-based and stored on shared storage that sits outside the OCP cluster. In these cases, the established security model is based on POSIX attributes where SAS administrators set permissions on folders and files to protect data access.

To ensure SAS Viya works seamlessly with these existing file-based permission models, it is essential to use SCCs beyond the default restricted. By using the nonroot SCC, SAS compute pods can launch SAS sessions under the user’s own identity, supporting integration with well-established POSIX-based controls. Also consider that, sometimes, the same storage backend might be used by multiple OCP projects: in such cases, using the UID ranges that OpenShift allocates per project would actually be detrimental.

Finally, when pre-defined SCCs do not cover specific services requirements, SAS Viya provides YAML manifests with custom SCC definitions as part of the deployment assets. These custom SCCs grant only the minimum privileges required for each component, following the principle of least privilege. For example, the sas-cas-server SCC is assigned to the service account used by CAS server pods, enabling just the capabilities needed for CAS to function securely. Nothing less, nothing more.

How Are Custom SCCs Applied?

Cluster administrators use the provided YAML manifests to define and bind custom SCCs to the appropriate service accounts, typically before the SAS Viya deployment begins. This process is transparent and can be reviewed by security teams in advance. OpenShift allows SCCs to be bound to service accounts even before those accounts exist, ensuring a smooth deployment workflow.

How Does This Align with Red Hat Best Practices?

Red Hat’s own guidance emphasizes that most workloads should use the restricted SCC, but recognizes that some applications require more. When SAS Viya was initially released on OpenShift, SAS and Red Hat published joint blogs to describe the architecture and deployment options. The security section of SAS Viya on Red Hat OpenShift – Part 2: Security and Storage Considerations states:

“Following Red Hat guidelines, most SAS Viya platform pods are deployed in the restricted SCC, which applies the highest level of security. However, there are a few exceptions... a few custom SCCs are either required by essential SAS Viya platform components, such as the CAS server, or associated with specific SAS offerings that might be included in your software order. All custom SCCs which might be applied to the SAS deployment are shipped as part of the SAS deployment assets collection of files and templates, so there is no need to create them manually.”

This approach ensures that:

• Default SCCs remain untouched, preserving cluster integrity.
• Custom SCCs are tightly scoped to each service account and pod, minimizing risk.
• All permissions are documented and auditable, supporting security reviews and compliance.

Transparency and Documentation

SAS provides detailed documentation listing:

• Which SCCs are required or optional for each component
• The exact capabilities each SCC grants
• How each component uses those permissions
• Alternative options and mitigations for administrators who prefer not to use certain SCCs

This transparency enables OpenShift administrators and security teams to make informed decisions and maintain full control over their cluster’s security posture.

A Practical Example: Securing the SAS Programming Environment with SAS Watchdog

SAS Watchdog is an optional component included in every SAS Viya platform deployment. SAS Watchdog monitors any processes in SAS Compute, SAS Batch or SAS Connect pods, to ensure that they comply with the terms of LOCKDOWN SAS system option. In practice, it prevents any access to files and folders outside of explicitly permitted locations. To enforce these security policies, it integrates with the OS kernel and therefore requires elevated privileges. If you decide to enable SAS Watchdog on OpenShift, the sas-watchdog SCC grants the required elevated privileges to the sas-programming-environment service account, used by SAS Compute, SAS Batch and SAS Connect server pods. Following the principle of least privileges, the SAS Watchdog processes run in a dedicated side-car container, while the main container does not use any elevated privileges.

Conclusion

Custom SCCs in SAS Viya are not a workaround or a security risk. On the contrary, they are a deliberate, auditable, and Red Hat-aligned way to enforce the principle of least privilege. By using custom SCCs, SAS Viya deployments on OpenShift achieve both the flexibility required for advanced analytics and the robust security demanded by modern enterprises.

You can learn more about SAS Viya on Red Hat OpenShift by enrolling in the SAS® Viya®: Deployment on RedHat OpenShift Container Platform course, available on learn.sas.com.

Find more articles from SAS Global Enablement and Learning here.