What & Why ?

Certainly! Let's go through each point with an example to help illustrate the features of Kyverno:

1. Policies as Kubernetes resources: Instead of learning a new language, Kyverno allows you to define policies using standard Kubernetes YAML files. For example, you can define a policy that requires all pods to have a specific label called "environment: production."

2. Validation, mutation, generation, and cleanup: Kyverno can validate, modify, generate, or clean up Kubernetes resources based on policies. For instance, you can define a policy that adds a sidecar container to every deployment to enable logging and monitoring.

3. Software supply chain security: Kyverno can verify container images used in Kubernetes deployments. For example, you can define a policy that checks if only trusted container images from specific repositories are allowed to be used in the cluster.

4. Label selectors and wildcards: Kyverno supports matching resources using labels. For example, you can define a policy that applies to all resources with the label "app: frontend" or resources with labels starting with "tier: ".

5. Overlays for validation and mutation: Similar to Kustomize, Kyverno allows you to apply overlays to validate or modify resources. For instance, you can define an overlay that adds resource requests and limits to all pod specifications.

6. Synchronizing configurations across Namespaces: Kyverno enables you to synchronize configurations across different Namespaces. For example, you can define a policy that ensures all Namespaces have the same resource quota limits.

7. Admission controls and policy violations: Kyverno can block the creation or modification of non-conforming resources. For instance, if a user tries to create a pod without the required label "app: backend," Kyverno can prevent it and provide an error message indicating the violation.

8. Self-service reports and policy exceptions: Kyverno provides self-service reports on policy compliance and allows users to request exceptions to specific policies. For example, a developer can request an exception if a particular policy prevents them from deploying a necessary resource.

9. Testing and validation: Kyverno's CLI allows you to test policies and validate resources before applying them to the cluster. For example, you can run the CLI command to validate a deployment YAML file against defined policies to ensure it meets the requirements.

10. Managing policies as code: Kyverno allows you to manage policies as code using tools like Git and Kustomize. For instance, you can store your policy files in a Git repository, version control them, and use Kustomize to manage different policy configurations for different environments.

These examples illustrate how Kyverno helps with policy enforcement, resource modification, supply chain security, label-based matching, synchronization, admission controls, self-service reports, testing, and managing policies as code in Kubernetes.

How ?

there are total 4 main steps :

1. Gate Keeper : Kyverno acts as the gate keeper , it intercepts the requests and the does particular operations

2. Notifications from API server : When user asks for requests then API server sends http callback ( notification ) to Kyverno

3. Matching policies & checking : Then Kyverno crosschecks those policies

4. Accepting or Rejecting requests : then on result of above check approval is done or not done

Imagine you have a policy in Kyverno that states: "All pods in the cluster must have a label called 'team: marketing'." Now, someone tries to create a pod without that label.

When the request to create the pod reaches the Kubernetes API server, it triggers an HTTP callback to Kyverno. Kyverno receives this callback and checks the pod's specifications.

Kyverno applies the matching policy, which states that the pod must have the label 'team: marketing.' If the pod doesn't have this label, Kyverno enforces the policy by modifying the pod to add the required label (mutating). The modified pod is then allowed to proceed and be created.

However, if the pod already has the label 'team: marketing,' Kyverno determines that the policy is already satisfied, so it allows the request to proceed without any modifications.

On the other hand, if the pod doesn't have the required label, Kyverno rejects the request entirely, preventing the pod from being created and providing an error message indicating the policy violation.

what are mutating policies ?

are rules / instruction which define how resources should be changed or modified

Suppose you have a mutating policy that states: "All pods should have an additional environment variable called 'ENVIRONMENT' with the value set to 'production'."

Now, when someone creates a pod in the Kubernetes cluster, Kyverno intercepts the request and checks if it matches the defined mutating policies. In this case, Kyverno examines the pod specifications.

If the pod doesn't have the environment variable 'ENVIRONMENT' with the value 'production', Kyverno applies the mutating policy by automatically modifying the pod's configuration. It adds the missing environment variable with the desired value.

As a result, when the pod is created or updated, it will have the 'ENVIRONMENT' environment variable set to 'production' as per the defined policy.

what are overlays ?

In the context of Kyverno, overlays are a mechanism that allows you to define changes or modifications to Kubernetes resources without directly modifying the original resource files. Overlays provide a way to apply additional configurations or modifications on top of the base resource definitions.

what are validating policies ?

Validating policies in Kyverno are rules or conditions that define the requirements or constraints for Kubernetes resources. They are used to ensure that resources adhere to specific standards, configurations, or security policies.

Suppose you have a validating policy that states: "All pods in the 'production' namespace must have a resource limit of at least 1 CPU and 1GB of memory."

When someone creates or modifies a pod in the Kubernetes cluster, Kyverno applies this validating policy to ensure that the pod meets the defined requirements.

In this case, Kyverno examines the pod specifications, such as the requested resources (CPU and memory limits), namespace, and other relevant details.

If the pod is in the 'production' namespace and its resource limits are below the specified threshold (less than 1 CPU and 1GB of memory), Kyverno generates an error message indicating the policy violation. This prevents the creation or modification of non-compliant pods.

On the other hand, if the pod in the 'production' namespace already has resource limits that meet or exceed the defined threshold, Kyverno determines that the policy is satisfied, and the pod is allowed to proceed without any errors.

what is policy enforcement ?

Suppose you have a policy in Kyverno that states: "All pods should have a label called 'team' with the value 'marketing'."

When someone creates or modifies a pod in the Kubernetes cluster, Kyverno enforces this policy by checking if the pod has the required label with the specified value.

If the pod does not have the 'team' label or the value is not set to 'marketing', Kyverno takes action to enforce the policy. It can either modify the pod by adding the missing label or reject the creation/modification of the pod entirely, depending on the policy configuration.

By enforcing this policy, Kyverno ensures that all pods within the cluster adhere to the defined labeling standard. It promotes consistency, better organization, and efficient management of pods.

what is kubernetes event ?

For example, let's say you deploy a new application by creating a pod in the cluster. Once the pod is successfully created, a "Normal" event may be generated with a message like: "Pod xyz created successfully."

Components of Kyverno

webhook server takes the request from api server and then passes it to to engine for further operations

webhook controller watches the installed policies and modifies webhook server such that it only request resources that match those policies

engine checkst those policies passed by webhook server

The Cert Renewer is responsible for monitoring and renewing the certificates needed by the Webhook. These certificates are stored as Kubernetes Secrets.

The Background Controller handles the generation and mutation of existing policies