Kyverno-guide: Blockera Kubernetes-fel i 13 Steg [2026]

Kyverno fyllde sex år i CNCF under 2026 och klev samtidigt upp till status som graduated-projekt, det högsta mognadssteget en CNCF-satsning kan nå. Samma år dök sex separata sårbarheter upp i verktyget, från ett SSRF-hål i CEL-baserade HTTP-anrop till en kritisk namnrymdseskalering som rättades i version 1.19.1. För team som kör Kubernetes i produktion är Kyverno i praktiken den policy-motor som avgör om en felkonfigurerad pod, en osignerad containeravbildning eller ett namespace utan nätverksregler ens tillåts starta. Den här guiden visar steg för steg hur du installerar Kyverno 1.19.1, skriver dina första regler och bygger ett komplett policy-paket som stoppar de vanligaste misstagen innan de når klustret.

Vad är Kyverno och varför behöver Kubernetes-kluster det 2026?

Kyverno är en policy-motor byggd för Kubernetes, och den stora skillnaden mot äldre alternativ är språket. Istället för att lära sig Rego, policyspråket bakom Open Policy Agent, skriver du regler som vanliga Kubernetes-resurser i YAML. Det sänker tröskeln rejält för plattformsteam som redan jobbar med manifest varje dag. Kyverno kopplar in sig som en admission-webhook, det nav i Kubernetes-API:et som granskar varje objekt innan det sparas i etcd. Där kan den validera, mutera, generera nya resurser eller verifiera att en containeravbildning är signerad, allt innan en pod ens får starta.

Projektet togs in i CNCF Sandbox den 10 november 2020 och flyttade till Incubating den 13 juli 2022. Statusen höjdes till Graduated den 16 mars 2026, med det officiella tillkännagivandet några dagar senare, den 24 mars. CNCF motiverade steget med bred produktionsanvändning och snabb tillväxt i communityn, snarare än en specifik siffra. Graduated är samma nivå som Kubernetes självt och Prometheus befinner sig på, och det signalerar att verktyget klarat en säkerhetsgranskning och visat sig stabilt i skarp drift hos flera organisationer. För dig som ska välja policy-verktyg inför 2027 är det en tydlig signal om att Kyverno inte är ett sidoprojekt längre.

Motivet bakom policy-motorer som Kyverno är sällan ett enda dramatiskt intrång, utan den långsamma ansamlingen av små avvikelser som till slut blir ett stort problem. Ett team glömmer resursgränser på en tjänst, ett annat kör en container som root för att en gammal avbildning kräver det, ett tredje lämnar ett namespace helt öppet för all intern trafik. Ingen av avvikelserna är i sig en katastrof, men tillsammans bygger de upp den typ av lateral rörelse-yta som angripare letar efter när de redan fått ett första fotfäste i klustret, till exempel via en sårbar applikation eller en läckt uppgift. Kyverno flyttar ansvaret för att upptäcka de avvikelserna från en människa som manuellt granskar manifest till en maskin som gör det vid varje enskild podskapande, dygnet runt.

Tekniskt sett registrerar Kyverno sig som två olika typer av admission-webhooks i klustret, en muterande och en validerande. Kubernetes anropar den muterande webhooken först för varje objekt som skapas eller ändras, vilket gör att mutate-regler kan fylla i standardvärden innan samma objekt sedan skickas vidare till den validerande webhooken. Generate-regler körs däremot asynkront efter att originalobjektet redan godkänts, eftersom de skapar helt nya, fristående resurser snarare än att ändra den som triggade regeln. Den ordningen, mutera, validera, generera, är värd att memorera eftersom den förklarar nästan alla överraskningar nya användare stöter på första veckan. Du kan skriva policyer både som ClusterPolicy, som gäller hela klustret, och som namespacade Policy-resurser för team som bara ska styra sin egen del av miljön. Det sistnämnda är praktiskt i stora organisationer där plattformsteamet äger grundreglerna men enskilda produktteam får lägga till egna, smalare regler ovanpå.

Sex sårbarheter och en CNCF-examen: Kyvernos år 2026

Ironin är svår att missa. Samma år som Kyverno graduerade i CNCF fick projektet sex registrerade sårbarheter, flera av dem allvarliga. Den mest kritiska, CVE-2026-100706, handlade om bristande validering av URL-kodade sökvägssegment i en Policy-regels apiCall-funktion. Felet kunde låta en tenant begränsad till ett namespace skapa objekt i andra namespace genom att missbruka admission-controllerns eget serviceaccount, en typ av eskalering som är extra farlig eftersom den utnyttjar verktyget som ska skydda klustret. Tabellen nedan sammanfattar årets sårbarheter.

CVE	Beskrivning	Drabbade versioner	Åtgärdad i
CVE-2026-100706	Eskalering via URL-kodade sökvägar i Policy apiCall urlPath	Före 1.19.1	1.19.1
CVE-2026-22039	Namnrymdseskalering via namespaced Policy apiCall	Före 1.16.3 / 1.15.3	1.16.3 / 1.15.3
CVE-2026-4789	SSRF via obegränsade CEL-baserade HTTP-funktioner	1.16.0 och senare	1.18.x (begränsade tokens)
CVE-2026-41323	Läckage av serviceaccount-token via apiCall-URL	CVSS 8,1, Hög	1.18.x
CVE-2026-39821	Sårbarhet i Go-beroendet x/net	Byggen före Go 1.26.6	1.19.1
CVE-2026-56853	Ytterligare sårbarhet löst via Go-uppdatering	Byggen före Go 1.26.6	1.19.1

Det gemensamma mönstret är tydligt. Flera av buggarna kretsar kring apiCall, funktionen som låter en policy hämta extern data under valideringen. Det är också en funktion många team aktiverar utan att läsa säkerhetskonsekvenserna noga. Slutsatsen är enkel, håll Kyverno uppdaterat och begränsa vilka policyer som får använda externa anrop. Vill du läsa mer om hur andra verktyg skyddar klustret i drift, snarare än vid admission, är vår genomgång av Falco för runtime-säkerhet i Kubernetes ett bra komplement till den här guiden.

Admission-controllern själv kör med ett serviceaccount som har ganska breda rättigheter i klustret, eftersom den behöver kunna läsa och ibland skapa resurser i alla namespace för att göra sitt jobb. Det är precis den egenskapen som CVE-2026-100706 och CVE-2026-22039 utnyttjade. En angripare behövde aldrig komma åt noden eller kringgå RBAC på vanligt sätt, det räckte att manipulera en apiCall-regel så att Kyvernos eget, mer priviligierade serviceaccount agerade åt dem i ett namespace de annars var utelåsta från. Lärdomen för plattformsteam är att behandla policy-motorn som en del av attackytan, inte bara som ett skyddslager. Granska vilka policyer som faktiskt använder apiCall, och fråga om varje sådan regel verkligen behöver gå utanför klustrets egna resurser.

Förkunskaper: verktyg och versioner du behöver

Du behöver inte vara Kubernetes-expert för att följa guiden, men några verktyg måste finnas på plats innan steg ett. Om klustret redan är hårdat enligt grunderna är det här ett naturligt nästa lager, se gärna vår guide om att härda ett Kubernetes-kluster om du inte redan gjort det grundarbetet.

Ett körande Kubernetes-kluster, lokalt via kind eller minikube, eller i molnet, med en version som finns i Kyvernos officiella kompatibilitetstabell. Ett tomt testkluster räcker gott för hela guiden.
Helm 3 installerat och konfigurerat mot klustret. Kyverno distribueras som ett Helm-chart, och tidigare versioner av Helm saknar stöd för en del av de nyare chart-funktionerna.
kubectl, matchat mot klusterversionen, med cluster-admin-rättigheter för installationen. Admission-webhooks och CRD:er kräver klusteromfattande behörighet att skapa.
Kyverno CLI version 1.19.1, samma version som admission-controllern, för att testa policyer lokalt innan de når klustret. En versionsskillnad mellan CLI och controller kan ge falska positiva resultat vid test.
Cosign, om du tänker följa steget om signaturverifiering av containeravbildningar. Verktyget behövs för att skapa och verifiera nyckelparet som policyn i steg tolv hänvisar till.
Minst 15 minuter overhead i klustrets CPU och minne för Kyvernos egna pods, de behöver resurser precis som allt annat. Räkna med fyra separata controller-pods som vardera behöver eget minne.
Ett git-repo där policyerna kan versionshanteras tillsammans med övrig infrastrukturkod, om du tänker bygga det kompletta projektet i slutet av guiden.

En sak till innan du börjar. Testa alltid i ett icke-produktionskluster först. Kyverno kan i teorin blockera varje ny deployment i hela klustret om en policy skrivs fel och sätts i enforce-läge direkt. Det händer varje vecka någonstans i världen, och det är helt undvikbart med den testordning vi går igenom nedan.

Kyverno jämfört med OPA/Gatekeeper

De två dominerande policy-motorerna för Kubernetes löser samma problem på olika sätt. Gatekeeper bygger på Open Policy Agent och Rego, ett generellt policyspråk som även används utanför Kubernetes, till exempel för API-gatewayer och CI/CD-pipelines. Kyverno är istället Kubernetes-native rakt igenom, policyerna är Kubernetes-resurser och körs utan ett separat språk att lära sig. Det gör Kyverno snabbare att komma igång med för ett team som redan tänker i YAML, medan Gatekeeper kan vara ett bättre val om organisationen redan standardiserat på Rego för andra system.

Egenskap	Kyverno	OPA/Gatekeeper
Policyspråk	Kubernetes YAML-resurser	Rego
Inlärningskurva	Låg för team som redan använder manifest	Högre, kräver Rego-kunskap
Mutate-regler	Inbyggt	Kräver tilläggskomponenter
Generate-regler	Inbyggt	Saknas nativt
Bildsignaturverifiering	Inbyggt via verifyImages	Kräver extern integration
CNCF-status	Graduated sedan mars 2026	Del av OPA-ekosystemet, egen livscykel

De flesta team landar på ett av verktygen snarare än båda, eftersom de täcker samma admission-steg i Kubernetes-flödet. Resten av guiden fokuserar på Kyverno, men principerna om audit-läge innan enforce, och om att testa i CI innan produktion, gäller lika mycket om du istället väljer Gatekeeper. Byter du från Gatekeeper till Kyverno, eller tvärtom, räkna med att skriva om regelverket från grunden snarare än att försöka översätta Rego till YAML eller vice versa, de två språken resonerar helt olika kring villkor och undantag.

Policy as code som efterlevnadsfråga för svenska och nordiska bolag

För organisationer som omfattas av NIS2 är policy as code inte bara en teknisk bekvämlighet. Lagstiftningen kräver dokumenterade, verifierbara processer för hur säkerhetskrav upprätthålls i drift, och ett manuellt granskat Kubernetes-manifest uppfyller det kravet sämre än en policy som maskinellt blockerar avvikelser varje gång en resurs skapas. Med Kyverno på plats kan ett säkerhetsteam visa en revisor exakt vilka regler som gällde vid en given tidpunkt genom att peka på en specifik commit i git, snarare än att försöka rekonstruera vad som egentligen tilläts den dagen en incident inträffade.

Policyreports, de rapporter Kyverno genererar automatiskt för varje regelbrott, blir i praktiken en löpande logg över klustrets säkerhetsstatus. Den går att exportera, arkivera och visa upp vid en revision utan extra verktyg. Kombinerat med att varje policy ligger versionshanterad i samma repo som övrig infrastrukturkod får du en spårbarhetskedja som sträcker sig hela vägen från en ändrad rad i en YAML-fil till vilken specifik pod som nekades eller flaggades i klustret. Det är ett starkare bevisläge än de flesta manuella granskningsprocesser kan erbjuda, och det är ett skäl till att fler nordiska plattformsteam har börjat efterfråga policy-motorer som en del av sitt NIS2-arbete under 2026.

Steg 1–3: Installera Kyverno 1.19.1 med Helm

Installationen sker i tre korta kommandon. Först lägger du till Kyvernos Helm-repo, sedan uppdaterar du repo-listan lokalt, och till sist installerar du själva controllern i ett eget namespace. Att isolera Kyverno i ett dedikerat namespace gör det enklare att övervaka resursanvändning och sätta egna RBAC-regler för just den komponenten. Helm är det rekommenderade installationssättet eftersom charten hanterar RBAC, CRD:er och de fyra controller-deploymenten i rätt ordning åt dig. Det går att installera via rena kubectl-manifest också, men då måste du själv hålla reda på beroendeordningen mellan CRD:er och controllrar, vilket sällan är värt besväret jämfört med ett enda Helm-kommando.

# Steg 1: lägg till Helm-repot
helm repo add kyverno https://kyverno.github.io/kyverno/

# Steg 2: uppdatera lokala repo-listor
helm repo update

# Steg 3: installera Kyverno 1.19.1 i eget namespace
helm install kyverno kyverno/kyverno \
  --namespace kyverno \
  --create-namespace \
  --version 1.19.1

Installationen tar vanligtvis under en minut på ett litet testkluster. Om du kör i ett kluster med strikta nätverkspolicyer sedan tidigare, kontrollera att admission-webhooken kan nå Kubernetes API-servern utan att blockeras av en egen regel, det är en klassisk fallgrop som vi återkommer till längre fram.

Ska du senare uppgradera till en nyare patchversion räcker ett helm upgrade-kommando med samma flaggor, och vill du ta bort Kyverno helt, till exempel i ett testkluster du river efteråt, går det med helm uninstall. Från version 1.19 flyttades CRD-hanteringen till ett separat chart som heter kyverno-api, vilket styrs av värdet crds.install. Glömmer du det värdet vid en uppgradering är det den vanligaste orsaken till att CRD:er plötsligt saknas efter en versionsändring, ett problem vi återkommer till i felsökningsavsnittet.

# Uppgradera till en senare patchversion
helm upgrade kyverno kyverno/kyverno \
  --namespace kyverno \
  --version 1.19.1 \
  --set crds.install=true

# Avinstallera helt, till exempel i ett testkluster
helm uninstall kyverno --namespace kyverno

Steg 4: Verifiera installationen

Innan du skriver en enda policy, bekräfta att alla delar av Kyverno startat korrekt. Fyra kontroller räcker för att känna sig trygg, podstatus, CRD:er, deployment-status och loggarna från controllern.

kubectl get pods --namespace kyverno
kubectl get crds | grep kyverno
kubectl wait --namespace kyverno \
  --for=condition=Available deployment --all --timeout=180s
kubectl logs --namespace kyverno \
  -l app.kubernetes.io/part-of=kyverno --all-containers=true

Ett lyckat resultat ser ut ungefär så här för pod-kommandot:

NAME                                      READY   STATUS    RESTARTS   AGE
kyverno-admission-controller-7d9f8c       1/1     Running   0          45s
kyverno-background-controller-5b7c9d      1/1     Running   0          45s
kyverno-cleanup-controller-9f6a4b         1/1     Running   0          45s
kyverno-reports-controller-3c2d1e         1/1     Running   0          45s

Fyra separata controllrar är normalt sedan Kyverno delade upp admission, bakgrundsskanning, rapportering och städning i egna processer. Ser du färre pods eller en som fastnar i CrashLoopBackOff, gå direkt till felsökningsavsnittet längre ner innan du fortsätter.

Varje controller har ett eget ansvar, och att förstå rollerna gör felsökning enklare senare. Admission-controllern är den som faktiskt pratar med Kubernetes-API:et i realtid och fattar beslut om varje ny resurs. Bakgrundscontrollern skannar resurser som redan finns i klustret mot policyer, vilket är hur du upptäcker avvikelser som fanns innan en policy infördes. Rapportcontrollern samlar resultat från båda i de policyreports vi använder senare i guiden, och städcontrollern hanterar schemalagd rensning av resurser som markerats för borttagning via separata CleanupPolicy-regler. Fastnar en av de fyra i väntläge, kontrollera alltid den specifika containerns logg istället för att bara läsa en samlad statusrad.

Steg 5–7: Skriv, testa och aktivera din första valideringspolicy

Första policyn ska kräva att varje container deklarerar CPU- och minnesgränser. Det är ett av de vanligaste produktionsproblemen i Kubernetes-kluster, en enda pod utan gränser kan äta upp en hel nods resurser och tränga undan allt annat. Skapa filen require-resources.yaml och börja i audit-läge, aldrig i enforce direkt.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resources
spec:
  validationFailureAction: Audit
  background: true
  rules:
    - name: require-resources
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Varje container måste ange CPU- och minnesgränser."
        pattern:
          spec:
            containers:
              - resources:
                  requests:
                    cpu: "?*"
                    memory: "?*"
                  limits:
                    cpu: "?*"
                    memory: "?*"

Lägg in policyn med kubectl apply -f require-resources.yaml och skapa sedan en test-pod utan resursgränser. I audit-läge accepteras podden, men en avvikelserapport skapas i bakgrunden. Kontrollera resultatet med kubectl get policyreport -A. Ser rapporten rimlig ut, redigera filen och byt validationFailureAction till Enforce, applicera igen, och testa samma dåliga pod en gång till. Den ska nu nekas direkt med ett meddelande som liknar detta:

Error from server: admission webhook "validate.kyverno.svc-fail" denied the request:
policy require-resources fail:
validation error: Varje container måste ange CPU- och minnesgränser.

Den här audit-till-enforce-rytmen är den enskilt viktigaste vanan att bygga in i teamet. Hoppa aldrig över audit-steget, oavsett hur självklar policyn känns.

Lägg märke till notationen "?*" i exemplet ovan. Det är Kyvernos egna villkorsoperatorer för mönstermatchning, skilda från vanlig YAML-syntax. Frågetecknet kräver att fältet finns och inte är tomt, medan asterisken fungerar som jokertecken för valfritt värde. Samma mönsterspråk används genomgående i validate-regler, och när du senare ser notationen =(fältnamn) i exemplet för privilegierade containrar betyder likhetstecknet att villkoret bara gäller om fältet faktiskt finns i resursen, annars hoppas kontrollen över. Det är en annan syntax än CEL, Common Expression Language, som Kyverno också stödjer i nyare, mer avancerade policytyper, något vi återkommer till i avsnittet om avancerade tips.

Steg 8–9: Blockera privilegierade pods och kräv icke-root-körning

Nästa lager handlar om rättigheter inne i containern. Privilegierade containrar och root-processer är en av de vanligaste vägarna ut ur en container och in i värdnoden vid ett intrång. Kyverno har färdiga communitypolicyer för det här, men att skriva en egen version ger bättre kontroll över felmeddelandet och vilka namespace som undantas.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-and-root
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: no-privileged-containers
      match:
        any:
          - resources:
              kinds:
                - Pod
      exclude:
        any:
          - resources:
              namespaces:
                - kube-system
      validate:
        message: "Privilegierade containrar är inte tillåtna."
        pattern:
          spec:
            =(securityContext):
              =(privileged): "false"
            containers:
              - =(securityContext):
                  =(privileged): "false"
    - name: require-non-root
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Containrar måste köra som icke-root."
        pattern:
          spec:
            securityContext:
              runAsNonRoot: true

Notera exclude-blocket för kube-system. Systemkomponenter i Kubernetes behöver ibland privilegierad åtkomst för att fungera, och att blockera dem av misstag är ett av de snabbaste sätten att lägga hela klustret i träda. Testa alltid policyn mot ett par av dina egna applikationer innan du rullar ut den brett.

Den här typen av regler överlappar delvis med Kubernetes egna Pod Security Standards, de inbyggda nivåerna privileged, baseline och restricted som kan sättas som en etikett på namespace-nivå. Skillnaden är att Pod Security Standards bara kan acceptera eller neka, medan en Kyverno-policy även kan förklara exakt varför i ett anpassat felmeddelande, kombinera flera villkor i samma regel och i vissa fall mutera resursen till ett säkert standardläge istället för att neka den helt. Många team kör båda samtidigt, med Pod Security Standards som ett grundskydd på klusternivå och Kyverno för mer detaljerade, verksamhetsspecifika regler ovanpå.

Steg 10: Mutate-regler för automatiska standardvärden

Validering stoppar det som är fel, men mutate-regler fixar det automatiskt istället för att neka. Ett vanligt användningsfall är att se till att varje pod får en spårbar etikett, utan att varje utvecklingsteam behöver komma ihåg det manuellt.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-team-label
spec:
  rules:
    - name: add-team-label
      match:
        any:
          - resources:
              kinds:
                - Pod
      mutate:
        patchStrategicMerge:
          metadata:
            labels:
              managed-by: kyverno
              team: platform

Mutate-regler körs innan validate-regler i Kyvernos pipeline, vilket betyder att du kan sätta ett standardvärde och sedan validera mot det i samma svep. Det är ett kraftfullt mönster, men håll det enkelt i början, för många mutate-regler i rad gör det svårt att felsöka varför en pod till slut ser ut som den gör. Ett vanligt nybörjarmisstag är att låta flera olika policyer mutera samma fält i olika ordning, vilket gör slutresultatet svårt att förutsäga. Håll en mutate-regel per syfte och dokumentera i policynamnet vilket fält den rör, så slipper nästa person i teamet gissa.

Steg 11: Generate-regler för automatiska NetworkPolicies

Generate-regler skapar helt nya resurser när en annan resurs tillkommer. Den mest praktiska varianten är att automatiskt lägga en standardiserad NetworkPolicy i varje nytt namespace, så att ingen glömmer isolera trafiken. Utan en sådan regel är standardbeteendet i Kubernetes att all trafik tillåts mellan pods, vilket sällan är vad man vill ha i produktion.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: generate-default-network-policy
spec:
  rules:
    - name: generate-network-policy
      match:
        any:
          - resources:
              kinds:
                - Namespace
      generate:
        synchronize: true
        apiVersion: networking.k8s.io/v1
        kind: NetworkPolicy
        name: default-deny
        namespace: "{{request.object.metadata.name}}"
        data:
          spec:
            podSelector: {}
            policyTypes:
              - Ingress
              - Egress

synchronize: true håller den genererade resursen i synk om källpolicyn ändras senare. Vill du istället tillåta ett team att själva justera NetworkPolicy efter att den skapats, sätt den till false så kopplas länken mellan käll- och målresurs bort direkt.

Steg 12: Stoppa leveranskedjeattacker med signaturverifiering av avbildningar

Den sista och mest relevanta regeln ur ett leveranskedjeperspektiv är bildverifiering. Kyverno kan kräva att varje container som startar kommer från en avbildning signerad med en betrodd nyckel, till exempel genom Cosign och Sigstore. Har du inte satt upp signering av dina avbildningar ännu, börja med vår guide om att signera containeravbildningar med Cosign innan du aktiverar policyn nedan, annars blockeras allt du försöker deploya.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-signed-images
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-images
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "registry.example.com/*"
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      ERSATT_MED_DIN_COSIGN_PUBLIC_KEY
                      -----END PUBLIC KEY-----

Kombinera gärna den här regeln med en sårbarhetsskanning tidigare i pipelinen. Om du redan kör Trivy för containerskanning täcker de två verktygen olika risker, Trivy hittar kända sårbarheter i avbildningen, medan Kyverno garanterar att bara avbildningar från en betrodd källa över huvud taget tillåts starta.

Var sparsam med wildcard-mönster i imageReferences. Ett mönster som * utan registry-prefix verifierar tekniskt sett varje avbildning som matchar, men ger ingen verklig garanti om vilken källa som faktiskt godkänns. Skriv alltid ett specifikt registry-prefix, som i exemplet ovan, så att policyn bara omfattar avbildningar från er egen, kontrollerade sökväg. Tredjepartsavbildningar från publika register bör antingen undantas medvetet eller speglas till ert eget register och signeras om, snarare än att få ett implicit godkännande genom ett för brett mönster.

Steg 13: Testa policyer i CI/CD med Kyverno CLI

Det sista steget flyttar testningen från klustret till pipelinen, så att en trasig policy aldrig når produktion i första taget. Kyverno CLI körs utan ett riktigt kluster och validerar manifest mot dina policyer direkt i CI-jobbet.

# Testa en policy mot ett exempel-manifest lokalt
kyverno apply require-resources.yaml \
  --resource deployment.yaml

# Exempel på CI-steg (GitHub Actions-syntax)
- name: Testa Kyverno-policyer
  run: |
    kyverno apply policies/ --resource manifests/ --policy-report

Lägg det här steget tidigt i pipelinen, före bygg och innan artefakter publiceras. Ett misslyckat policytest ska stoppa merget, inte bara logga en varning som ingen läser. Det är skillnaden mellan policy as code som faktiskt styr beteende och policy as code som bara är dokumentation. Vill du bredda perspektivet till molnresurser utanför Kubernetes, kompletterar vår guide om Cloud Custodian för policy as code i molnet den här artikeln bra.

Övervaka Kyverno med policyreports och mått

En policy du inte övervakar är i praktiken en policy du inte vet fungerar. Kyverno exponerar Prometheus-kompatibla mått på admission-controllerns metrics-endpoint, inklusive hur många regler som nekat, godkänt eller mutat en resurs, samt hur lång tid varje policyutvärdering tar. De måtten är ovärderliga när du ska avgöra om en policy börjar påverka klustrets svarstider innan det blir ett produktionsproblem. Lägg in ett enkelt dashboard-mål för andelen nekade requests per policy, en plötslig topp brukar betyda att en ny applikation eller ett nytt team just stött på en regel de inte kände till.

# Lista alla policyreports i klustret, sorterat per namespace
kubectl get policyreport -A

# Visa detaljer för en specifik rapport, inklusive vilka regler som brutits
kubectl describe policyreport -n mitt-namespace

# Räkna hur många resurser som just nu bryter mot minst en policy
kubectl get policyreport -A -o json | \
  jq '[.items[].summary.fail] | add'

Policyreports uppdateras av bakgrundscontrollern på ett schema, inte i realtid, så räkna med en viss fördröjning mellan att en resurs ändras och att rapporten reflekterar det. För team som vill ha samma information i ett befintligt SIEM eller dashboard-system räcker det ofta att skrapa metrics-endpointen på samma sätt som för andra Kubernetes-komponenter, ingen separat exportör krävs.

Vanliga fallgropar när du inför Kyverno

Enforce från dag ett. Den vanligaste nybörjarfällan. Kör alltid i audit-läge minst en till två veckor innan du byter till enforce, och granska policyreport regelbundet under den perioden. Ett team som hoppar över det här steget upptäcker ofta problemet först när en release stoppas mitt i en deploy-fönster klockan fyra en fredag.
Glömt exkludera systemnamespace. En policy som blockerar privilegierade pods utan undantag för kube-system kan slå ut hela klustret, inklusive DNS och nätverksplugin. Återställning kräver ofta att du tillfälligt stänger av admission-webhooken helt för att kunna rätta policyn, så håll alltid en sådan nödkommandorad till hands innan du rullar ut en ny enforce-policy.
För breda match-regler. En regel som matchar alla Pod-resurser utan filter träffar även korta jobb och init-containrar som ofta har andra behov än långlivade tjänster. Smalna av matchningen med etiketter eller namespace-filter istället för att skriva undantag för varje specialfall efteråt.
Synkrona apiCall-anrop i varje validering. Externa anrop under admission ökar svarstiden för varenda podskapande i klustret, och vid hög belastning kan det orsaka timeouts som i sin tur blockerar helt legitima deployer. Flytta kontroller som inte måste ske i realtid till bakgrundsskanning istället.
Ingen versionskontroll på policyer. Policyer som bara finns som lösa YAML-filer i någons terminal försvinner när personen slutar. Lägg dem i git precis som annan infrastrukturkod, och låt en pull request-granskning gälla policyändringar lika strikt som ändringar i produktionskod.
Blandar ihop generate och mutate. Generate skapar nya, fristående resurser. Mutate ändrar resursen som redan matchas. Att förväxla dem leder ofta till dubblerade eller saknade objekt, och felet brukar visa sig först några dagar senare när någon undrar varför ett namespace saknar sin NetworkPolicy.
Otydliga felmeddelanden i policyn. Standardmeddelandet från en misslyckad validering är kort och tekniskt. Skriv alltid ett eget, konkret meddelande i message-fältet som talar till utvecklaren som faktiskt stötte på felet, inte bara till den som skrev policyn.

Felsökning: 8 vanliga fel och lösningar

Problem	Trolig orsak	Lösning
Webhook-timeout vid podskapande	Admission-controllern svarar inte inom tidsgränsen	Skala upp antal repliker, minska antal synkrona apiCall-regler
Policy blockerar oväntat allt	validationFailureAction satt till Enforce för tidigt	Återgå till Audit, granska policyreport innan nästa försök
CRD:er saknas efter uppgradering till 1.19	Dedikerad kyverno-api-chart installerades inte	Kör helm upgrade med crds.install=true uttryckligen satt
Pod skapas trots tydligt policybrott	Fel namespace exkluderat i match/exclude-blocket	Läs igenom exclude-sektionen rad för rad och testa i staging
Hög CPU-last på admission-controllern	Många regler med externa apiCall-anrop körs synkront	Flytta kontroller till bakgrundsskanning istället för admission
Signaturverifiering med Cosign misslyckas alltid	Fel publik nyckel eller fel registry-prefix i policyn	Testa cosign verify manuellt mot samma avbildning och nyckel
policyreport visar aldrig resultat	background: true saknas i policyn	Lägg till background: true och vänta in nästa skanningscykel
helm install hänger kvar vid create-namespace	Kyvernos serviceaccount saknar nödvändiga RBAC-rättigheter	Kontrollera ClusterRoleBindings innan du installerar om

De flesta av de här felen går att undvika helt genom att alltid testa nya policyer i audit-läge på ett icke-produktionskluster först, det återkommande temat genom hela guiden. Om du ändå hamnar i ett läge där ett helt kluster blockeras av en felaktig enforce-policy finns en nödutgång, skala ner admission-webhooken för Kyverno till noll repliker med kubectl scale deployment kyverno-admission-controller --replicas=0 -n kyverno. Det stänger av policy-kontrollen helt tills du hunnit rätta regeln, och bör bara användas som en tillfällig åtgärd, aldrig som ett permanent läge.

Avancerade tips och det färdiga policy-paketet

När grundpolicyerna är på plats och stabila finns det några steg kvar för att göra installationen produktionsmässig. Sätt rimliga värden för webhookens timeoutSeconds så att en tillfällig nätverksstörning inte blockerar hela klustret. Använd failurePolicy: Ignore för icke-kritiska policyer och Fail bara för de regler där ett nekat svar faktiskt ska stoppa deployen. Separera bakgrundsskanning från admission-tidskontroller så att tunga regler inte bromsar varje podskapande. Och nyttja Kyvernos policyexceptions för att hantera enstaka, motiverade undantag utan att behöva skriva om huvudpolicyn varje gång.

Ett tips för team som redan känner sig bekväma med den klassiska ClusterPolicy-formen är att börja utvärdera de nyare policytyperna ValidatingPolicy, ImageValidatingPolicy och GeneratingPolicy. De bygger på CEL, samma uttrycksspråk som Kubernetes egna inbyggda ValidatingAdmissionPolicy-resurser använder, och gör det möjligt att skriva mer komplexa villkor utan Kyvernos äldre mönstersyntax. De klassiska ClusterPolicy-reglerna som den här guiden bygger på fortsätter att fungera och underhållas, men om du planerar en längre investering i policy as code är det värt att läsa på om CEL-varianterna innan ni låser fast hela regelverket i det äldre formatet.

Slutligen, dokumentera varje policy med en kort kommentar om varför den finns, inte bara vad den gör. Sex månader senare är det nästan alltid lättare att minnas vad en regel kontrollerar än varför den en gång infördes, och den kontexten är precis det en revisor eller en ny kollega kommer att fråga om först.

Det färdiga projektet från den här guiden samlas naturligt i en mapp med sex filer, en per policy, plus en values-fil för Helm-installationen. En rimlig struktur är policies/require-resources.yaml, policies/disallow-privileged-and-root.yaml, policies/add-team-label.yaml, policies/generate-default-network-policy.yaml och policies/verify-signed-images.yaml, tillsammans med en ci/kyverno-test.yaml för pipelinejobbet. Checka in mappen i samma repo som klusterkonfigurationen, låt CI köra Kyverno CLI mot varje pull request, och rulla sedan ut hela paketet med ett enda kubectl apply -f policies/ mot klustret. Det ger dig ett reproducerbart, granskningsbart policy-lager som fungerar likadant i varje miljö, från utvecklingskluster till produktion.

Rulla ut paketet i etapper om du redan har ett produktionskluster i drift. Börja med de två mutate- och generate-policyerna, som aldrig nekar en deploy utan bara lägger till saknade standardvärden, innan du aktiverar de striktare valideringsreglerna i enforce-läge. Den ordningen ger teamet tid att vänja sig vid att policyreports dyker upp i vardagen, utan att samtidigt riskera stoppade releaser under samma period. När samtliga sex policyer körts i audit-läge minst en vecka utan oväntade träffar mot befintlig trafik är klustret redo för att växla samtliga till enforce.

Vanliga frågor

Är Kyverno gratis att använda?

Ja. Kyverno är öppen källkod under Apache 2.0-licensen och drivs som ett CNCF-projekt, utan licenskostnad för kärnfunktionerna. Det finns kommersiella supporterbjudanden från enskilda leverantörer runt projektet, men själva mjukvaran kostar ingenting att installera och köra i valfri skala.

Fungerar Kyverno med alla Kubernetes-distributioner?

Ja, eftersom Kyverno bygger på standardiserade admission-webhooks i Kubernetes-API:et fungerar den oavsett om klustret körs i EKS, AKS, GKE eller en lokal distribution som k3s. Kontrollera ändå alltid Kyvernos officiella kompatibilitetstabell för exakt vilka Kubernetes-versioner den aktuella Kyverno-versionen stödjer, eftersom stödet för äldre eller nyare API-versioner kan skilja sig mellan releaser.

Ersätter Kyverno RBAC eller NetworkPolicy?

Nej. Kyverno kompletterar RBAC och NetworkPolicy genom att automatisera och framtvinga dem, men den tar inte över den underliggande åtkomstkontrollen i Kubernetes. Tänk på Kyverno som ett lager som ser till att RBAC och nätverksregler faktiskt sätts upp korrekt varje gång, inte som en ersättning för dem.

Kan Kyverno blockera pods som redan körs?

Inte direkt. Admission-kontroller gäller vid skapandet av resursen. Befintliga resurser som bryter mot en policy flaggas istället i en policyreport via bakgrundsskanningen, och måste åtgärdas manuellt eller via ett separat städningsjobb som bygger på en egen CleanupPolicy-resurs.

Behöver jag både Kyverno och OPA/Gatekeeper?

Oftast inte. De löser samma problem på admission-nivå, och de flesta team väljer ett av verktygen för att undvika dubbla regelverk som kan motsäga varandra och göra felsökning svårare än den behöver vara.

Hur ofta behöver jag uppdatera Kyverno av säkerhetsskäl?

Utifrån mönstret under 2026, med flera patchversioner och version 1.19.1 släppt i september för att åtgärda två sårbarheter, är en rimlig rutin att följa projektets releaser löpande på GitHub och uppgradera inom veckor efter en säkerhetsrelevant patch, snarare än att vänta till nästa planerade underhållsfönster.

Kan Kyverno sänka prestandan i klustret?

Det beror helt på hur policyerna är skrivna. Enkla valideringsregler mot statiska mönster har minimal påverkan, medan många synkrona externa apiCall-anrop i admission-kedjan kan öka svarstiden märkbart vid hög podskapande-frekvens. Mät alltid admission-controllerns svarstider innan och efter en ny policy rullas ut i produktion.

Var hittar jag färdiga policyer att utgå från?

Kyverno-projektet publicerar ett bibliotek med färdiga, granskade policyer för vanliga säkerhetsbehov, som du kan anpassa istället för att skriva allt från grunden. Det är ofta snabbare att börja med en befintlig policy och trimma villkoren efter er miljö än att skriva en helt ny regel från ett tomt blad.

Kyverno 1.19.1: Stoppa 6 Kubernetes-CVE:er i 13 Steg [2026]