As organizations modernize their analytics platforms with SAS Viya on Kubernetes, governance and security requirements often raise questions about cluster-scoped permissions. This article explains why SAS Workload Management requires visibility beyond a single namespace to enable intelligent workload scheduling, and what customers should consider when deploying SAS Viya in shared Kubernetes environments.
When reviewing a SAS Viya deployment, platform and security teams frequently ask:
"Why does SAS Workload Management require cluster-level access?"
It's a reasonable question, particularly in large enterprise environments where multiple applications share the same Kubernetes cluster and access is tightly controlled. I touched on this topic in a previous article; here, I focus on it in detail.
SAS Workload Management Is More Than a Scheduler
Kubernetes administrators are familiar with the native Kubernetes scheduler, which places pods on nodes based on available resources and scheduling constraints.
SAS Workload Management extends these capabilities by providing workload-aware orchestration for analytics and compute-intensive environments. It can manage:
- Work queues
- Job prioritization
- Resource governance
- User and group quotas
- Scheduling policies across competing workloads
- Cluster scaling
Rather than evaluating a single pod placement request, SAS Workload Management continuously makes decisions about how analytical workloads should be prioritized and executed across available resources.
In summary, you should view SAS Workload Management as an orchestration and governance layer rather than simply another application running in a namespace.
Cluster Visibility Matters
To make effective scheduling decisions, SAS Workload Management works best with an accurate view of the entire Kubernetes environment in which it operates.
This visibility allows it to:
- Understand available compute capacity
- Identify node characteristics through labels
- Evaluate resource availability across the cluster
- Place workloads on appropriate infrastructure
- Support efficient workload distribution
- Trigger the Cluster Autoscaler when there are no available nodes to start a pending job
Without cluster-wide visibility, workload decisions are made using an incomplete picture of the environment, reducing the effectiveness of the orchestration layer.
Cluster-scoped permissions support intelligent scheduling, enabling capabilities such as:
Node Awareness
Node labels can be used to identify infrastructure characteristics such as hardware types, performance tiers, or specialized capabilities (such as nodes with GPUs).
SAS Workload Management uses this information to help match workloads with suitable execution resources.
Resource Awareness
Effective workload orchestration requires visibility into all available and consumed resources across the environment. This includes resources used by Kubernetes processes and by other pods not directly managed by SAS Workload Orchestrator.
This awareness helps the system make informed decisions about when SAS jobs should run and where they can be placed most efficiently.
Consistent Policy Enforcement
SAS Workload Management governs analytical workloads with centralized policies rather than simple first-come, first-served scheduling.
Cluster visibility helps SAS Workload Management apply those policies consistently across jobs competing for resources, considering workloads from any namespace in the cluster.
Cluster Autoscaling
Another important consideration is autoscaling.
SAS Workload Management can leverage cluster-wide information to support workload-driven scaling decisions and help ensure new cluster nodes are available when demand increases. This capability relies on visibility into the broader Kubernetes environment, making cluster awareness an important factor in overall workload orchestration.
Considerations for Shared Kubernetes Clusters
Many enterprises operate shared Kubernetes platforms that host multiple applications and business services.
These environments typically emphasize:
- Strong tenant and application isolation
- Least-privilege access models
- Centralized cluster administration
- Security and compliance controls
As a result, platform teams may carefully review any solution requesting cluster-scoped access. Understanding the operational benefits of that access helps inform those discussions and enables deployment decisions that balance governance requirements with workload management capabilities.
SAS Workload Management needs read access to:
- Node resources (such as CPU, memory, labels) on all nodes, to place SAS workloads correctly
- SAS jobs across namespaces, to correctly track all workloads
Here is the actual ClusterRole definition:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: sas-workload-orchestrator
labels:
sas.com/admin: cluster-wide
rules:
- apiGroups: [""]
resources: ["nodes", "pods"]
verbs: ["get", "list", "watch"]
SAS Workload management elevated access is for API level visibility, not infrastructure control. It does not modify cluster infrastructure, nodes, system components, or other applications.
SAS Workload management does not require:
- Privileged pod permissions
- Host level access
- Ability to modify nodes
- Ability to modify system DaemonSets
- Ability to modify webhook configurations
- Ability to modify cluster networking
- Ability to modify storage classes or PVs
The Cluster Role and its permissions are bound to SAS Workload Management’s two service accounts; they are not available to users or other services.
Finally, as expected, all direct interactions with Kubernetes APIs are captured in normal Kubernetes audit logs.
Making an Informed Decision
The documentation available in the README files that come with the SAS Viya deployment assets explains in great detail what SAS Workload Management Cluster Roles are for, emphasizing that their usage is strongly recommended. The README files list the functionality that would be lost without these elevated privileges and include specific instructions about additional tasks that must be performed in that case.
If you do not define the recommended Cluster Roles, SAS Workload Management still works, but you’ll lose some of its capabilities. This may lead to administrators having to manually tune or manage nodes; for example, ensuring SAS Viya compute workloads are not impacted by unplanned placement of third-party pods on the same nodes. Or a SAS Administrator might have to manually close/open a host (node) in SAS Environment Manager when that node is cordoned/uncordoned in Kubernetes.
To learn more about SAS Workload Management, including how to configure, administer and use its capabilities, you can visit learn.sas.com and enroll in the course "Architecture and Administration for SAS® Workload Management on SAS® Viya®".
Conclusion
Cluster-scoped permissions are often a focal point during deployment reviews, especially in shared Kubernetes environments. Understanding why SAS Workload Management requires this read-only visibility helps architecture, platform, and security teams make informed decisions.
Consider SAS Workload Management for what it is, an orchestration and governance layer rather than simply another application running in a namespace.
SAS Workload Management uses cluster awareness to deliver intelligent workload orchestration, helping organizations balance resource utilization, workload priorities, and operational efficiency across their SAS Viya deployments.
Find more articles from SAS Global Enablement and Learning here.
