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 →Cortex Security Audit: What You Need to Know
Cortex has completed a rigorous security audit by OSTIF, enhancing its credibility as a multi-tenant storage solution for Prometheus and OpenTelemetry. The audit focused on the security health of tenant boundaries and cluster operations, using advanced code review techniques. This is crucial for anyone looking to deploy Cortex in sensitive environments.
Runtime Supply Chain Verification with NRI: Securing Your Kubernetes Deployments
In a world where supply chain attacks are rampant, ensuring the integrity of your container images is crucial. The Node Resource Interface (NRI) allows you to enforce supply chain verification at runtime, leveraging plugins to validate image attestations before they even start. Dive into how this mechanism works and what you need to watch out for in production.
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.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.