Skip to content

Cluster Policy

With all clusters under management, a default cluster level policy (based on OPA Gatekeeper) is automatically enforced and implemented to strengthen governance. This provides the means to control what users can/cannot do on the cluster. This also ensures that the clusters are always in compliance with centralized policies. The cluster policies are closely coordinated with network policies to ensure there is defense in depth and completeness.

Cluster Policy

Note

Learn more about Cluster Policy Enforcement in the Rafay platform.

Why is it required?

In a Kubernetes based multi-tenant environment, cluster policies are crucial for enforcing security, resource management, and compliance across different tenants. Here are some important policies that are particularly relevant:

Security Policies

  • Security Policies for Pods

    • Policy Purpose: Enforce security best practices for pods, such as running as non-root, restricting the use of privileged containers, and controlling the use of hostPath volumes. This ensures that tenants cannot deploy potentially insecure workloads that might compromise the cluster.
    • Example: Enforce that all pods must run as non-root and disallow privileged mode.

  • Image Whitelisting/Blacklisting:

    • Policy Purpose: Restrict the use of container images to approved repositories or specific image versions. This helps prevent the deployment of untrusted or vulnerable images by tenants.
    • Example: Enforce that all images must be pulled from an internal registry or a specific list of trusted registries.

Label and Annotation Policies

  • Mandatory Labels and Annotations:

    • Policy Purpose: Enforce the use of specific labels and annotations on resources for tracking, auditing, and management purposes. This is important for organizing resources, applying policies selectively, and ensuring consistent tagging across tenants.
    • Example: Enforce that every resource has labels identifying the tenant, environment (e.g., dev, prod), and application.

  • Namespace Ownership:

    • Policy Purpose: Ensure that namespaces have specific labels or annotations that identify the owning team or organization, which helps in managing tenant-specific policies and access controls.
    • Example: Enforce that each namespace has an owner label that maps to the responsible team or tenant.

Admission Control Policies

  • Restrict Certain Resource Types:

    • Policy Purpose: Prevent tenants from creating or modifying certain resource types that could impact the entire cluster (e.g., preventing tenants from creating ClusterRoleBindings or mutating webhooks).
    • Example: Enforce that tenants cannot create or modify ClusterRoles, ClusterRoleBindings, or custom resource definitions (CRDs).

  • Disallow Specific Configurations:

    • Policy Purpose: Prevent tenants from applying certain configurations that might be insecure or violate cluster policies (e.g., disallowing the use of certain annotations that might bypass security controls).
    • Example: Enforce that hostNetwork is not enabled in pod specifications, or block the use of the kubernetes.io/ingress.class annotation unless it adheres to predefined classes.

Compliance Policies

  • Compliance with Regulatory Standards:
    • Policy Purpose: Ensure that tenant workloads comply with regulatory standards such as GDPR, HIPAA, or PCI-DSS by enforcing specific configurations and controls.
    • Example: Enforce that all sensitive workloads have encryption enabled for data at rest and in transit.

In summary, centralized policy enforcement plays a crucial role in enforcing security, resource management, compliance, and operational consistency. By implementing these policies, you can ensure that each tenant operates within their allocated boundaries, adheres to security best practices, and complies with organizational or regulatory requirements.