{"id":27821,"date":"2021-07-09T12:24:50","date_gmt":"2021-07-09T11:24:50","guid":{"rendered":"https:\/\/www.inovex.de\/blog\/?p=21284"},"modified":"2022-11-21T15:50:55","modified_gmt":"2022-11-21T14:50:55","slug":"ersatz-kubernetes-podsecuritypolicies-alternativen","status":"publish","type":"post","link":"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/","title":{"rendered":"Ersatz f\u00fcr Kubernetes PodSecurityPolicies \u2013 passende Alternativen"},"content":{"rendered":"<p>Mit Kubernetes 1.21 wurden <a href=\"https:\/\/kubernetes.io\/blog\/2021\/04\/06\/podsecuritypolicy-deprecation-past-present-and-future\/\">PodSecurityPolicies (PSP) abgek\u00fcndigt<\/a>. Also Panik angesagt? Nein, die PSPs bleiben uns zuerst einmal erhalten und werden vermutlich erst in 1.25 entfernt.\u00a0Trotzdem ist es eine gute Gelegenheit sich schon jetzt nach Alternativen umzuschauen. In diesem Artikel konzentrieren wir uns auf drei Open-Source-Tools und die &#8222;PSP Replacement Policy&#8220;<!--more--><\/p>\n<p>Zu den m\u00f6glichen Alternativen geh\u00f6ren:<\/p>\n<ul>\n<li>der Kubernetes-eigene Ersatz (vorl\u00e4ufiger Name &#8222;PSP Replacement Policy&#8220;,\u00a0<a href=\"https:\/\/github.com\/kubernetes\/enhancements\/issues\/2579\">KEP 2579<\/a>)<\/li>\n<li>OPA Gatekeeper<\/li>\n<li>Kyverno<\/li>\n<li>k-rail<\/li>\n<li><a href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/governance\/policy\/concepts\/policy-for-kubernetes\">Azure Policy<\/a>, Aqua, Twistlock (Prisma), Sysdig<\/li>\n<\/ul>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_82_2 counter-hierarchy ez-toc-counter ez-toc-custom ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\"><p class=\"ez-toc-title\" style=\"cursor:inherit\"><\/p>\n<\/div><nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#Admission-Controller\" >Admission Controller<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#Tools\" >Tools<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#PodSecurityPolicies-Replacement-Policy\" >PodSecurityPolicies Replacement Policy<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#OPA-kube-mgmt-OPA-Gatekeeper\" >OPA, kube-mgmt, OPA Gatekeeper<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#Kyverno\" >Kyverno<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#k-rail\" >k-rail<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#Szenarien\" >Szenarien<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#Einfach-PodSecurityPolicies-ersetzen\" >Einfach PodSecurityPolicies ersetzen<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#Komplexere-Szenarien\" >Komplexere Szenarien<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#Fazit\" >Fazit<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"Admission-Controller\"><\/span>Admission Controller<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Die von uns untersuchten vier Alternativen funktionieren alle einigerma\u00dfen \u00e4hnlich: Der Kubernetes API Server unterst\u00fctzt Admission Controller, die bei jedem API-Request befragt werden. Entweder pr\u00fcfen sie nur und geben ja\/nein zur\u00fcck (validating) oder sie k\u00f6nnen die Objekte ver\u00e4ndern (mutating). Damit k\u00f6nnte man z. B. ein bestimmtes Label an einen Pod setzen.<\/p>\n<p>Eine ganze Reihe dieser Admission Controller sind bereits in den API Server eingebaut (<a href=\"https:\/\/kubernetes.io\/docs\/reference\/access-authn-authz\/admission-controllers\/\">builtin<\/a>), aber der API Server kann auch zur Laufzeit mit externen Admission Controllern erweitert werden (<a href=\"https:\/\/kubernetes.io\/docs\/reference\/access-authn-authz\/extensible-admission-controllers\/\">Dynamic Admission Controllers<\/a>). Diese nennt man dann MutatingAdmissionWebhook oder ValidatingAdmissionWebhook.<\/p>\n<p>Alle hier vorgestellten Alternativen stellen einen solchen Admission Controller bereit.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Tools\"><\/span>Tools<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<h3><span class=\"ez-toc-section\" id=\"PodSecurityPolicies-Replacement-Policy\"><\/span>PodSecurityPolicies Replacement Policy<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Der bisherige PodSecurityPolicy Controller war ein eingebauter, mutating admission controller. Der \u201emutating\u201c-Aspekt ist unter anderem ein Grund, warum der Controller jetzt \u00fcberarbeitet wird: Bei manchen Feldern wurde die PodSpec ver\u00e4ndert, damit der Pod die Policy erf\u00fcllt. Dieses Verhalten war f\u00fcr viele verwirrend, ebenso die Art und Weise, wie man die Rechte vergab, damit jemand eine Policy verwenden durfte. Zudem mussten bisher immer <em>explizit<\/em> die Rechte vergeben werden, eine bestimmte PSP nutzen zu d\u00fcrfen. Eine einzelne PSP musste dann den Pod erlauben, auch wenn ein:e Nutzer:in mehrere PSPs verwenden darf und ein Kombination der PSPs den Pod erlaubt h\u00e4tte.<\/p>\n<p>Mit der neuen PSP Replacement Policy soll das alles klarer werden. Im Gegenzug gibt man etwas (kaum genutzte) Flexibilit\u00e4t auf. Da die erste Alpha-Version erst in 1.22 kommt, ist noch nicht genau klar, wie die L\u00f6sung endg\u00fcltig aussehen wird. Im Moment sieht es so aus, als ob es die drei Stufen <em>restricted<\/em>, <em>baseline<\/em> und <em>privileged<\/em> geben wird, die sich an den bisherigen <a href=\"https:\/\/kubernetes.io\/docs\/concepts\/security\/pod-security-standards\/\">Empfehlungen f\u00fcr PSPs<\/a>\u00a0orientieren. Welche Policy f\u00fcr welchen Namespace gilt, wird dann mit Labels am Namespace festgelegt:<\/p>\n<pre class=\"lang:yaml decode:true\" title=\"Beispiel Namespace mit Labels\">apiVersion: v1\r\nkind: Namespace\r\nmetadata:\r\n  name: example\r\n  labels:\r\n    &lt;featurename&gt;.kubernetes.io\/allow: baseline\r\n    &lt;featurename&gt;.kubernetes.io\/allow-version: 1.22\r\n    &lt;featurename&gt;.kubernetes.io\/warn: restricted\r\n    &lt;featurename&gt;.kubernetes.io\/warn-version: latest<\/pre>\n<p>Damit wird zum Beispiel verboten, einen Pod mit hostPath zu starten, aber nur gewarnt, wenn ein Container im Pod als root l\u00e4uft. Da die Policies sich mit Kubernetes selbst ver\u00e4ndern k\u00f6nnen, kann man mit dem <em>version<\/em>-Label auf eine bestimmte Version festlegen oder mit <em>latest<\/em> immer auf die neueste Version festlegen.<\/p>\n<p>Geplant ist zudem eine Audit-Funktion, feinere Abstufungen um bei bestimmten User-Namen oder <a href=\"https:\/\/kubernetes.io\/docs\/concepts\/containers\/runtime-class\/\">RuntimeClasses<\/a>\u00a0explizit nicht zu pr\u00fcfen und Warnungen, wenn eine \u00c4nderung der Namespace-Labels Pods darin betreffen.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"OPA-kube-mgmt-OPA-Gatekeeper\"><\/span>OPA, kube-mgmt, OPA Gatekeeper<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Im Universum des Open Policy Agent (OPA) gibt es gleich mehrere Tools: kube-mgmt war der alte Weg ihn zu deployen, heute wird eher der OPA Gatekeeper verwendet.<\/p>\n<p>Policies werden in der eigenen Sprache <em>rego<\/em> geschrieben (empfehlenswert zum Ausprobieren: <a href=\"https:\/\/play.openpolicyagent.org\">https:\/\/play.openpolicyagent.org<\/a>). Bei kube-mgmt werden die rego-Regeln mittels ConfigMaps geladen, der Gatekeeper definiert dagegen Kubernetes&#8216; CRDs f\u00fcr u. a. ConstraintTemplates. Mit ConstraintTemplates wird die Policy-Bibliothek erweitert, z. B. dem rego-Code f\u00fcr &#8222;pr\u00fcfe ob eine Annotation x einen bestimmten Wert y hat&#8220;. Der Gatekeeper erzeugt daraus wieder eine CRD, die dann instanziiert werden kann; also z. B. dass die Annotation &#8222;force-ssl-redirect&#8220; an einem Ingress nicht &#8222;true&#8220; sein darf. Diese Konstruktion erlaubt eine Trennung, sodass Techniker die ConstraintTemplates erstellen und Nicht-Techniker diese selbstst\u00e4ndig verwenden k\u00f6nnen, um ihre Vorstellungen umzusetzen. Andererseits ist diese Konstruktion auch manchmal schwer zu durchschauen.<\/p>\n<p>Ein Vorteil vom OPA ist, dass es ihn auch f\u00fcr alle m\u00f6glichen anderen Stellen (ssh, ingress, &#8230;) gibt, so dass man theoretisch \u00fcber seinen ganzen Stack dieselben Policies verwenden kann. In der Praxis habe ich noch nicht gesehen, dass man die Kubernetes-spezifischen Policies irgendwo anders wiederverwenden k\u00f6nnte &#8230;<\/p>\n<p>Auch ansonsten macht OPA(-Gatekeeper) einen soliden Eindruck:<\/p>\n<ul>\n<li>Er stellt Metriken bereit, damit man seine Funktion \u00fcberwachen kann<\/li>\n<li>Er kann hochverf\u00fcgbar betrieben werden \u2013 zumindest mit validierenden Regeln<\/li>\n<li>Die <a href=\"https:\/\/github.com\/open-policy-agent\/gatekeeper-library\">gatekeeper-library<\/a> liefert viele Beispiele (besonders hilfreich, wenn man mit rego neu anf\u00e4ngt)<\/li>\n<li>Wie es aktuell aussieht, entwickelt sich OPA zu so etwas wie dem de-facto Standard (kommt z. B. auch im <a href=\"https:\/\/github.com\/cncf\/curriculum\/blob\/18b874435de67b2b72aec78b073ead931e9fc5e0\/CKS_Curriculum_%20v1.22.pdf\">CKS<\/a> vor, viele Vortr\u00e4ge auf der KubeCon)<\/li>\n<li>OPA-Gatekeeper bietet auch einen Audit-Modus, in dem er Regelverst\u00f6\u00dfe nicht verbietet, sondern nur auflistet mit\u00a0<span class=\"lang:default decode:true crayon-inline\">kubectl describe ConstraintTemplateGeneratedCRD<\/span> (\u00e4hnlich wie SELinux&#8216; permissive mode)<\/li>\n<\/ul>\n<p>Der OPA-Gatekeeper erlaubt prinzipiell auch Mutating-Regeln, um Pods zu ver\u00e4ndern. Das Feature ist aktuell aber noch in einem experimentellen Stadium (<a href=\"https:\/\/github.com\/open-policy-agent\/gatekeeper\/issues\/588\">Github issue<\/a>).<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Kyverno\"><\/span>Kyverno<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><a href=\"https:\/\/kyverno.io\">Kyverno<\/a> ist deutlich auf Kubernetes ausgelegt: Die Konfiguration erfolgt mittels eigener CRDs und im yaml-Format, wie in der Kubernetes-Welt gewohnt.<\/p>\n<p>Auch Kyverno bietet:<\/p>\n<ul>\n<li>Metriken<\/li>\n<li>Eine <a href=\"https:\/\/github.com\/kyverno\/policies\">policy library<\/a> mit vielen Beispielen<\/li>\n<li>Sehr gute <a href=\"https:\/\/kyverno.io\/docs\/\">Dokumentation<\/a><\/li>\n<li>Unterst\u00fctzt mutating Policies<\/li>\n<li>Kyverno unterst\u00fctzt ebenfalls einen Audit-Modus und generiert daraus <a href=\"https:\/\/github.com\/kubernetes-sigs\/wg-policy-prototypes\/blob\/master\/policy-report\/README.md\">PolicyReports<\/a>:\u00a0 <span class=\"lang:default decode:true crayon-inline \">kubectl get policyreport &#8211;all-namespaces<\/span><\/li>\n<\/ul>\n<p>Mit kyverno-cli kann man komfortabel seine Regel-Konfiguration testen mit <span class=\"lang:default decode:true crayon-inline \">kyverno validate &lt;file&gt;<\/span> oder <span class=\"lang:default decode:true crayon-inline \">kyverno apply &lt;policy&gt; &#8211;resource &lt;yaml&gt;<\/span><\/p>\n<p>Bis vor Kurzem konnte Kyverno noch nicht hochverf\u00fcgbar betrieben werden, HA ist aber mit Version 1.4.0 gekommen (<a href=\"https:\/\/github.com\/kyverno\/kyverno\/issues?q=label%3AHA\">Github issues<\/a>), die kurz vor diesem Blogartikel erschienen ist.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"k-rail\"><\/span>k-rail<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><a href=\"https:\/\/github.com\/cruise-automation\/k-rail\">k-rail<\/a> ist ein eher kleineres Projekt:<\/p>\n<ul>\n<li>Hat einen Monitor-Modus<\/li>\n<li>Hat eine Reihe von eingebauten Regeln, erweiterbar \u00fcber go Plugins<\/li>\n<li>Ist vergleichsweise wenig komplex<\/li>\n<li>Die Dokumentation ist nicht besonders ausf\u00fchrlich (es existiert quasi nur eine README)<\/li>\n<\/ul>\n<p>k-rails bietet deutlich weniger Features als OPA oder Kyverno, daf\u00fcr kann es aber auch eine deutlich geringere Komplexit\u00e4t und wir wollen im Vergleich herausfinden, ob es sich vielleicht als einfaches Tool eignet, um genau den PSP Controller zu ersetzen.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Szenarien\"><\/span>Szenarien<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<h3><span class=\"ez-toc-section\" id=\"Einfach-PodSecurityPolicies-ersetzen\"><\/span>Einfach PodSecurityPolicies ersetzen<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>In der folgenden Tabelle ist aufgef\u00fchrt, welches Tool welche Teile einer PSP abdeckt, indem man nur mitgelieferte Beispiele verwendet. Also quasi: wie viel einer PSP kann man mit dem Tool ohne Mehraufwand abdecken:<\/p>\n<table style=\"height: 876px;\" width=\"952\">\n<tbody>\n<tr style=\"height: 24px;\">\n<td style=\"height: 24px; width: 425px;\">PSP Aspekt<\/td>\n<td style=\"height: 24px; width: 210px;\">OPA Gatekeeper<\/td>\n<td style=\"height: 24px; width: 137px;\">Kyverno<\/td>\n<td style=\"height: 24px; width: 152px;\">k-rail<\/td>\n<td style=\"height: 24px; width: 152px;\">PSP Replacement<br \/>\n(voraussichtlich)<\/td>\n<\/tr>\n<tr style=\"height: 24px;\">\n<td style=\"height: 24px; width: 425px;\">privileged<\/td>\n<td style=\"height: 24px; width: 210px;\">\u2713<\/td>\n<td style=\"height: 24px; width: 137px;\">\u2713<\/td>\n<td style=\"height: 24px; width: 152px;\">\u2713<\/td>\n<td style=\"height: 24px; width: 152px;\">\u2713 (baseline)<\/td>\n<\/tr>\n<tr style=\"height: 24px;\">\n<td style=\"height: 24px; width: 425px;\">hostPID, hostIPC<\/td>\n<td style=\"height: 24px; width: 210px;\">\u2713<\/td>\n<td style=\"height: 24px; width: 137px;\">\u2713<\/td>\n<td style=\"height: 24px; width: 152px;\">nur PID<\/td>\n<td style=\"height: 24px; width: 152px;\">\u2713(baseline)<\/td>\n<\/tr>\n<tr style=\"height: 24px;\">\n<td style=\"height: 24px; width: 425px;\">hostNetwork, hostPorts<\/td>\n<td style=\"height: 24px; width: 210px;\">\u2713<\/td>\n<td style=\"height: 24px; width: 137px;\">\u2713<\/td>\n<td style=\"height: 24px; width: 152px;\">network<\/td>\n<td style=\"height: 24px; width: 152px;\">\u2713 (baseline)<\/td>\n<\/tr>\n<tr style=\"height: 24px;\">\n<td style=\"height: 24px; width: 425px;\">volumes<\/td>\n<td style=\"height: 24px; width: 210px;\">\u2713<\/td>\n<td style=\"height: 24px; width: 137px;\">\u2713<\/td>\n<td style=\"height: 24px; width: 152px;\"><\/td>\n<td style=\"height: 24px; width: 152px;\">nur PVs erlaubt (restricted)<\/td>\n<\/tr>\n<tr style=\"height: 24px;\">\n<td style=\"height: 24px; width: 425px;\">allowedHostPaths<\/td>\n<td style=\"height: 24px; width: 210px;\">\u2713<\/td>\n<td style=\"height: 24px; width: 137px;\">komplett verboten<\/td>\n<td style=\"height: 24px; width: 152px;\">verboten f\u00fcr PVs, f\u00fcr docker socket oder komplett<\/td>\n<td style=\"height: 24px; width: 152px;\">komplett verboten (baseline)<\/td>\n<\/tr>\n<tr style=\"height: 24px;\">\n<td style=\"height: 24px; width: 425px;\">allowedFlexVolumes<\/td>\n<td style=\"height: 24px; width: 210px;\">\u2713<\/td>\n<td style=\"height: 24px; width: 137px;\">\u2713<\/td>\n<td style=\"height: 24px; width: 152px;\"><\/td>\n<td style=\"height: 24px; width: 152px;\">nur PVs erlaubt (restricted)<\/td>\n<\/tr>\n<tr style=\"height: 24px;\">\n<td style=\"height: 24px; width: 425px;\">fsGroup<\/td>\n<td style=\"height: 24px; width: 210px;\">nicht mutating *<\/td>\n<td style=\"height: 24px; width: 137px;\">nicht mutating *<\/td>\n<td style=\"height: 24px; width: 152px;\"><\/td>\n<td style=\"height: 24px; width: 152px;\">initial nicht implementiert<\/td>\n<\/tr>\n<tr style=\"height: 24px;\">\n<td style=\"height: 24px; width: 425px;\">readOnlyRootFilesystem<\/td>\n<td style=\"height: 24px; width: 210px;\">\u2713<\/td>\n<td style=\"height: 24px; width: 137px;\">\u2713(in best-practices)<\/td>\n<td style=\"height: 24px; width: 152px;\"><\/td>\n<td style=\"height: 24px; width: 152px;\"><\/td>\n<\/tr>\n<tr style=\"height: 24px;\">\n<td style=\"height: 24px; width: 425px;\">runAsUser, runAsGroup, supplementalGroups<\/td>\n<td style=\"height: 24px; width: 210px;\">nicht mutating *<\/td>\n<td style=\"height: 24px; width: 137px;\">nicht mutating *<\/td>\n<td style=\"height: 24px; width: 152px;\"><\/td>\n<td style=\"height: 24px; width: 152px;\">\u2713 (restricted) (Gruppen werden initial nicht implementiert sein)<\/td>\n<\/tr>\n<tr>\n<td style=\"width: 425px;\">allowPrivilegeEscalation, defaultAllowPrivilegeEscalation<\/td>\n<td style=\"width: 210px;\">\u2713<\/td>\n<td style=\"width: 137px;\">\u2713<\/td>\n<td style=\"width: 152px;\"><\/td>\n<td style=\"width: 152px;\">\u2713 (restricted)<\/td>\n<\/tr>\n<tr>\n<td style=\"width: 425px;\">defaultAddCapabilities, requiredDropCapabilities, allowedCapabilities<\/td>\n<td style=\"width: 210px;\">\u2713<\/td>\n<td style=\"width: 137px;\">verbiete &#8222;add&#8220;<\/td>\n<td style=\"width: 152px;\">verbiete &#8222;add&#8220;<\/td>\n<td style=\"width: 152px;\">feste Liste erlaubter Capabilities (baseline)<\/td>\n<\/tr>\n<tr>\n<td style=\"width: 425px;\">seLinux<\/td>\n<td style=\"width: 210px;\">\u2713<\/td>\n<td style=\"width: 137px;\">\u2713<\/td>\n<td style=\"width: 152px;\"><\/td>\n<td style=\"width: 152px;\">feste Liste erlaubter Werte (baseline)<\/td>\n<\/tr>\n<tr>\n<td style=\"width: 425px;\">allowedProcMountTypes<\/td>\n<td style=\"width: 210px;\">\u2713<\/td>\n<td style=\"width: 137px;\">default\u2713<\/td>\n<td style=\"width: 152px;\"><\/td>\n<td style=\"width: 152px;\">\u2713 (baseline)<\/td>\n<\/tr>\n<tr>\n<td style=\"width: 425px;\">AppArmor\/seccomp annotations<\/td>\n<td style=\"width: 210px;\">\u2713<\/td>\n<td style=\"width: 137px;\">&#8222;undefined&#8220; oder &#8222;default&#8220;<\/td>\n<td style=\"width: 152px;\">seccomp: immer &#8222;default&#8220; setzen, apparmor: verbiete &#8222;unconfined&#8220;<\/td>\n<td style=\"width: 152px;\">seccomp: verbiete &#8222;unconfined&#8220; (baseline), muss gesetzt sein (restricted), apparmor: verbiete &#8222;unconfined&#8220; (baseline)<\/td>\n<\/tr>\n<tr>\n<td style=\"width: 425px;\">forbiddenSysctls, allowedUnsafeSysctls<\/td>\n<td style=\"width: 210px;\">\u2713<\/td>\n<td style=\"width: 137px;\">\u2713<\/td>\n<td style=\"width: 152px;\"><\/td>\n<td style=\"width: 152px;\">feste\u00a0 Liste erlaubter Werte<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>* Der PSP Controller mutiert den Pod bei manchen Feldern, um default-Werte f\u00fcr manche Felder zu setzen, falls diese nicht explizit gesetzt sind. Die hier vorgestellten Admission Controller unterst\u00fctzen das nicht, k\u00f6nnen aber validieren, ob erlaubte Werte in den Feldern stehen.<\/p>\n<p>Quellen: Was die PSP Replacement Policy vermutlich erm\u00f6glichen wird, ist aus den <a href=\"https:\/\/kubernetes.io\/docs\/concepts\/security\/pod-security-standards\/\">Pod Security Standards<\/a> und dem <a href=\"https:\/\/github.com\/kubernetes\/enhancements\/tree\/master\/keps\/sig-auth\/2579-psp-replacement#pod-security-standards\">Kubernetes Enhancement Proposal<\/a> abgeleitet. F\u00fcr OPA-Gatekeeper gibt es eine <a href=\"https:\/\/github.com\/open-policy-agent\/gatekeeper-library\/blob\/master\/library\/pod-security-policy\/README.md\">Vergleichstabelle<\/a>, f\u00fcr Kyverno gibt es einen <a href=\"https:\/\/github.com\/kyverno\/policies\/tree\/main\/pod-security\">Ordner mit Pod Security Policies<\/a> in den Beispiel-Policies (mit Unterordnern, die den Pod Security Standards entsprechen) und f\u00fcr k-rails wurden die <a href=\"https:\/\/github.com\/cruise-automation\/k-rail\/tree\/master\/policies\">eingebauten Policies<\/a> analysiert.<\/p>\n<p>Wie man in der Tabelle schon sieht, kann k-rails knapp die H\u00e4lfte der F\u00e4lle nicht abdecken. Die anderen drei unterscheiden sich in Details, aber decken zumindest grob den kompletten Funktionsumfang einer PSP ab.<\/p>\n<h3><span class=\"ez-toc-section\" id=\"Komplexere-Szenarien\"><\/span>Komplexere Szenarien<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>Die Admission Controller k\u00f6nnen nat\u00fcrlich noch mehr au\u00dfer nur die PSP zu ersetzen.<\/p>\n<p>So k\u00f6nnen zum Beispiel nur Ingress-yamls zugelassen werden, deren Domain \u00fcberhaupt zum Cluster passt. Oder der Inhalt bestimmter ConfigMaps kann validiert werden (z. B., wenn darin Prometheus-Alerts definiert werden, die dieser zentral einsammelt). Oder es kann validiert werden, dass jeder Namespace ein Label mit der Kostenstelle tr\u00e4gt. Oder der Zeitstempel des letzten Apply soll automatisch annotiert werden. Oder ein bestimmter Service darf nur bei zunehmendem Mond ge\u00e4ndert werden.<\/p>\n<p>Okay, das letzte Beispiel war vielleicht nicht ganz realistisch, aber alle diese Beispiele lassen sich mit dynamischen Admission Webhooks umsetzen. Die meisten davon lassen sich auch mit den vorgestellten Admission Controllern umsetzen. Schwierig wird es, wenn entweder dynamische Daten von au\u00dferhalb n\u00f6tig sind (z. B. ein Abgleich mit einer Liste von Benutzer:innen) oder wenn die Validierung sehr komplex ist (z. B., ob eine ConfigMap eine valide Konfiguration enth\u00e4lt). In solchen komplizierten F\u00e4llen kann es sich auch lohnen, einen eigenen Admission Controller zu schreiben. Das ist gar nicht so kompliziert wie es klingt, ein Kollege bereitet schon einen Artikel f\u00fcr diesen Blog vor. Stay tuned &#8230;<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Fazit\"><\/span>Fazit<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Das Sch\u00f6ne ist, dass man nicht auf eine L\u00f6sung festgelegt ist: alle k\u00f6nnen beliebig kombiniert werden. Um die eigentliche PSP in den meisten mir bisher untergekommenen Clustern zu ersetzen ist die &#8222;PSP Replacement Policy&#8220; vollkommen ausreichend. Da sie schon mit Kubernetes mitkommt ist der Aufwand minimal und wird hoffentlich in mehr Clustern einfach mal angeschaltet. Daf\u00fcr bietet sie etwas weniger Flexibilit\u00e4t f\u00fcr komplexe Szenarien.<\/p>\n<p>Bei komplexeren Anforderungen k\u00f6nnen sowohl OPA Gatekeeper als auch Kyverno geeignet sein. Beide sind in diversen Projekten bei inovex im Einsatz und um es kurz zusammenzufassen: beide haben ihre kleinen Macken, aber funktionieren gut. Mich pers\u00f6nlich w\u00fcrde haupts\u00e4chlich die ungewohnte rego-Syntax und das komplizierte ContraintTemplate-Konstrukt vom OPA Gatekeeper abhalten, und eher zu Kyverno tendieren lassen. Denn der beste Admission Controller n\u00fctzt nichts, wenn er nicht verwendet wird.<\/p>\n<p>Ich freue mich sehr von Euren Erfahrungen in den Kommentaren lesen: Welche Policies habt Ihr? Welche Ecken nerven Euch an OPA, Kyverno oder einem der kommerziellen Admission Controller?<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Mit Kubernetes 1.21 wurden PodSecurityPolicies (PSP) abgek\u00fcndigt. Also Panik angesagt? Nein, die PSPs bleiben uns zuerst einmal erhalten und werden vermutlich erst in 1.25 entfernt.\u00a0Trotzdem ist es eine gute Gelegenheit sich schon jetzt nach Alternativen umzuschauen. In diesem Artikel konzentrieren wir uns auf drei Open-Source-Tools und die &#8222;PSP Replacement Policy&#8220;<\/p>\n","protected":false},"author":222,"featured_media":30845,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"ep_exclude_from_search":false,"footnotes":""},"tags":[114,101],"service":[423,879],"coauthors":[{"id":222,"display_name":"Simon Dreher","user_nicename":"sdreher"}],"class_list":["post-27821","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-kubernetes","tag-security","service-kubernetes","service-security"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.5 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Ersatz f\u00fcr Kubernetes PodSecurityPolicies - inovex GmbH<\/title>\n<meta name=\"description\" content=\"Wir beleuchten die Alternativen zu Kubernetes PodSecurityPolicies (PSP) mit Fokus auf Open-Source-L\u00f6sungen und der \u201ePSP Replacement Policy\u201c.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Ersatz f\u00fcr Kubernetes PodSecurityPolicies - inovex GmbH\" \/>\n<meta property=\"og:description\" content=\"Wir beleuchten die Alternativen zu Kubernetes PodSecurityPolicies (PSP) mit Fokus auf Open-Source-L\u00f6sungen und der \u201ePSP Replacement Policy\u201c.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/\" \/>\n<meta property=\"og:site_name\" content=\"inovex GmbH\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/inovexde\" \/>\n<meta property=\"article:published_time\" content=\"2021-07-09T11:24:50+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2022-11-21T14:50:55+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/kubernetes-podsecuritypolicies-ersatz.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1920\" \/>\n\t<meta property=\"og:image:height\" content=\"1080\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Simon Dreher\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/kubernetes-podsecuritypolicies-ersatz-1024x576.png\" \/>\n<meta name=\"twitter:creator\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:site\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:label1\" content=\"Verfasst von\" \/>\n\t<meta name=\"twitter:data1\" content=\"Simon Dreher\" \/>\n\t<meta name=\"twitter:label2\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data2\" content=\"9\u00a0Minuten\" \/>\n\t<meta name=\"twitter:label3\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data3\" content=\"Simon Dreher\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/ersatz-kubernetes-podsecuritypolicies-alternativen\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/ersatz-kubernetes-podsecuritypolicies-alternativen\\\/\"},\"author\":{\"name\":\"Simon Dreher\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/person\\\/ea57d51598890080b9613f52ca773b99\"},\"headline\":\"Ersatz f\u00fcr Kubernetes PodSecurityPolicies \u2013 passende Alternativen\",\"datePublished\":\"2021-07-09T11:24:50+00:00\",\"dateModified\":\"2022-11-21T14:50:55+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/ersatz-kubernetes-podsecuritypolicies-alternativen\\\/\"},\"wordCount\":1629,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/ersatz-kubernetes-podsecuritypolicies-alternativen\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/kubernetes-podsecuritypolicies-ersatz.png\",\"keywords\":[\"Kubernetes\",\"Security\"],\"articleSection\":[\"General\",\"Infrastructure\"],\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/ersatz-kubernetes-podsecuritypolicies-alternativen\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/ersatz-kubernetes-podsecuritypolicies-alternativen\\\/\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/ersatz-kubernetes-podsecuritypolicies-alternativen\\\/\",\"name\":\"Ersatz f\u00fcr Kubernetes PodSecurityPolicies - inovex GmbH\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/ersatz-kubernetes-podsecuritypolicies-alternativen\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/ersatz-kubernetes-podsecuritypolicies-alternativen\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/kubernetes-podsecuritypolicies-ersatz.png\",\"datePublished\":\"2021-07-09T11:24:50+00:00\",\"dateModified\":\"2022-11-21T14:50:55+00:00\",\"description\":\"Wir beleuchten die Alternativen zu Kubernetes PodSecurityPolicies (PSP) mit Fokus auf Open-Source-L\u00f6sungen und der \u201ePSP Replacement Policy\u201c.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/ersatz-kubernetes-podsecuritypolicies-alternativen\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/ersatz-kubernetes-podsecuritypolicies-alternativen\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/ersatz-kubernetes-podsecuritypolicies-alternativen\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/kubernetes-podsecuritypolicies-ersatz.png\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/kubernetes-podsecuritypolicies-ersatz.png\",\"width\":1920,\"height\":1080,\"caption\":\"Kubernetes Logo mit Vorh\u00e4ngeschloss\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/ersatz-kubernetes-podsecuritypolicies-alternativen\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Ersatz f\u00fcr Kubernetes PodSecurityPolicies \u2013 passende Alternativen\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#website\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\",\"name\":\"inovex GmbH\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\",\"name\":\"inovex GmbH\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2021\\\/03\\\/inovex-logo-16-9-1.png\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2021\\\/03\\\/inovex-logo-16-9-1.png\",\"width\":1921,\"height\":1081,\"caption\":\"inovex GmbH\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/inovexde\",\"https:\\\/\\\/x.com\\\/inovexgmbh\",\"https:\\\/\\\/www.instagram.com\\\/inovexlife\\\/\",\"https:\\\/\\\/www.linkedin.com\\\/company\\\/inovex\",\"https:\\\/\\\/www.youtube.com\\\/channel\\\/UC7r66GT14hROB_RQsQBAQUQ\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/person\\\/ea57d51598890080b9613f52ca773b99\",\"name\":\"Simon Dreher\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/3b3612ba5c850270d9d6c168fbfddbd6aa4ad65be3b681c8be256df8af2e024a?s=96&d=retro&r=ga87d9ca4dec0eec541f17c9505e738cd\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/3b3612ba5c850270d9d6c168fbfddbd6aa4ad65be3b681c8be256df8af2e024a?s=96&d=retro&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/3b3612ba5c850270d9d6c168fbfddbd6aa4ad65be3b681c8be256df8af2e024a?s=96&d=retro&r=g\",\"caption\":\"Simon Dreher\"},\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/author\\\/sdreher\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Ersatz f\u00fcr Kubernetes PodSecurityPolicies - inovex GmbH","description":"Wir beleuchten die Alternativen zu Kubernetes PodSecurityPolicies (PSP) mit Fokus auf Open-Source-L\u00f6sungen und der \u201ePSP Replacement Policy\u201c.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/","og_locale":"de_DE","og_type":"article","og_title":"Ersatz f\u00fcr Kubernetes PodSecurityPolicies - inovex GmbH","og_description":"Wir beleuchten die Alternativen zu Kubernetes PodSecurityPolicies (PSP) mit Fokus auf Open-Source-L\u00f6sungen und der \u201ePSP Replacement Policy\u201c.","og_url":"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/","og_site_name":"inovex GmbH","article_publisher":"https:\/\/www.facebook.com\/inovexde","article_published_time":"2021-07-09T11:24:50+00:00","article_modified_time":"2022-11-21T14:50:55+00:00","og_image":[{"width":1920,"height":1080,"url":"https:\/\/www.inovex.de\/wp-content\/uploads\/kubernetes-podsecuritypolicies-ersatz.png","type":"image\/png"}],"author":"Simon Dreher","twitter_card":"summary_large_image","twitter_image":"https:\/\/www.inovex.de\/wp-content\/uploads\/kubernetes-podsecuritypolicies-ersatz-1024x576.png","twitter_creator":"@inovexgmbh","twitter_site":"@inovexgmbh","twitter_misc":{"Verfasst von":"Simon Dreher","Gesch\u00e4tzte Lesezeit":"9\u00a0Minuten","Written by":"Simon Dreher"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#article","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/"},"author":{"name":"Simon Dreher","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/ea57d51598890080b9613f52ca773b99"},"headline":"Ersatz f\u00fcr Kubernetes PodSecurityPolicies \u2013 passende Alternativen","datePublished":"2021-07-09T11:24:50+00:00","dateModified":"2022-11-21T14:50:55+00:00","mainEntityOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/"},"wordCount":1629,"commentCount":0,"publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/kubernetes-podsecuritypolicies-ersatz.png","keywords":["Kubernetes","Security"],"articleSection":["General","Infrastructure"],"inLanguage":"de","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/","url":"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/","name":"Ersatz f\u00fcr Kubernetes PodSecurityPolicies - inovex GmbH","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#primaryimage"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/kubernetes-podsecuritypolicies-ersatz.png","datePublished":"2021-07-09T11:24:50+00:00","dateModified":"2022-11-21T14:50:55+00:00","description":"Wir beleuchten die Alternativen zu Kubernetes PodSecurityPolicies (PSP) mit Fokus auf Open-Source-L\u00f6sungen und der \u201ePSP Replacement Policy\u201c.","breadcrumb":{"@id":"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#primaryimage","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/kubernetes-podsecuritypolicies-ersatz.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/kubernetes-podsecuritypolicies-ersatz.png","width":1920,"height":1080,"caption":"Kubernetes Logo mit Vorh\u00e4ngeschloss"},{"@type":"BreadcrumbList","@id":"https:\/\/www.inovex.de\/de\/blog\/ersatz-kubernetes-podsecuritypolicies-alternativen\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.inovex.de\/de\/"},{"@type":"ListItem","position":2,"name":"Ersatz f\u00fcr Kubernetes PodSecurityPolicies \u2013 passende Alternativen"}]},{"@type":"WebSite","@id":"https:\/\/www.inovex.de\/de\/#website","url":"https:\/\/www.inovex.de\/de\/","name":"inovex GmbH","description":"","publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.inovex.de\/de\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":"Organization","@id":"https:\/\/www.inovex.de\/de\/#organization","name":"inovex GmbH","url":"https:\/\/www.inovex.de\/de\/","logo":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","width":1921,"height":1081,"caption":"inovex GmbH"},"image":{"@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/inovexde","https:\/\/x.com\/inovexgmbh","https:\/\/www.instagram.com\/inovexlife\/","https:\/\/www.linkedin.com\/company\/inovex","https:\/\/www.youtube.com\/channel\/UC7r66GT14hROB_RQsQBAQUQ"]},{"@type":"Person","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/ea57d51598890080b9613f52ca773b99","name":"Simon Dreher","image":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/secure.gravatar.com\/avatar\/3b3612ba5c850270d9d6c168fbfddbd6aa4ad65be3b681c8be256df8af2e024a?s=96&d=retro&r=ga87d9ca4dec0eec541f17c9505e738cd","url":"https:\/\/secure.gravatar.com\/avatar\/3b3612ba5c850270d9d6c168fbfddbd6aa4ad65be3b681c8be256df8af2e024a?s=96&d=retro&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/3b3612ba5c850270d9d6c168fbfddbd6aa4ad65be3b681c8be256df8af2e024a?s=96&d=retro&r=g","caption":"Simon Dreher"},"url":"https:\/\/www.inovex.de\/de\/blog\/author\/sdreher\/"}]}},"_links":{"self":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/27821","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/users\/222"}],"replies":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/comments?post=27821"}],"version-history":[{"count":7,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/27821\/revisions"}],"predecessor-version":[{"id":37770,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/27821\/revisions\/37770"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media\/30845"}],"wp:attachment":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media?parent=27821"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/tags?post=27821"},{"taxonomy":"service","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/service?post=27821"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/coauthors?post=27821"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}