<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Gatekeeper on Blog Cloud &amp; DevOps</title>
    <link>https://blog.cockpitio.com/tags/gatekeeper/</link>
    <description>Recent content in Gatekeeper on Blog Cloud &amp; DevOps</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>fr</language>
    <lastBuildDate>Mon, 04 May 2026 08:00:00 +0100</lastBuildDate>
    <atom:link href="https://blog.cockpitio.com/tags/gatekeeper/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Admission Kubernetes en 2026 : Native policies (VAP, MAP), Kyverno ou Gatekeeper, comment choisir ?</title>
      <link>https://blog.cockpitio.com/kubernetes/kubernetes-admission-solutions/</link>
      <pubDate>Mon, 04 May 2026 08:00:00 +0100</pubDate>
      <guid>https://blog.cockpitio.com/kubernetes/kubernetes-admission-solutions/</guid>
      <description>ContexteLe 22 avril 2026, Kubernetes 1.36 sortait avec MutatingAdmissionPolicy en GA. C&amp;rsquo;est un tournant. Jusqu&amp;rsquo;ici, beaucoup d&amp;rsquo;équipes restaient sur Kyverno ou OPA Gatekeeper pour la simple raison qu’il manquait la mutation native dans l’API server. Maintenant, validation et mutation tournent sans webhook, sans dépendance externe.&#xA;En parallèle, en février 2026, Kyverno 1.17 bascule sur CEL comme moteur principal et déprécie ses anciennes CRDs JMESPath. Le même langage que les Admission Policies natives, mais avec la génération, le contexte externe et les PolicyReports en plus.</description>
    </item>
  </channel>
</rss>
