Kubernetes Admission Control 2026: Kyverno vs OPA Gatekeeper – Πλήρης Οδηγός Θωράκισης και Policy as Code

Ενημερώθηκε: 10 Ιουλίου 2026

Το Kubernetes admission control είναι το στάδιο του API server όπου κάθε αίτημα δημιουργίας ή τροποποίησης πόρου περνάει από validating και mutating webhooks πριν αποθηκευτεί στο etcd. Το 2026, οι δύο κυρίαρχες policy engines γι' αυτό το σημείο είναι το Kyverno (YAML-native, project του CNCF) και το OPA Gatekeeper (βασισμένο στη γλώσσα Rego). Στην πράξη, το Kyverno έχει γίνει η προεπιλογή για ομάδες που θέλουν να γράψουν πολιτικές γρήγορα, ενώ το Gatekeeper παραμένει επιλογή όπου υπάρχει ήδη κώδικας Rego σε άλλα σημεία της stack. Παρακάτω θα δεις όλες τις διαφορές, έτοιμα policies και pipeline snippets.

• Το Kyverno χρησιμοποιεί YAML CRDs, καλύπτει validation, mutation, generation και image verification σε ένα binary (χωρίς Rego).
• Το OPA Gatekeeper βασίζεται σε Rego και είναι ισχυρότερο για σύνθετη λογική που αγγίζει external data ή cross-resource queries.
• Από το Kubernetes 1.30+ υπάρχει native ValidatingAdmissionPolicy με CEL. Για απλές πολιτικές αντικαθιστά και τους δύο controllers.
• Και τα δύο εργαλεία επαληθεύουν υπογραφές Sigstore/cosign για container images, αλλά το Kyverno το κάνει out-of-the-box.
• Στο 2026 το OPA Gatekeeper παραμένει active project. Δεν έχει γίνει deprecated, αλλά ο ρυθμός features έχει επιβραδυνθεί σε σχέση με το Kyverno.
• Και τα δύο τρέχουν policy tests στο CI/CD μέσω των kyverno test και gator test, απαραίτητο βήμα πριν το merge.

Τι είναι το Kubernetes admission control;

Το admission control είναι μια αλυσίδα από admission controllers, plugins που ζουν μέσα στον kube-apiserver και εξετάζουν κάθε αίτημα αφού περάσει authentication και authorization, αλλά πριν γραφτεί στο etcd. Χωρίζονται σε δύο κατηγορίες: τα mutating (μπορούν να τροποποιήσουν το object, π.χ. να προσθέσουν sidecar container ή default labels) και τα validating (αποδέχονται ή απορρίπτουν το αίτημα χωρίς να το αλλάξουν).

Ενσωματωμένοι controllers όπως το PodSecurity, το ResourceQuota ή το NodeRestriction καλύπτουν βασικά σενάρια. Όταν όμως χρειάζεσαι custom λογική, π.χ. «απαγόρευσε images από registries εκτός λίστας», «απαίτησε readinessProbe σε κάθε Deployment», «μπλόκαρε privileged containers εκτός του kube-system», εκεί παίζουν οι εξωτερικοί admission webhooks. Ο kube-apiserver καλεί έναν HTTP endpoint που ζει σε έναν operator μέσα στο cluster και ο operator απαντά με allow/deny (και προαιρετικά με JSON patch αν είναι mutating). Kyverno και OPA Gatekeeper είναι ακριβώς αυτοί οι operators.

Στο DevSecOps context, το admission control είναι ο τελευταίος αυτόματος έλεγχος πριν το workload τρέξει: το σημείο όπου κόβεται ό,τι γλίτωσε από το scanner στο DevSecOps pipeline με SAST και secrets scanning. Στην πράξη το βάζω μαζί με image signing μέσω Sigstore/cosign και rootless containers για να έχω defense-in-depth από build μέχρι runtime. Έχω δουλέψει σε clusters όπου έλειπε αυτό το στάδιο και, πίστεψέ με, το πρώτο incident σε παίρνει από κάτω.

Kyverno vs OPA Gatekeeper: συγκριτικός πίνακας 2026

Πριν βουτήξουμε σε YAML, ας δούμε τις διαφορές συνοπτικά. Οι εκδόσεις αναφοράς: Kyverno 1.13 (Q1 2026) και Gatekeeper 3.18.

Χαρακτηριστικό	Kyverno 1.13	OPA Gatekeeper 3.18
Γλώσσα πολιτικής	YAML (Kubernetes-native)	Rego (μαθαίνεις νέα γλώσσα)
Καμπύλη μάθησης	Χαμηλή, γράφεις YAML που θυμίζει CRD	Μέτρια προς υψηλή, Rego συν ConstraintTemplate CRDs
Mutation policies	Ναι, native	Ναι (Assign/AssignMetadata), πιο περιορισμένη
Generation (auto-create πόρων)	Ναι, μοναδικό feature	Όχι
Image signature verification	Native με verifyImages	Απαιτεί external module
External data lookup	APICall και registries	Πολύ ισχυρότερο (data.inventory)
Policy testing CLI	kyverno test	gator test
Reporting (PolicyReport CRD)	Native, καλύτερο	Constraint status συν Gatekeeper Policy Manager
Memory footprint	~150 έως 250 MiB για μεσαία cluster	~200 έως 400 MiB
Επιλογή project maturity	CNCF Graduated (2024)	CNCF Incubating

Πώς εγκαθιστώ Kyverno σε production cluster;

Η πρόταση για production είναι Helm με το επίσημο chart, σε high-availability mode (3 replicas για το admission controller). Το quickstart YAML είναι μόνο για test clusters. Παρακάτω το αντίστοιχο snippet, όπως το τρέχω από pipeline (ποτέ από laptop):

# Προσθήκη Helm repository και εγκατάσταση σε namespace kyverno
helm repo add kyverno https://kyverno.github.io/kyverno/
helm repo update

helm upgrade --install kyverno kyverno/kyverno \
  --namespace kyverno --create-namespace \
  --version 3.3.0 \
  --set admissionController.replicas=3 \
  --set backgroundController.replicas=2 \
  --set reportsController.replicas=2 \
  --set cleanupController.replicas=2 \
  --set features.admissionReports.enabled=true \
  --set features.reports.chunkSize=1000 \
  --wait --timeout=5m

# Επιβεβαίωση ότι όλα τα components τρέχουν
kubectl -n kyverno get pods -l app.kubernetes.io/instance=kyverno
kubectl -n kyverno get validatingwebhookconfigurations

Δύο κρίσιμες ρυθμίσεις για production που ξεχνιούνται συχνά: failurePolicy: Fail στα webhooks (αλλιώς ένας αργός Kyverno pod ισοδυναμεί με σιωπηλή bypass των πολιτικών) και webhookConfiguration.matchConditions για να αποκλείσεις τα system namespaces από policy evaluation. Αλλιώς ο cluster autoscaler ή το CNI μπορεί να μπλοκάρει σε upgrade. Δες τα Kyverno installation docs για το πλήρες tuning.

Πολιτικές Kyverno: 5 έτοιμα examples για την pipeline

Τα παρακάτω είναι policies που εφαρμόζω σε σχεδόν κάθε cluster. Όλα ξεκινούν με validationFailureAction: Audit και προωθούνται σε Enforce μόνο αφού το reports controller έχει καθαρίσει.

1. Απαγόρευση images από registries εκτός allowlist

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: validate-registries
      match:
        any:
          - resources:
              kinds: [Pod]
      validate:
        message: "Επιτρέπονται μόνο images από ghcr.io/mycorp ή registry.gitlab.com/mycorp."
        pattern:
          spec:
            containers:
              - image: "ghcr.io/mycorp/* | registry.gitlab.com/mycorp/*"
            =(initContainers):
              - image: "ghcr.io/mycorp/* | registry.gitlab.com/mycorp/*"

2. Απαίτηση για readiness και liveness probes

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-probes
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-probes
      match:
        any:
          - resources:
              kinds: [Deployment, StatefulSet]
              namespaceSelector:
                matchExpressions:
                  - {key: kubernetes.io/metadata.name, operator: NotIn, values: [kube-system, kyverno]}
      validate:
        message: "Deployments πρέπει να έχουν readinessProbe και livenessProbe."
        pattern:
          spec:
            template:
              spec:
                containers:
                  - readinessProbe:
                      "?*": "?*"
                    livenessProbe:
                      "?*": "?*"

3. Enforce των Pod Security Standards (restricted)

Το επίσημο Kyverno policy set έχει έτοιμο όλο το restricted profile. Το εγκαθιστώ ως εξής:

# Εγκατάσταση του pod-security policy set (v1.13 compatible)
kubectl apply -f https://raw.githubusercontent.com/kyverno/policies/main/pod-security/restricted.yaml

# Επιλεκτική εξαίρεση namespace που τρέχει legacy workload
kubectl label ns legacy-app kyverno.io/exclude=true

4. Μπλοκάρισμα του latest tag

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds: [Pod]
      validate:
        message: "Το image tag πρέπει να είναι εκτός από 'latest' και όχι κενό."
        pattern:
          spec:
            containers:
              - image: "!*:latest & *:*"

5. Auto-generate NetworkPolicy για κάθε νέο namespace

Αυτό είναι το χαρακτηριστικό που δεν το βρίσκεις στο Gatekeeper. Ειλικρινά, ήταν από τα πράγματα που με έπεισαν να μεταφέρω δύο clusters από Gatekeeper σε Kyverno πέρσι.

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

Εγκατάσταση OPA Gatekeeper και πολιτικές σε Rego

Το Gatekeeper χωρίζει την πολιτική σε δύο πράγματα: το ConstraintTemplate (η λογική σε Rego, γίνεται CRD) και το Constraint (το instance που ενεργοποιεί το template με συγκεκριμένες παραμέτρους). Είναι πιο verbose από το Kyverno, αλλά ο διαχωρισμός δίνει reusability.

# Εγκατάσταση Gatekeeper με Helm
helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm repo update

helm upgrade --install gatekeeper gatekeeper/gatekeeper \
  --namespace gatekeeper-system --create-namespace \
  --version 3.18.0 \
  --set replicas=3 \
  --set audit.replicas=1 \
  --set auditInterval=60 \
  --set constraintViolationsLimit=100 \
  --set enableExternalData=true \
  --set validatingWebhookFailurePolicy=Fail \
  --wait --timeout=5m

Το ίδιο σενάριο «απαγόρευση images εκτός allowlist» σε Rego συν Gatekeeper:

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8sallowedrepos
spec:
  crd:
    spec:
      names:
        kind: K8sAllowedRepos
      validation:
        openAPIV3Schema:
          type: object
          properties:
            repos:
              type: array
              items: {type: string}
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sallowedrepos
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not startswith_any(container.image, input.parameters.repos)
          msg := sprintf("Container image %v δεν είναι σε επιτρεπόμενο repo.", [container.image])
        }
        startswith_any(str, prefixes) {
          startswith(str, prefixes[_])
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: prod-allowed-repos
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: [Pod]
    excludedNamespaces: [kube-system, gatekeeper-system]
  parameters:
    repos:
      - "ghcr.io/mycorp/"
      - "registry.gitlab.com/mycorp/"

Δύο αράδες YAML έγιναν 30, κι αυτό είναι το tradeoff. Σε αντάλλαγμα, το ConstraintTemplate μπορείς να το ξαναχρησιμοποιήσεις σε 20 clusters με διαφορετικές allowlists χωρίς να ξαναγράψεις τη λογική. Το επίσημο Gatekeeper documentation έχει πλήρες Rego reference.

ValidatingAdmissionPolicy με CEL: ο ενσωματωμένος τρόπος

Από το Kubernetes 1.30 (GA), υπάρχει και τρίτη επιλογή που δεν χρειάζεται καθόλου operator: το ValidatingAdmissionPolicy με έκφραση σε Common Expression Language (CEL). Τρέχει μέσα στον kube-apiserver, οπότε δεν έχει network hop, δεν έχει pods να συντηρήσεις, και δεν πέφτει αν πέσει κάποιο pod. Το tradeoff: μόνο validation (όχι mutation ή generation), και σύνθετη λογική με external data δεν παίζει.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: disallow-privileged
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups:   [""]
        apiVersions: ["v1"]
        operations:  ["CREATE", "UPDATE"]
        resources:   ["pods"]
  validations:
    - expression: "!object.spec.containers.exists(c, c.securityContext.?privileged == optional.of(true))"
      message: "Privileged containers δεν επιτρέπονται."
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: disallow-privileged-binding
spec:
  policyName: disallow-privileged
  validationActions: [Deny, Audit]
  matchResources:
    namespaceSelector:
      matchExpressions:
        - {key: kubernetes.io/metadata.name, operator: NotIn, values: [kube-system]}

Στα δικά μου clusters, χρησιμοποιώ τον εξής απλό κανόνα: απλά validation rules πάνε σε ValidatingAdmissionPolicy με CEL. Οτιδήποτε χρειάζεται mutation, generation ή image signature verification πάει σε Kyverno. Rego μόνο αν υπάρχει ήδη Rego σε άλλα κομμάτια της stack (π.χ. Envoy, Terraform Cloud). Περισσότερα στο upstream ValidatingAdmissionPolicy docs.

Επαλήθευση container image signatures με cosign

Ο πιο συχνός λόγος που κάποιος επιλέγει Kyverno το 2026 είναι το native image verification. Παίρνει υπογραφές Sigstore/cosign και μπλοκάρει pods με ανυπόγραφα ή κακά υπογεγραμμένα images, χωρίς πρόσθετο controller. Παράδειγμα με keyless verification (OIDC identity από τη CI/CD):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signatures
spec:
  validationFailureAction: Enforce
  webhookTimeoutSeconds: 30
  rules:
    - name: verify-cosign
      match:
        any:
          - resources:
              kinds: [Pod]
      verifyImages:
        - imageReferences:
            - "ghcr.io/mycorp/*"
          attestors:
            - entries:
                - keyless:
                    subject: "https://github.com/mycorp/*/.github/workflows/*"
                    issuer: "https://token.actions.githubusercontent.com"
                    rekor:
                      url: https://rekor.sigstore.dev
          mutateDigest: true
          verifyDigest: true
          required: true

Το mutateDigest: true μετατρέπει tags σε immutable digests μετά την επιτυχή επαλήθευση. Έτσι δεν έχεις race conditions με image mutation μεταξύ signature check και pod start. Στο container security guide έχω το build-side snippet για την cosign υπογραφή στο GitHub Actions που ταιριάζει με αυτό το policy. Αν θέλεις να δεις πώς αυτό δένει με ευρύτερα runtime controls, ρίξε μια ματιά και στο eBPF runtime security με Tetragon και Falco.

Testing πολιτικών στο CI/CD pipeline

Δεν υπάρχει χειρότερο pipeline από αυτό που περνάει τα builds αλλά ο cluster απορρίπτει τα deployments στη μέση της νύχτας. Το testing των policies πρέπει να τρέχει πριν τα YAMLs φτάσουν στο cluster. Και τα δύο εργαλεία έχουν CLI για dry-run.

Για Kyverno, στήνω ένα kyverno-test.yaml με sample resources και προσδοκίες, μετά τρέχει στο GitHub Actions:

# .github/workflows/kyverno-policy-test.yaml
name: Kyverno Policy Test

on:
  pull_request:
    paths: ["policies/**", "tests/**"]

jobs:
  policy-test:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4

      - name: Install Kyverno CLI
        run: |
          curl -sSL https://github.com/kyverno/kyverno/releases/download/v1.13.0/kyverno-cli_v1.13.0_linux_x86_64.tar.gz | tar -xz
          sudo mv kyverno /usr/local/bin/

      - name: Run policy tests
        run: kyverno test ./tests --detailed-results

      - name: Apply policies to sample manifests (dry-run)
        run: |
          kyverno apply ./policies \
            --resource ./samples/*.yaml \
            --policy-report \
            --audit-warn

Για Gatekeeper, το ισοδύναμο τρέχει με gator. Συνιστώ να αποτυχαίνει το build αν βρεθεί έστω και ένα violation:

# Στο ίδιο workflow, εναλλακτικά για Gatekeeper users
- name: Install gator CLI
  run: |
    curl -sSL https://github.com/open-policy-agent/gatekeeper/releases/download/v3.18.0/gator-v3.18.0-linux-amd64.tar.gz | tar -xz
    sudo mv gator /usr/local/bin/

- name: Test Gatekeeper policies
  run: |
    gator test \
      --filename=./constraints/ \
      --filename=./templates/ \
      --filename=./samples/ \
      --output=table

Είναι το OPA Gatekeeper deprecated; Ποιο να διαλέξω το 2026;

Όχι, το OPA Gatekeeper δεν είναι deprecated. Παραμένει active CNCF Incubating project με release 3.18 στο πρώτο μισό του 2026 και σταθερή upstream ροή commits. Παρόλα αυτά, η ταχύτητα release για νέα features (native image signing, αυτόματα PolicyReports, policy exceptions) έχει επιβραδυνθεί σε σχέση με το Kyverno, που έγινε CNCF Graduated project το 2024 και τραβάει σαφώς μεγαλύτερη κοινότητα το τελευταίο 18μηνο.

Ο δικός μου pragmatic decision tree για το 2026:

• Νέο cluster, κανένας από την ομάδα δεν ξέρει Rego: Kyverno. Θα γράφεις πολιτικές την ίδια μέρα.
• Χρειάζεσαι mutation, generation ή image signing: Kyverno (native), όχι Gatekeeper με add-ons.
• Υπάρχει ήδη Rego σε Envoy, Terraform Cloud ή Conftest: Gatekeeper για συνέπεια εργαλείων.
• Πολύ σύνθετη λογική με external data ή cross-resource queries: Gatekeeper, το Rego είναι πιο ισχυρό.
• 2 έως 3 απλά validation rules και τίποτε άλλο: ValidatingAdmissionPolicy με CEL, χωρίς κανένα operator.

Πραγματικά μεγάλες ομάδες συχνά τρέχουν και τα δύο ταυτόχρονα. Gatekeeper για platform-level guardrails που άλλαξαν πριν χρόνια και δεν πειράζουν, Kyverno για νέες πολιτικές που εξελίσσονται. Δεν είναι το τέλος του κόσμου, αν κρατήσεις τα scopes καθαρά. Απλώς πρόσεχε τη σειρά των webhooks με το reinvocationPolicy (έμαθα να το ελέγχω με το χέρι μετά από ένα ολονύχτιο incident).

Συχνές ερωτήσεις

Πώς εγκαθιστώ το Kyverno σε ένα νέο Kubernetes cluster;

Χρησιμοποίησε το επίσημο Helm chart σε high-availability mode: helm upgrade --install kyverno kyverno/kyverno -n kyverno --create-namespace --set admissionController.replicas=3. Για production πάντα ρύθμισε failurePolicy: Fail και ξεκίνα τις πολιτικές σε Audit mode για μία εβδομάδα πριν πας σε Enforce.

Είναι το Kyverno καλύτερο από το OPA;

Για Kubernetes-only χρήση και ομάδες χωρίς Rego experience, ναι, το Kyverno είναι πιο εύκολο και καλύπτει mutation, generation και image signing εξ αρχής. Το OPA/Gatekeeper είναι καλύτερο όταν χρειάζεσαι πολύπλοκη λογική με external data ή έχεις ήδη Rego σε άλλα εργαλεία (Envoy, Terraform).

Τι αντικαθιστά το OPA Gatekeeper στο Kubernetes 1.30+;

Για απλά validation rules, το native ValidatingAdmissionPolicy με CEL αντικαθιστά και τα δύο external tools, χωρίς να χρειάζεται operator. Τρέχει μέσα στον kube-apiserver. Για mutation, generation και image verification δεν υπάρχει native ισοδύναμο, οπότε Kyverno ή Gatekeeper παραμένουν απαραίτητα.

Πώς επαληθεύω container image signatures με Kyverno και cosign;

Χρησιμοποίησε policy με verifyImages block, ορίζοντας keyless attestor με subject και issuer που δείχνουν στο CI/CD OIDC identity. Θέσε mutateDigest: true ώστε τα tags να μετατρέπονται σε immutable digests μετά την επαλήθευση, αποτρέποντας race conditions με image mutation.

Πώς κάνω testing των admission policies στο CI/CD;

Για Kyverno χρησιμοποίησε kyverno test με YAML test spec που περιλαμβάνει sample resources και expected results. Για Gatekeeper το ισοδύναμο είναι gator test. Βάλε το βήμα σε GitHub Actions με pull_request trigger, έτσι σπάει το build όταν κάποιος αλλάξει policy χωρίς να ενημερώσει τα tests.