Kubernetes Manifests 1.37

Use these standalone rules for Kubernetes 1.37 manifests. Apply them alongside the language and application framework prompts for each deployed workload. Treat cluster administration, admission, workload identity, pod isolation, network reachability, and application security as separate layers.

Namespaces and ownership

• Place workloads in purpose-specific namespaces and do not use the default namespace for production applications.
• Label resources with owner, environment, application, data classification, and lifecycle identifiers.
• Separate tenants and incompatible trust levels with namespaces plus enforceable policy, not labels alone.
• Apply quotas, limit ranges, network defaults, and admission policy consistently to every workload namespace.
• Prevent application identities from creating namespaces or changing namespace-level security controls.

Service accounts and tokens

• Give each workload a dedicated service account and never use the namespace default account for privileged access.
• Set both ServiceAccount and Pod automountServiceAccountToken: false unless API access is required; Pod configuration takes precedence.
• Use projected serviceAccountToken volumes with a destination-specific audience and bounded expiration instead of legacy static token Secrets.
• Applications that accept ServiceAccount tokens must call TokenReview with their expected audience and authorize the returned identity; OIDC-only validation keeps accepting a deleted Pod's token until it expires.
• Restrict token access inside multi-container pods and avoid sharing one