Admission Controller policies
An Admission Controller in Kubernetes (k8s) is a critical component that intercepts requests to the Kubernetes API server before the persistence of the object, but after the request is authenticated and authorized. The Admission Controller makes decisions on whether to admit the request based on specific policies and rules, thereby acting as a gatekeeper that can either allow or block the creation, modification, deletion, or connection to a Kubernetes object based on the configured admission control plugins.
There are two types of Admission Controllers in Kubernetes:
- Validating Admission Webhooks: These webhooks call out to external services to validate the request. The external service can be any HTTP(s) service that you control. It can validate the object based on the criteria you’ve set and return a response to the Admission Controller on whether the request is valid.
- Mutating Admission Webhooks: Before a request is validated, it can be intercepted by these webhooks, which can modify the objects sent in the request. For instance, they can add annotations or labels, modify the object’s spec, and so forth. After the mutation, the request is then passed on to the Validating Admission Webhooks.
Admission Controllers play a vital role in maintaining the cluster’s security and integrity by ensuring that only valid and authorized requests are executed. They can enforce policies, ensure compliance with security practices, and offer a mechanism for extension and customization of Kubernetes behavior without requiring changes to the core Kubernetes code.
Kubernetes comes with several built-in Admission Controllers, and administrators can choose which ones to enable according to their cluster’s requirements. Additionally, developers can create their own Admission Controllers to enforce custom policies specific to their applications or organization’s needs.
Kyverno
Kyverno is a policy engine designed for Kubernetes, offering a way to manage and enforce policies across a Kubernetes cluster in a declarative manner. It’s particularly useful because it can both mutate (modify) and validate Kubernetes resource configurations on the fly, as well as generate new resources when necessary. This makes Kyverno a versatile tool for managing security, compliance, and operational requirements in Kubernetes environments. Here are a few examples of how Kyverno can be utilized:
1. Enforcing Pod Security Standards
You can enforce Pod Security Standards (PSS) by creating policies that ensure pods meet specific security requirements. For example, you could enforce that all pods run as non-root users, do not share the host network, or have read-only root filesystems. This helps in maintaining a baseline security posture across your cluster.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: enforce-pod-security
spec:
validationFailureAction: enforce
rules:
- name: check-root-user
match:
resources:
kinds:
- Pod
validate:
message: "Running as root is not allowed. Set runAsNonRoot to true."
pattern:
spec:
containers:
- securityContext:
runAsNonRoot: true
2. Mutating Webhook for Default Labels
Kyverno can automatically add labels to resources at the time of creation. This is particularly useful for tagging resources for organizational, billing, or monitoring purposes. Here’s a policy that adds a label indicating the environment to every namespace that is created without needing manual intervention.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: add-default-labels
spec:
rules:
- name: add-env-label
match:
resources:
kinds:
- Namespace
mutate:
patchStrategicMerge:
metadata:
labels:
environment: "dev"
3. Blocking HostPath Volumes
For security reasons, you might want to prevent pods from using hostPath
volumes, as this can expose sensitive paths of the host to the pod. A Kyverno policy can block such configurations.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: disallow-host-path
spec:
validationFailureAction: enforce
rules:
- name: validate-hostPath
match:
resources:
kinds:
- Pod
validate:
message: "hostPath volumes are not allowed"
pattern:
spec:
volumes:
- hostPath: "null"
4. Generating Resource Quotas and Limit Ranges
Kyverno can generate additional resources based on the creation of other resources. For instance, whenever a new namespace is created, Kyverno can automatically generate a ResourceQuota and a LimitRange for that namespace, ensuring that every namespace has its resource usage boundaries defined.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: generate-resource-quota-limitrange
spec:
rules:
- name: generate-resources
match:
resources:
kinds:
- Namespace
generate:
kind: ResourceQuota
name: default-resource-quota
namespace: "{{request.object.metadata.name}}"
synchronize: true
data:
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
Amazon EKS Specific Policies
Enforce EKS Pod Security Group: Amazon EKS supports assigning AWS Security Groups directly to pods. You might want to enforce that certain deployments must specify a Security Group.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: enforce-eks-security-group
spec:
rules:
- name: check-security-group-annotation
match:
resources:
kinds:
- Pod
validate:
message: "Missing EKS Security Group annotation."
pattern:
metadata:
annotations:
"eks.amazonaws.com/security-groups": "?*"
Azure AKS Specific Policies
Enforce Azure Policy Add-on: AKS integrates with Azure Policy to enforce policies on Kubernetes resources. You could create a Kyverno policy to ensure that certain critical namespaces have the Azure Policy add-on enabled, by checking for specific labels or annotations that indicate the add-on’s presence.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: ensure-azure-policy-addon
spec:
rules:
- name: check-azure-policy-addon
match:
resources:
kinds:
- Namespace
selector:
matchLabels:
"name": "critical"
validate:
message: "Azure Policy Add-on is not enabled on this namespace."
pattern:
metadata:
labels:
"azure-policy-enabled": "true"
Google GKE Specific Policies
Enforce Private Clusters: GKE offers the option to create private clusters, where nodes have internal IP addresses only. You might want to enforce that all GKE clusters within your organization are private. This policy would be more about auditing or enforcing cluster creation policies outside of the cluster itself but can be represented as an informational policy in Kyverno for awareness.
1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: enforce-gke-private-cluster
spec:
rules:
- name: check-gke-private-cluster
match:
resources:
kinds:
- Namespace
validate:
message: "Ensure your GKE clusters are private. This policy should be enforced through GCP's organizational policies."
Conclusion
In conclusion, Kubernetes Admission Controllers play a pivotal role in ensuring that clusters operate securely and efficiently by enforcing policies that govern resource creation and modification. Kyverno stands out as a versatile policy management tool that simplifies the creation, application, and enforcement of these policies. By leveraging Kyverno’s capabilities to both mutate and validate resources, developers and administrators can ensure their clusters adhere to the highest standards of security, compliance, and operational efficiency. Whether managing policies in cloud-specific environments like EKS, AKS, and GKE, or ensuring general Kubernetes best practices, Kyverno provides a powerful, declarative approach to policy management. As Kubernetes clusters grow in complexity, tools like Kyverno will become increasingly indispensable in the toolkit of those tasked with maintaining these environments. By implementing the practices and examples discussed, organizations can take a significant step forward in securing and optimizing their Kubernetes deployments.