How to Enforce Kubernetes Pod Security Standards in a Multi-Tenant Cluster Using Capsule and OPA

Introduction

Kubernetes security is a critical concern, especially in multi-tenant clusters where multiple teams or applications share the same infrastructure. Organizations need to ensure that workloads running on Kubernetes adhere to security best practices. Pod Security Standards (PSS) help define policies to restrict risky configurations, such as running privileged containers. Capsule enables multi-tenancy in Kubernetes by providing logical isolation of namespaces and enforcing governance policies per tenant. Open Policy Agent (OPA), particularly its Kubernetes-native implementation Gatekeeper, allows administrators to define and enforce security policies declaratively.

In this blog, we will explore how to enforce Kubernetes Pod Security Standards (PSS) using Capsule and OPA to secure multi-tenant environments.

---

Why Use Capsule and OPA for Multi-Tenant Security?

Capsule for Multi-Tenancy

• Provides namespace isolation between tenants.
• Allows defining security policies at the tenant level.
• Restricts resource consumption per tenant.

OPA (Gatekeeper) for Policy Enforcement

• Ensures compliance with Pod Security Standards.
• Rejects insecure pod configurations before deployment.
• Centralized management of security policies.

By integrating Capsule and OPA, we can enforce fine-grained security policies per tenant, ensuring safe workload execution.

---

Step 1: Install Capsule and OPA (Gatekeeper)

Install Capsule

helm repo add clastix https://clastix.github.io/charts
helm repo update
helm install capsule clastix/capsule

Verify that Capsule is running:

kubectl get pods -n capsule-system

Install OPA Gatekeeper

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm repo update
helm install gatekeeper gatekeeper/gatekeeper

Check if Gatekeeper is running:

kubectl get pods -n gatekeeper-system

---

Step 2: Define a Capsule Tenant with Security Constraints

Let’s create a Capsule Tenant with enforced pod security policies.

apiVersion: capsule.clastix.io/v1beta1
kind: Tenant
metadata:
  name: secure-team
spec:
  owner:
    kind: User
    name: secure-user
  namespaceOptions:
    quota:
      hard:
        pods: "10"
    additionalMetadata:
      annotations:
        "security.enforce": "true"

Apply the tenant configuration:

kubectl apply -f tenant.yaml

This tenant will have a security enforcement annotation, which we will use in our OPA policies.

---

Step 3: Enforce Kubernetes Pod Security Standards with OPA

Create a Policy to Restrict Privileged Containers

To prevent pods from running as privileged, create a ConstraintTemplate in Gatekeeper.

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8spssrestricted
spec:
  crd:
    spec:
      names:
        kind: K8sPSSRestricted
      validation:
        openAPIV3Schema:
          type: object
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package security

        violation[{
            "msg": msg,
            "details": {}}] {
            input.review.object.spec.containers[_].securityContext.privileged == true
            msg := "Privileged containers are not allowed in tenant namespaces"
        }

Apply the policy:

kubectl apply -f policy.yaml

Create a Constraint to Enforce the Policy

Now, bind this policy to Capsule-managed namespaces:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSSRestricted
metadata:
  name: restrict-privileged-containers
spec:
  match:
    namespaces:
      - secure-team

Apply the constraint:

kubectl apply -f constraint.yaml

---

Step 4: Test the Policy Enforcement

Now, try deploying a pod with privileged access:

apiVersion: v1
kind: Pod
metadata:
  name: privileged-pod
  namespace: secure-team
spec:
  containers:
    - name: test-container
      image: busybox
      securityContext:
        privileged: true

Apply the pod definition:

kubectl apply -f privileged-pod.yaml

Expected Output:

Error from server: admission webhook "validation.gatekeeper.sh" denied the request:
Privileged containers are not allowed in tenant namespaces

This confirms that our Capsule-OPA integration is successfully enforcing pod security policies.

---

Real-World Use Cases

SaaS Platforms

• Prevent tenants from deploying insecure workloads.
• Ensure security compliance for all tenant applications.

Enterprise Kubernetes Environments

• Apply tenant-specific security controls.
• Prevent cross-tenant security risks.

DevSecOps Pipelines

• Shift security left by enforcing policies at the CI/CD stage.
• Block insecure container configurations before deployment.

---

Best Practices for Multi-Tenant Security

1. Use Capsule quotas to prevent resource exhaustion.
2. Define OPA policies for least privilege access.
3. Regularly audit tenant workloads for security risks.
4. Combine OPA and Capsule to enforce granular security policies.
5. Monitor security policy violations using Prometheus & Grafana.

---

Conclusion

By integrating Capsule and OPA, organizations can achieve fine-grained pod security enforcement across multi-tenant Kubernetes clusters. Capsule ensures tenant isolation, while OPA provides a flexible and scalable policy enforcement mechanism. This approach not only enhances security but also simplifies compliance with industry standards like CIS benchmarks and Pod Security Standards.

Automating security policies at the tenant level allows organizations to scale their Kubernetes environments securely without manual intervention. With OPA’s policy-as-code approach, teams can continuously refine and audit their security policies, ensuring that multi-tenant clusters remain compliant over time.

As Kubernetes adoption grows, adopting multi-tenant security best practices becomes critical for maintaining secure, efficient, and scalable workloads. The combination of Capsule and OPA is a powerful toolset to achieve this. By leveraging these technologies, organizations can ensure consistent security governance, allowing different teams or customers to operate in shared clusters without compromising security.

That’s it for now. I hope this article gave you some useful insights on the topic. Please feel free to drop a comment, question or suggestion.