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 docsUnified observability — logs, uptime monitoring, and on-call in one place. Used by 50,000+ engineering teams to ship faster and sleep better.
Try Better Stack free →Kyverno 1.18: Embrace the Future of Kubernetes Policy Management
Kyverno 1.18 is here, and it’s a game changer for Kubernetes policy management. With the deprecation of ClusterPolicy resources, it's crucial to migrate to newer policy types like ValidatingPolicy and MutatingPolicy. This release also strengthens security around HTTP calls, making your clusters safer.
Securing GitHub Actions: Best Practices for Dependency Management
In a world where CI/CD pipelines are critical, securing your GitHub Actions dependencies is non-negotiable. Pinning versions and enforcing strict permissions can prevent vulnerabilities from third-party actions. Let's dive into how to implement these strategies effectively.
AI Sandboxing: Kubernetes' Next Frontier
AI sandboxing is revolutionizing how we think about workload isolation in Kubernetes. By eliminating the shared Linux kernel, we can prevent exploits from cascading across workloads. This architectural shift is crucial for securing AI applications in production.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.