Multi-Tenancy in K8s & OpenShift #6 - Pod Security Standards (PSS)

In previous blogs, we’ve covered Namespace-Based Isolation for workload separation, Network Policies for secure communication, Role-Based Access Control (RBAC) for permissions management, and Resource Quotas and LimitRanges for fair resource allocation across tenants in a multi-tenant Kubernetes cluster.

In Kubernetes, Pod Security Standards (PSS) are a set of policies designed to enforce security best practices at the pod level. In a multi-tenant environment, where tenants share the same cluster, it’s essential to control what kind of workloads they can deploy. PSS helps enforce workload security by restricting the privileges and capabilities that tenants can assign to their pods, reducing the risk of malicious or misconfigured containers affecting other tenants.

Multi-Tenancy in Kubernetes & Openshift: A Comprehensive Guide

Part 1: Use Cases & Implementations

Part 2: Namespace-Based Isolation for Workload Separation

Part 3: Network Policies for Network Isolation

Part 4: Role-Based Access Control (RBAC) for Authorization

Part 5: Resource Quotas and LimitRanges for Resource Control

Part 6: Pod Security Standards (PSS) for Workload Security

Part 7: Storage Isolation for Persistent Volume Security

Part 8: Ingress Control Isolation for External Access Segregation

Part 9: Control Plane Robustness to Safeguard shared Kubernetes Resources

Part 10: NodePort and HostPort Restrictions for Enhanced Network Security

Part 11: Resource and Cost Tracking for ShowBack/ChargeBack

Part 12: Multi-Tenant Considerations for Shared Tools

Pod Security Standards (PSS) for Workload Security

What Are Pod Security Standards?

Pod Security Standards define three levels of security profiles for workloads in Kubernetes:

• Privileged: Allows unrestricted pod configurations, including running as root and accessing host resources. This level is rarely recommended for multi-tenant environments.

• Baseline: Provides a moderate security profile that disallows certain risky configurations, such as privileged containers, while allowing common usage scenarios.

• Restricted: The most secure level, enforcing stricter policies, such as preventing root users, controlling filesystem access, and restricting host networking.

These standards are implemented using Pod Security Admission (PSA), which replaces Pod Security Policies (PSP) in recent Kubernetes versions. By configuring PSS, we can enforce pod-level security that aligns with the needs of our multi-tenant environment.

Why Use Pod Security Standards in Multi-Tenancy?

In multi-tenant Kubernetes clusters, each tenant might run a variety of applications, but without proper security controls, tenants could:

• Gain elevated privileges: Allowing privileged pods could let tenants escalate permissions, potentially accessing other tenants’ resources or the underlying nodes.

• Compromise cluster security: Misconfigured or insecure pods might introduce vulnerabilities that attackers can exploit to compromise the cluster.

• Affect other tenants’ workloads: Tenants might inadvertently run pods with configurations that impact the stability of the cluster or interfere with other tenants' workloads.

By using Pod Security Standards, we can enforce workload security policies that prevent such scenarios, ensuring a secure and stable environment for all tenants.

How Pod Security Standards Work

Pod Security Standards are applied at the namespace level using Pod Security Admission. We can define security levels for each namespace according to the needs and trust level of its tenants. For example, in a multi-tenant environment, we might enforce the Restricted level for most tenants and allow Baseline only for those with special requirements.

Use Cases for Pod Security Standards in Multi-Tenancy

• Enforcing Non-Privileged Containers: By default, pods aren’t allowed to run as privileged containers. This prevents tenants from inadvertently accessing the host or other sensitive resources.

• Controlling Root Access: The Restricted policy prevents containers from running as the root user, reducing the risk of privilege escalation and ensuring tenants deploy applications with least privilege.

• Restricting Host Network Access: For most tenants, we want to disallow access to the host network, which could lead to security risks. PSS policies block host network access, enforcing pod isolation.

• Limiting Access to Sensitive Filesystems: Policies under PSS restrict access to certain volume types, like the host filesystem, ensuring tenants can only access the files and directories that their applications need.

Best Practices for Pod Security Standards in Multi-Tenancy

• Use the Restricted Profile by Default: Unless there’s a specific need for looser controls, we start with the Restricted profile, which enforces the most secure set of policies. This ensures tenants adhere to security best practices.

• Define Different Profiles for Different Tenants: For example, if certain tenants need elevated privileges to run specific applications, we can assign them the Baseline profile while still enforcing Restricted for others.

• Enable Auditing for Sensitive Policies: Using the audit label along with enforce helps us track attempts to deploy pods that violate stricter policies. This is useful for detecting tenants who may need additional guidance on security best practices.

• Regularly Review and Adjust Policies: As tenants’ requirements evolve, we adjust the policies accordingly. Regular audits and reviews ensure the security standards remain aligned with the security posture of the cluster.

Conclusion

Pod Security Standards (PSS) are crucial for maintaining workload security in a multi-tenant Kubernetes environment. By defining and enforcing appropriate security policies, we can ensure that tenants deploy only secure, non-privileged workloads that can't interfere with other tenants or the underlying cluster infrastructure. PSS provides a robust framework for enforcing least privilege, ensuring a secure and compliant multi-tenant Kubernetes environment.

Simplifying Multi-Tenancy with Stakater Multi-Tenant Operator

Implementing multi-tenancy in Kubernetes can be quite intricate. It demands extensive knowledge of Kubernetes and involves configuring aspects like namespace isolation, network policies, RBAC, and resource quotas. Getting it right requires considerable time and effort to guarantee security and effective resource management. This is where the Stakater Multi-Tenant Operator (MTO) excels.

The Stakater Multi-Tenant Operator is designed to streamline and expedite the implementation of multi-tenancy in Kubernetes clusters. It offers a comprehensive, automated framework for tenant management, allowing organizations to quickly and efficiently establish secure, isolated, and well-managed environments.

When applied in conjunction with Pod Security Standards (PSS), the MTO enhances workload security by enforcing strict policies that prevent tenants from inadvertently compromising the cluster's integrity. By using PSS, organizations can enforce security measures at the namespace level, ensuring that each tenant operates within defined security profiles—Privileged, Baseline, and Restricted—tailored to their specific needs and trust levels.

This collaborative approach to multi-tenancy not only simplifies management but also reinforces security, allowing tenants to run their applications confidently while minimizing risks to the overall Kubernetes environment. In the next blog, we’ll dive into Storage Isolation for Persistent Volume Security, focusing on how to secure persistent storage in multi-tenant environments and prevent unauthorized access to shared data resources.