Kyverno 1.18: Embrace the Future of Kubernetes Policy Management
Kyverno 1.18 marks a significant evolution in Kubernetes policy management, especially with the planned deprecation of ClusterPolicy resources later this year. This change pushes users toward newer policy types such as ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ImageValidatingPolicy, and DeletingPolicy. These newer types offer enhanced capabilities and align better with Kubernetes' evolving landscape, ensuring your policies remain effective and relevant.
In this release, Kyverno policies can now call external services via HTTP using CEL libraries, but with a twist. The security around these calls has been significantly hardened. By default, unsafe addresses like loopback and metadata services are blocked, and users can configure both allow and block lists for cluster-scoped and namespaced policies. Additionally, HTTP calls from namespaced policies are disabled by default and require explicit enabling through configuration flags. This is a crucial step in preventing SSRF-style abuses, keeping your cluster secure.
As you adopt Kyverno 1.18, remember that the transition from ClusterPolicy to the newer policy types is not just a recommendation; it’s a necessity. The deprecation warning is clear, and ignoring it could lead to complications down the line. Also, be mindful of the configuration parameters like the successEventActions ConfigMap, which allows you to control the verbosity of policy reporting. This release is a step forward, but it requires your attention to detail to leverage its full potential.
Key takeaways
- →Migrate from ClusterPolicy to ValidatingPolicy, MutatingPolicy, and others to stay current.
- →Configure allow and block lists for HTTP calls to enhance security.
- →Explicitly enable HTTP calls from namespaced policies to avoid security risks.
- →Use the successEventActions ConfigMap to manage policy reporting noise.
- →Stay aware of the deprecation timeline to avoid future issues.
Why it matters
In production, transitioning to Kyverno 1.18 ensures that your Kubernetes policies are not only effective but also secure against emerging threats. The hardened HTTP call security is particularly vital for protecting sensitive cluster data.
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 docsUnified observability — logs, uptime monitoring, and on-call in one place. Used by 50,000+ engineering teams to ship faster and sleep better.
Try Better Stack free →Unlocking Data Security: Confidential Containers in Kubernetes
Confidential Containers are revolutionizing data protection in cloud-native environments by leveraging Trusted Execution Environments (TEEs). This technology ensures that sensitive workloads can run securely on third-party infrastructure without exposing data to operators.
Making Kyverno Think It's in Production: A Practical Guide
Ever wondered how to test your Kubernetes policies without deploying them? Learn how to leverage Kyverno's CLI to simulate a production environment, ensuring your policies are battle-tested before they hit the cluster. This article dives into the mechanics of using resolveResourcesMockData for reliable policy evaluation.
Mastering Security Profiles Operator v1: Harden Your Kubernetes Workloads
Security is paramount in Kubernetes, and the Security Profiles Operator (SPO) simplifies managing security profiles as custom resources. With its stable API and support for seccomp, SELinux, and AppArmor, you can enhance your cluster's security posture effortlessly.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.