Linux Foundation Kyverno Certified Associate

Kyverno policies are Kubernetes resources written in YAML. You learn how policies and rules are structured, how a rule matches resources, what Audit and Enforce mean, and how policies can be packaged as OCI images.

• Policy and ClusterPolicy resources
• Rules: match, exclude and the action
• Audit and Enforce modes
• Background scans of existing resources
• Reading a policy written by someone else
• Packaging policies as OCI images

You build An annotated copy of one policy, with every field explained and its effect tested in a cluster.

A policy engine must be installed with care because it sits in the request path. You install Kyverno with Helm, learn what each controller does, inspect the custom resources it adds, and verify that it is working.

• Adding the chart repository and choosing values
• Installing into its own namespace
• The admission, background, cleanup and reports controllers
• Custom resource definitions that Kyverno adds
• Checking webhooks and pod health
• Removing Kyverno cleanly

You build A Kyverno installation from Helm with a values file, verified by a first test policy.

Defaults suit a demonstration, not production. You tune controller flags, give Kyverno the permissions that generation and mutation need, run it with several replicas, and upgrade without leaving a gap in enforcement.

• Controller flags and the configuration ConfigMap
• Excluding resources and namespaces from processing
• RBAC that Kyverno needs for mutate and generate
• High availability with several replicas
• Webhook failure policy and its risks
• Planning and performing an upgrade

You build A production-style Kyverno configuration with three replicas, tuned permissions and a documented upgrade plan.

Policies should be tested before a cluster sees them. You install the CLI, apply policies to manifests offline, write test files with expected results, and use jp to experiment with JMESPath queries.

• Installing the Kyverno CLI
• kyverno apply against files and live resources
• Writing kyverno test files
• Expected results: pass, fail and skip
• kyverno jp for JMESPath experiments
• Running policy tests in CI

You build A policy test suite that runs in a pipeline and fails when a policy stops doing what it should.

Deploying a policy is a decision about who is affected. You apply policies to a cluster, select resources by kind, name, namespace and label, and use common settings such as failure behavior and background processing.

• Applying and removing policies in a cluster
• Matching by kind, name, namespace and label
• Matching by user, group and service account
• Excluding system namespaces and trusted users
• Common policy settings and defaults
• Rolling a policy from audit to enforce

You build A policy applied first in audit mode, reviewed from its findings and then switched to enforce.

Validation is the most common use of policy. You write rules that check patterns, deny on conditions, and loop over lists of containers, with messages that tell a developer exactly what to fix.

• Pattern validation and wildcards
• Deny rules with conditions
• anyPattern and alternatives
• foreach for containers and other lists
• Writing messages developers can act on
• Common policies: labels, limits, trusted registries, no latest tag

You build A validation policy set covering labels, resource limits, image sources and tags.

Static rules only go so far. You use preconditions to decide when a rule applies, reference request data with variables, query values with JMESPath, and pull in ConfigMap or API data as context.

• Preconditions and when rules apply
• Variables from the request and the resource
• JMESPath for reading and transforming values
• ConfigMap context for shared settings
• API calls as policy context
• Debugging a variable that resolves to nothing

You build A policy that reads allowed values from a ConfigMap and applies only to selected namespaces.

Mutation fixes resources instead of rejecting them. You write strategic merge and JSON patch rules, add defaults only when missing, mutate existing resources, and reason about the order in which policies run.

• Strategic merge patches
• JSON patches
• Add-if-not-present anchors
• Mutating lists with foreach
• Mutating existing resources
• How mutation interacts with validation

You build A mutation policy that adds default security settings and labels, with tests for pods that already set them.

Policies can also create and remove resources. You generate namespace defaults such as network policies and quotas, keep them synchronized with their source, and clean up resources on a schedule or by expiry.

• Generate rules from data and from clones
• Synchronizing generated resources
• Defaults for new namespaces
• Cleanup policies and schedules
• Expiry by label or time
• Permissions needed to generate and delete

You build A policy that gives every new namespace a default-deny network policy and a quota, plus a cleanup rule for stale resources.

Trust in what runs depends on knowing where images came from, and newer rules can use CEL expressions. You verify image signatures and attestations, and write policy conditions in the Common Expression Language.

• Why verify images at admission
• VerifyImage rules and signatures
• Attestations and attestors
• Keyless and key-based verification in outline
• CEL expressions in policy
• Choosing between JMESPath and CEL

You build A policy that admits only signed images from approved registries, with a CEL rule for one extra check.

A policy program needs feedback. You read policy reports, grant narrow exceptions with PolicyExceptions, and collect metrics to see how policies perform and how often they block.

• Policy reports and cluster policy reports
• Reading results by namespace and policy
• PolicyExceptions: scope, ownership and expiry
• Kyverno metrics and what they show
• Dashboards and alerts on policy violations
• Reviewing exceptions regularly

You build A dashboard of policy results and a controlled exception process with owners and expiry.

Design the guardrails for a shared cluster. You choose the policies, write and test them, roll them out through audit to enforce, and set up the reporting and exception handling that keep them workable.

• Choosing the guardrails the cluster needs
• Writing validation, mutation and generation policies
• Testing policies in the CLI and in CI
• Rolling out from audit to enforce
• Reporting and handling exceptions
• Handing over the policy library

You build A tested policy set with a rollout plan, reports and an exception process for a shared cluster.