Documentation / Cluster policies

Cluster policies

← Documentation · Welcome

Two sets of guardrails are enforced on every namespace: which resource kinds you can create via your repo, and how your pods must be configured (workload hardening). A deploy that violates either is rejected at sync time - nothing breaks, it just doesn't go live until fixed.

Allowed resource kinds

This is the contract enforced for your namespace. You can create the kinds under ALLOW by committing them to your repo; anything else must be requested via ticket. (Agents configuring an app: parse this.)

# SELF-SERVICE - create these in your repo; ArgoCD syncs them into your namespace.
ALLOW (apiGroup → kinds):
  ""                          ConfigMap, Secret, Service, ServiceAccount, PersistentVolumeClaim
  apps                        Deployment, StatefulSet, DaemonSet, ReplicaSet
  batch                       Job, CronJob
  networking.k8s.io           Ingress
  gateway.networking.k8s.io   HTTPRoute
  autoscaling                 HorizontalPodAutoscaler
  policy                      PodDisruptionBudget

# PLATFORM - cannot be created via self-service; request via support@inf.ethz.ch.
DENY:
  rbac.authorization.k8s.io   Role, RoleBinding           # all RBAC, including namespace-scoped
  networking.k8s.io           NetworkPolicy               # isolation is platform-managed
  <any cluster-scoped kind>   # e.g. Namespace, ClusterRole, ClusterRoleBinding, StorageClass, CRDs
  <any kind not under ALLOW>  # default-deny: if it isn't listed above, request it

A sync that references a kind outside ALLOW will fail until the platform adds it for you. This list mirrors your namespace's ArgoCD AppProject (namespaceResourceWhitelist / namespaceResourceBlacklist, with no cluster-scoped resources allowed); if that changes, this page is updated to match.

Workload hardening

Pods run non-root, without privilege escalation, without host access, and drop Linux capabilities by default. In practice that means every container needs a securityContext like this:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

The example deployment.yaml ships with a compliant securityContext - copy it and keep it as-is unless you have a reason not to. Common consequences:

  • Your container image must be able to run as a non-root user (most official images can; some need a runAsUser or an image variant).
  • Anything that needs privileged access, host paths, or extra capabilities is an exception, reviewed before it's granted.

Requesting an exception

Need a denied kind, or a relaxation of the hardening? Open a ticket at support@inf.ethz.ch (what to include) - name the resource kind or the exact securityContext field, and why your app needs it.