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 docs35% off certifications and e-learning with code SEPT26BTS35, or 40% off bundles and instructor-led training with SEPT26BTS40. New this month: the MCPA (Model Context Protocol Associate) certification.
Kubernetes Access via Public Clients: Mastering OIDC with PKCE
Unlock secure Kubernetes access by leveraging public clients and PKCE. This approach mitigates the risk of intercepted authorization codes, ensuring robust authentication. Dive in to learn how to configure your identity provider effectively.
Mastering Vulnerability Reports in Open Source: A Kubernetes Perspective
Handling vulnerability reports is crucial for maintaining the integrity of your open source projects. Establish a clear reporting path in your SECURITY.md file to streamline the process. This article dives into the mechanics of vulnerability management and the importance of embargo periods.
KubeletInUserNamespace: Elevating Security in Kubernetes v1.37
Kubernetes v1.37 takes a significant step in security by promoting the KubeletInUserNamespace feature gate to beta. This feature allows node components to run as non-root users, reducing the risk of potential damage. Discover how this works and what you need to know for production.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.