Kubernetes v1.36: Unremovable Admission Policies for Stronger Security
In a world where security breaches are rampant, Kubernetes v1.36's introduction of admission policies that can't be deleted is a critical enhancement. This feature allows you to define admission webhooks and CEL-based policies that are loaded at the API server's startup, ensuring that your security measures are in place before any requests are processed. This self-contained approach to admission control addresses the need for robust policy enforcement, making it harder for malicious actors to bypass security measures.
The mechanism is straightforward. You point the API server to a directory containing your policy YAML files using the staticManifestsDir field in the AdmissionConfiguration file. When the API server starts, it loads these policies, ensuring they are active from the get-go. If any manifest is invalid, the server won't start, which enforces a strict validation process right from the beginning. This means you need to be meticulous with your YAML files, as any errors can prevent the entire API server from functioning.
In production, be aware that manifest-based configurations are intentionally self-contained. If you run multiple API server instances, each instance loads its own manifest files independently, which can lead to inconsistencies if not managed properly. Additionally, the initial load at startup is stricter, so ensure your manifests are valid to avoid startup failures. This feature is currently in alpha, so keep an eye on its evolution and be prepared for potential changes in future releases.
Key takeaways
- →Define admission policies using manifest-based admission control for enhanced security.
- →Use the `staticManifestsDir` field in the AdmissionConfiguration to point to your policy directory.
- →Ensure all YAML manifests are valid before starting the API server to prevent startup failures.
- →Understand that each API server instance loads its own manifest files independently.
- →Be aware that this feature is currently in alpha and may evolve in future Kubernetes releases.
Why it matters
This feature significantly strengthens your cluster's security posture by preventing unauthorized modifications to critical admission policies, which is essential in a production environment.
Code examples
1apiVersion:
2apiserver.config.k8s.io/v1
3kind:
4AdmissionConfiguration
5plugins:
6-
7name:
8ValidatingAdmissionPolicy
9configuration:
10apiVersion:
11apiserver.config.k8s.io/v1
12kind:
13ValidatingAdmissionPolicyConfiguration
14staticManifestsDir:
15"/etc/kubernetes/admission/validating-policies/"1apiVersion:
2admissionregistration.k8s.io/v1
3kind:
4ValidatingAdmissionPolicy
5metadata:
6name:
7"deny-privileged.static.k8s.io"
8annotations:
9kubernetes.io/description:
10"Deny launching privileged pods, anywhere this policy is applied"
11spec:
12failurePolicy:
13Fail
14matchConstraints:
15resourceRules:
16-
17apiGroups:
18[
19""
20]
21apiVersions:
22[
23"v1"
24]
25operations:
26[
27"CREATE",
28"UPDATE"
29]
30resources:
31[
32"pods"
33]
34variables:
35-
36name:
37allContainers
38expression:
39>-
40object.spec.containers +
41(has(object.spec.initContainers) ? object.spec.initContainers : []) +
42(has(object.spec.ephemeralContainers) ? object.spec.ephemeralContainers : [])
43validations:
44-
45expression:
46>-
47!variables.allContainers.exists(c,
48has(c.securityContext) && has(c.securityContext.privileged) &&
49c.securityContext.privileged == true)
50message:
51"Privileged containers are not allowed"1apiVersion:
2admissionregistration.k8s.io/v1
3kind:
4ValidatingAdmissionPolicy
5metadata:
6name:
7"protect-policies.static.k8s.io"
8annotations:
9kubernetes.io/description:
10"Prevent modification or deletion of protected admission resources"
11spec:
12failurePolicy:
13Fail
14matchConstraints:
15resourceRules:
16-
17apiGroups:
18[
19"admissionregistration.k8s.io"
20]
21apiVersions:
22[
23"*"
24]
25operations:
26[
27"DELETE",
28"UPDATE"
29]
30resources:
31-
32"validatingadmissionpolicies"
33-
34"validatingadmissionpolicybindings"
35-
36"validatingwebhookconfigurations"
37-
38"mutatingwebhookconfigurations"
39validations:
40-
41expression:
42>-
43!has(oldObject.metadata.labels) ||
44!('platform.example.com/protected' in oldObject.metadata.labels) ||
45oldObject.metadata.labels['platform.example.com/protected'] != 'true'
46message:
47"Protected admission resources cannot be modified or deleted"When NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsIndustry-standard certifications built by the people behind Linux and Kubernetes. Earn globally recognized credentials — CKA, CKAD, CKS, and 40+ more. OpsCanary readers get 30% off year-round.
Explore certifications →Cortex Security Audit: What You Need to Know
Cortex has completed a rigorous security audit by OSTIF, enhancing its credibility as a multi-tenant storage solution for Prometheus and OpenTelemetry. The audit focused on the security health of tenant boundaries and cluster operations, using advanced code review techniques. This is crucial for anyone looking to deploy Cortex in sensitive environments.
Runtime Supply Chain Verification with NRI: Securing Your Kubernetes Deployments
In a world where supply chain attacks are rampant, ensuring the integrity of your container images is crucial. The Node Resource Interface (NRI) allows you to enforce supply chain verification at runtime, leveraging plugins to validate image attestations before they even start. Dive into how this mechanism works and what you need to watch out for in production.
Unlocking Data Security: Confidential Containers in Kubernetes
Confidential Containers are revolutionizing data protection in cloud-native environments by leveraging Trusted Execution Environments (TEEs). This technology ensures that sensitive workloads can run securely on third-party infrastructure without exposing data to operators.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.