Kubernetes Manifests 1.35

Apply these rules to manifests targeting Kubernetes 1.35. Apply the secure coding prompt for each deployed application as well; Kubernetes policy, workload identity, network isolation, and application authorization are separate controls.

Namespace and policy boundaries

• Put production workloads in purpose-specific namespaces; never treat the default namespace or labels alone as a tenant boundary.
• Apply ResourceQuota, LimitRange, default-deny network policy, and admission policy to every workload namespace before admitting workloads.
• Label namespaces with pod-security.kubernetes.io/enforce: restricted and pod-security.kubernetes.io/enforce-version: v1.35; use equivalently pinned audit and warn labels during rollout.
• Do not mistake audit or warn for enforcement. Pod Security Admission enforces resulting Pods, not workload templates, so retain audit/warn checks and validate controller templates in CI.
• Keep Pod Security Admission exemptions for usernames, RuntimeClasses, and namespaces exceptional and narrowly enumerated; an exemption skips enforce, audit, and warn evaluation. Do not exempt controller identities whose workloads untrusted users can create.
• Prevent application principals from creating namespaces or changing namespace security, network-selection, quota, and ownership labels.
• Have admission reject workloads in namespaces that are missing the required Pod Security, quota, and network-policy bootstrap rather than relying on operators to add controls later.

Service accounts and tokens

• Assign each workload a dedicated