Kyverno offers a robust, declarative approach to enforcing security and compliance standards within Kubernetes clusters by allowing users to define and enforce custom policies. For an in-depth look at Kyverno’s functionality, including core concepts and benefits, see my detailed article here. In this guide, we’ll focus on extending Kyverno policies, providing a structured walkthrough of its data model, and illustrating use cases to make the most of Kyverno in a Kubernetes environment.
Understanding the Kyverno Policy Data Model
Kyverno policies consist of several components that define how the policy should behave, which resources it should affect, and the specific rules that apply. Let’s dive into the main parts of the Kyverno policy model:
- Policy Definition: This is the root configuration where you define the policy’s metadata, including name, type, and scope. Policies can be created at the namespace level for specific areas or as cluster-wide rules to enforce uniform standards across the entire Kubernetes cluster.
- Rules: Policies are made up of rules that dictate what conditions Kyverno should enforce. Each rule can include logic for validation, mutation, or generation based on your needs.
- Match and Exclude Blocks: These sections allow fine-grained control over which resources the policy applies to. You can specify resources by their kinds (e.g., Pods, Deployments), namespaces, labels, and even specific names. This flexibility is crucial for creating targeted policies that impact only the resources you want to manage.
- Match block: Defines the conditions under which the rule applies to specific resources.
- Exclude block: Used to explicitly omit resources that match certain conditions, ensuring that unaffected resources are not inadvertently included.
- Validation, Mutation, and Generation Actions: Each rule can take different types of actions:
- Validation: Ensures resources meet specific criteria and blocks deployment if they don’t.
- Mutation: Adjusts resource configurations to align with predefined standards, which is useful for auto-remediation.
- Generation: Creates or manages additional resources based on existing resource configurations.
Example: Restricting Container Image Sources to Docker Hub
A common security requirement is to limit container images to trusted registries. The example below demonstrates a policy that only permits images from Docker Hub.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-dockerhub-images
spec:
rules:
- name: only-dockerhub-images
match:
resources:
kinds:
- Pod
validate:
message: "Only Docker Hub images are allowed."
pattern:
spec:
containers:
- image: "docker.io/*"This policy targets all Pod resources in the cluster and enforces a validation rule that restricts the image source to docker.io. If a Pod uses an image outside Docker Hub, Kyverno denies its deployment, reinforcing secure sourcing practices.
Practical Use-Cases for Kyverno Policies
Kyverno policies can handle a variety of Kubernetes management tasks through validation, mutation, and generation. Let’s explore examples for each type to illustrate Kyverno’s versatility:
1. Validation Policies
Validation policies in Kyverno ensure that resources comply with specific configurations or security standards, stopping any non-compliant resources from deploying.
Use-Case: Enforcing Resource Limits for Containers
This example prevents deployments that lack resource limits, ensuring all Pods specify CPU and memory constraints.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: enforce-resource-limits
spec:
rules:
- name: require-resource-limits
match:
resources:
kinds:
- Pod
validate:
message: "Resource limits (CPU and memory) are required for all containers."
pattern:
spec:
containers:
- resources:
limits:
cpu: "?*"
memory: "?*"By enforcing resource limits, this policy helps prevent resource contention in the cluster, fostering stable and predictable performance.
2. Mutation Policies
Mutation policies allow Kyverno to automatically adjust configurations in resources to meet compliance requirements. This approach is beneficial for consistent configurations without manual intervention.
Use-Case: Adding Default Labels to Pods
This policy adds a default label, environment: production, to all new Pods that lack this label, ensuring that resources align with organization-wide labeling standards.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: add-default-label
spec:
rules:
- name: add-environment-label
match:
resources:
kinds:
- Pod
mutate:
patchStrategicMerge:
metadata:
labels:
environment: "production"This mutation policy is an example of how Kyverno can standardize resource configurations at scale by dynamically adding missing information, reducing human error and ensuring labeling consistency.
3. Generation Policies
Generation policies in Kyverno are used to create or update related resources, enhancing Kubernetes automation by responding to specific configurations or needs in real-time.
Use-Case: Automatically Creating a ConfigMap for Each New Namespace
This example policy generates a ConfigMap in every new namespace, setting default configuration values for all resources in that namespace.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: generate-configmap
spec:
rules:
- name: add-default-configmap
match:
resources:
kinds:
- Namespace
generate:
kind: ConfigMap
name: default-config
namespace: "{{request.object.metadata.name}}"
data:
default-key: "default-value"This generation policy is triggered whenever a new namespace is created, automatically provisioning a ConfigMap with default settings. This approach is especially useful in multi-tenant environments, ensuring new namespaces have essential configurations in place.
Conclusion
Extending Kyverno policies enables Kubernetes administrators to establish and enforce tailored security and operational practices within their clusters. By leveraging Kyverno’s capabilities in validation, mutation, and generation, you can automate compliance, streamline operations, and reinforce security standards seamlessly.
