ProHoster > Blog > Administratioun > Validéiert Kubernetes YAML géint bescht Praktiken a Politiken

Validéiert Kubernetes YAML géint bescht Praktiken a Politiken

Note. iwwersat.: Mat der wuessender Zuel vu YAML Konfiguratiounen fir K8s Ëmfeld gëtt de Besoin fir hir automatiséiert Verifizéierung ëmmer méi dréngend. Den Auteur vun dëser Iwwerpréiwung huet net nëmmen existent Léisunge fir dës Aufgab ausgewielt, awer huet och gekuckt wéi se funktionnéieren mat Deployment als Beispill. Et war ganz informativ fir déi, déi un dësem Thema interesséiert sinn.

Validéiert Kubernetes YAML géint bescht Praktiken a Politiken

TL; DR: Dësen Artikel vergläicht sechs statesch Tools fir Kubernetes YAML Dateien géint bescht Praktiken an Ufuerderungen ze validéieren an ze evaluéieren.

Kubernetes Workloads ginn normalerweis a Form vun YAML Dokumenter definéiert. Ee vun de Probleemer mat YAML ass d'Schwieregkeet fir Aschränkungen oder Bezéiungen tëscht Manifestdateien ze spezifizéieren.

Wat wa mir musse sécherstellen datt all Biller, déi an de Cluster ofgesat ginn, aus engem vertrauenswürdege Registry kommen?

Wéi kann ech verhënneren datt Deployments déi keng PodDisruptionBudgets hunn an de Cluster geschéckt ginn?

Integratioun vu statesche Tester erlaabt Iech Feeler a Politikverletzungen an der Entwécklungsphase z'identifizéieren. Dëst erhéicht d'Garantie datt d'Ressourcedefinitioune richteg a sécher sinn, a mécht et méi wahrscheinlech datt d'Produktiounslaascht déi bescht Praktiken verfollegen.

De Kubernetes statesche YAML Dateiinspektiouns-Ökosystem kann an déi folgend Kategorien opgedeelt ginn:

  • API Valideuren. Tools an dëser Kategorie kontrolléieren de YAML Manifest géint d'Ufuerderunge vum Kubernetes API Server.
  • Bereet Tester. Tools aus dëser Kategorie kommen mat fäerdegen Tester fir Sécherheet, Konformitéit mat beschten Praktiken, etc.
  • Benotzerdefinéiert Valideuren. Vertrieder vun dëser Kategorie erlaabt Iech Mooss Tester a verschiddene Sproochen ze schafen, Zum Beispill, Rego an Javascript.

An dësem Artikel wäerte mir sechs verschidden Tools beschreiwen a vergläichen:

  1. kubeval;
  2. kube-Score;
  3. config-lint;
  4. Koffer;
  5. Contest;
  6. polaris.

Ma, loosst eis ufänken!

Iwwerpréift Deployment

Ier mer ufänken Tools ze vergläichen, loosst eis e puer Hannergrond erstellen op deem se se testen.

De Manifest hei drënner enthält eng Rei vu Feeler an Net-Konformitéit mat beschten Praktiken: wéi vill vun hinnen fannt Dir?

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: http-echo
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: http-echo
        image: hashicorp/http-echo
        args: ["-text", "hello-world"]
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: http-echo
spec:
  ports:
  - port: 5678
    protocol: TCP
    targetPort: 5678
  selector:
    app: http-echo

(base-valid.yaml)

Mir benotzen dëse YAML fir verschidden Tools ze vergläichen.

Den uewe Manifest base-valid.yaml an aner Manifestatiounen aus dësem Artikel fannt Dir an Git Repositories.

De Manifest beschreift eng Webapplikatioun, där hir Haaptaufgab ass, mat engem "Hello World" Message op den Hafen 5678 ze reagéieren. Et kann mat dem folgenden Kommando ofgesat ginn:

kubectl apply -f hello-world.yaml

An esou - kontrolléiert d'Aarbecht:

kubectl port-forward svc/http-echo 8080:5678

Elo gitt op http://localhost:8080 a confirméiert datt d'Applikatioun funktionnéiert. Awer befollegt et bescht Praktiken? Loosst eis kucken.

1. Kubeval

Am Kär kubeval D'Iddi ass datt all Interaktioun mat Kubernetes duerch seng REST API geschitt. An anere Wierder, Dir kënnt en API Schema benotzen fir ze kontrolléieren ob e bestëmmten YAML dermat entsprécht. Loosst eis e Beispill kucken.

Installatioun Uweisungen kubeval sinn op der Websäit vum Projet verfügbar.

Zu der Zäit vum Originalartikel ze schreiwen, war Versioun 0.15.0 verfügbar.

Eemol installéiert, loosst eis et de Manifest hei uewen fidderen:

$ kubeval base-valid.yaml
PASS - base-valid.yaml contains a valid Deployment (http-echo)
PASS - base-valid.yaml contains a valid Service (http-echo)

Wann et erfollegräich ass, wäert de Kubeval mat Ausgangscode 0 erausgoen. Dir kënnt et wéi follegt kontrolléieren:

$ echo $?
0

Loosst eis elo kubeval mat engem anere Manifest probéieren:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: http-echo
        image: hashicorp/http-echo
        args: ["-text", "hello-world"]
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: http-echo
spec:
  ports:
  - port: 5678
    protocol: TCP
    targetPort: 5678
  selector:
    app: http-echo

(kubeval-invalid.yaml)

Kënnt Dir de Problem mam Aen feststellen? Loosst eis starten:

$ kubeval kubeval-invalid.yaml
WARN - kubeval-invalid.yaml contains an invalid Deployment (http-echo) - selector: selector is required
PASS - kubeval-invalid.yaml contains a valid Service (http-echo)

# проверим код возврата
$ echo $?
1

D'Ressource gëtt net verifizéiert.

Deployment mat der API Versioun apps/v1, muss e Selektor enthalen entspriechend dem Label vum Pod. De Manifest uewendriwwer enthält kee Selektor, sou datt Kubeval e Feeler gemellt huet an mat engem Net-Null Code erausgeet.

Ech froe mech wat geschitt wann ech maachen kubectl apply -f mat dësem Manifest?

Ma, loosst eis probéieren:

$ kubectl apply -f kubeval-invalid.yaml
error: error validating "kubeval-invalid.yaml": error validating data: ValidationError(Deployment.spec):
missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec; if you choose to ignore these errors,
turn validation off with --validate=false

Dat ass genee de Feeler, iwwer deen de Kubeval gewarnt huet. Dir kënnt et fixéieren andeems Dir e Selektor bäidréit:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
spec:
  replicas: 2
  selector:          # !!!
    matchLabels:     # !!!
      app: http-echo # !!!
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: http-echo
        image: hashicorp/http-echo
        args: ["-text", "hello-world"]
        ports:
        - containerPort: 5678
---
apiVersion: v1
kind: Service
metadata:
  name: http-echo
spec:
  ports:
  - port: 5678
    protocol: TCP
    targetPort: 5678
  selector:
    app: http-echo

(base-valid.yaml)

De Virdeel vun Tools wéi kubeval ass datt Feeler wéi dës fréi am Deployment Zyklus gefaange kënne ginn.

Zousätzlech erfuerderen dës Kontrollen keen Zougang zum Cluster; Si kënnen offline gemaach ginn.

Par défaut iwwerpréift kubeval Ressourcen géint dat lescht Kubernetes API Schema. Wéi och ëmmer, an de meeschte Fäll musst Dir eventuell géint eng spezifesch Kubernetes Verëffentlechung kontrolléieren. Dëst kann mam Fändel gemaach ginn --kubernetes-version:

$ kubeval --kubernetes-version 1.16.1 base-valid.yaml

Maacht weg datt d'Versioun am Format spezifizéiert muss ginn Major.Minor.Patch.

Fir eng Lëscht vu Versioune fir déi d'Verifizéierung ënnerstëtzt gëtt, kuckt w.e.g. op JSON Schema op GitHub, déi kubeval fir Validatioun benotzt. Wann Dir kubeval offline muss lafen, luet d'Schemaen erof a spezifizéieren hir lokal Plaz mam Fändel --schema-location.

Nieft eenzelne YAML Fichieren kann kubeval och mat Verzeechnes an stdin Aarbecht.

Zousätzlech integréiert Kubeval einfach an d'CI Pipeline. Déi, déi Tester wëllen ausféieren ier se Manifestatiounen an de Cluster schécken, si frou ze wëssen datt kubeval dräi Ausgangsformater ënnerstëtzt:

  1. Einfach Text;
  2. JSON;
  3. Test Anything Protocol (TAP).

A jidderee vun de Formater ka fir weider Parsing vum Output benotzt ginn fir e Resumé vun de Resultater vum gewënschten Typ ze generéieren.

Ee vun den Nodeeler vu Kubeval ass datt et de Moment net op Konformitéit mat Custom Resource Definitions (CRDs) ka kontrolléieren. Wéi och ëmmer, et ass méiglech Kubeval ze konfiguréieren ignoréieren hinnen.

Kubeval ass e super Tool fir Ressourcen ze kontrolléieren an ze evaluéieren; Wéi och ëmmer, et sollt betount ginn datt den Test passéiert net garantéiert datt d'Ressource mat beschten Praktiken entsprécht.

Zum Beispill, benotzt den Tag latest an engem Container verfollegen net beschten Praktiken. Kubeval hält dëst awer net als Feeler a mellt et net. Dat ass, d'Verifizéierung vun esou YAML gëtt ouni Warnungen ofgeschloss.

Awer wat wann Dir YAML evaluéiere wëllt an Violatioune wéi den Tag z'identifizéieren latest? Wéi kontrolléieren ech eng YAML Datei géint déi bescht Praktiken?

2. Kube-Partitur

Kube-Score parses YAML Manifestatiounen an evaluéiert hinnen géint gebaut-an Tester. Dës Tester ginn ausgewielt op Basis vu Sécherheetsrichtlinnen a beschten Praktiken, sou wéi:

  • Lafen de Container als Net-root Benotzer.
  • Disponibilitéit vu Pod Gesondheetskontrollen.
  • Ufroen a Limite fir Ressourcen setzen.

Baséierend op den Testresultater ginn dräi Resultater uginn: OK, OPGEPASST и KRITESCH.

Dir kënnt Kube-Score online probéieren oder se lokal installéieren.

Zu der Zäit vum Originalartikel ze schreiwen, war déi lescht Versioun vum kube-Score 1.7.0.

Loosst eis et op eisem Manifest probéieren base-valid.yaml:

$ kube-score score base-valid.yaml

apps/v1/Deployment http-echo
[CRITICAL] Container Image Tag
  · http-echo -> Image with latest tag
      Using a fixed tag is recommended to avoid accidental upgrades
[CRITICAL] Pod NetworkPolicy
  · The pod does not have a matching network policy
      Create a NetworkPolicy that targets this pod
[CRITICAL] Pod Probes
  · Container is missing a readinessProbe
      A readinessProbe should be used to indicate when the service is ready to receive traffic.
      Without it, the Pod is risking to receive traffic before it has booted. It is also used during
      rollouts, and can prevent downtime if a new version of the application is failing.
      More information: https://github.com/zegl/kube-score/blob/master/README_PROBES.md
[CRITICAL] Container Security Context
  · http-echo -> Container has no configured security context
      Set securityContext to run the container in a more secure context.
[CRITICAL] Container Resources
  · http-echo -> CPU limit is not set
      Resource limits are recommended to avoid resource DDOS. Set resources.limits.cpu
  · http-echo -> Memory limit is not set
      Resource limits are recommended to avoid resource DDOS. Set resources.limits.memory
  · http-echo -> CPU request is not set
      Resource requests are recommended to make sure that the application can start and run without
      crashing. Set resources.requests.cpu
  · http-echo -> Memory request is not set
      Resource requests are recommended to make sure that the application can start and run without crashing.
      Set resources.requests.memory
[CRITICAL] Deployment has PodDisruptionBudget
  · No matching PodDisruptionBudget was found
      It is recommended to define a PodDisruptionBudget to avoid unexpected downtime during Kubernetes
      maintenance operations, such as when draining a node.
[WARNING] Deployment has host PodAntiAffinity
  · Deployment does not have a host podAntiAffinity set
      It is recommended to set a podAntiAffinity that stops multiple pods from a deployment from
      being scheduled on the same node. This increases availability in case the node becomes unavailable.

YAML passéiert Kubeval Tester, wärend de Kube-Score op déi folgend Mängel weist:

  • Bereetschaft Kontrollen sinn net konfiguréiert.
  • Et gi keng Ufroen oder Limiten fir CPU Ressourcen an Erënnerung.
  • Pod Stéierungsbudgeten sinn net spezifizéiert.
  • Et gi keng Trennungsregele (Anti-Affinitéit) fir maximal Disponibilitéit ze maximéieren.
  • De Container leeft als Root.

Dëst sinn all gëlteg Punkten iwwer Mängel déi musse behandelt ginn fir den Deployment méi effizient an zouverlässeg ze maachen.

Equipe kube-score weist Informatioun a mënschlech liesbarer Form mat abegraff all Typverletzungen OPGEPASST и KRITESCH, wat hëlleft vill während der Entwécklung.

Déi, déi dëst Tool an der CI Pipeline benotze wëllen, kënne méi kompriméiert Output mat dem Fändel aktivéieren --output-format ci (an dësem Fall ginn Tester mat dem Resultat och ugewisen OK):

$ kube-score score base-valid.yaml --output-format ci

[OK] http-echo apps/v1/Deployment
[OK] http-echo apps/v1/Deployment
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) CPU limit is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Memory limit is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) CPU request is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Memory request is not set
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Image with latest tag
[OK] http-echo apps/v1/Deployment
[CRITICAL] http-echo apps/v1/Deployment: The pod does not have a matching network policy
[CRITICAL] http-echo apps/v1/Deployment: Container is missing a readinessProbe
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Container has no configured security context
[CRITICAL] http-echo apps/v1/Deployment: No matching PodDisruptionBudget was found
[WARNING] http-echo apps/v1/Deployment: Deployment does not have a host podAntiAffinity set
[OK] http-echo v1/Service
[OK] http-echo v1/Service
[OK] http-echo v1/Service
[OK] http-echo v1/Service

Ähnlech wéi Kubeval, Kube-Score gëtt en Net-Null Ausgangscode zréck wann et en Test ass deen net feelt KRITESCH. Dir kënnt och ähnlech Veraarbechtung aktivéieren fir OPGEPASST.

Zousätzlech ass et méiglech Ressourcen fir d'Konformitéit mat verschiddene API Versiounen ze kontrolléieren (wéi an Kubeval). Wéi och ëmmer, dës Informatioun ass am Kube-Score selwer hardcoded: Dir kënnt keng aner Versioun vu Kubernetes auswielen. Dës Begrenzung kann e grousse Problem sinn wann Dir wëllt Äre Stärekoup upgraden oder wann Dir verschidde Stärekéip mat verschiddene Versioune vu K8s hutt.

notéiert dat et gëtt schonn en Thema mat enger Propositioun dës Geleeënheet ze realiséieren.

Méi Informatiounen iwwer kube-Score fannt Dir op offizieller Websäit.

Kube-Score Tester sinn e super Tool fir bescht Praktiken ëmzesetzen, awer wat wann Dir Ännerungen am Test maache musst oder Är eege Reegelen derbäisetzen? Och, dëst kann net gemaach ginn.

Kube-Score ass net erweiterbar: Dir kënnt keng Politik derbäi addéieren oder se upassen.

Wann Dir personaliséiert Tester schreiwen musst fir d'Konformitéit mat de Firmepolitiken z'iwwerpréiwen, kënnt Dir ee vun de folgende véier Tools benotzen: config-lint, Kupfer, confetest oder Polaris.

3.Config-lint

Config-lint ass en Tool fir YAML, JSON, Terraform, CSV Konfiguratiounsdateien a Kubernetes Manifestatiounen ze validéieren.

Dir kënnt et mat Hëllef installéieren Uweisungen op der Websäit vum Projet.

Déi aktuell Verëffentlechung am Moment vum Schreiwen vum Original Artikel ass 1.5.0.

Config-lint huet keng agebaute Tester fir d'Kubernetes Manifestatiounen ze validéieren.

Fir all Tester ze maachen, ass et néideg entspriechend Regelen ze kreéieren. Si ginn an YAML Dateien geschriwwe genannt "Regelen" (Regelen), an hunn déi folgend Struktur:

version: 1
description: Rules for Kubernetes spec files
type: Kubernetes
files:
  - "*.yaml"
rules:
   # список правил

(rule.yaml)

Loosst eis et méi genee studéieren:

  • Beräich type spezifizéiert wéi eng Zort Configuratioun config-lint wäert benotzen. Fir K8s manifestéiert dëst ass ëmmer Kubernetes.
  • Am Beräich files Zousätzlech zu de Fichieren selwer, kënnt Dir e Verzeechnes uginn.
  • Beräich rules geduecht fir Benotzer Tester astellen.

Loosst eis soen datt Dir sécher sidd datt Biller am Deployment ëmmer vun engem vertrauenswürdege Repository erofgeluede ginn wéi my-company.com/myapp:1.0. Eng Config-lint Regel déi sou e Scheck ausféiert, géif esou ausgesinn:

- id: MY_DEPLOYMENT_IMAGE_TAG
  severity: FAILURE
  message: Deployment must use a valid image tag
  resource: Deployment
  assertions:
    - every:
        key: spec.template.spec.containers
        expressions:
          - key: image
            op: starts-with
            value: "my-company.com/"

(rule-trusted-repo.yaml)

All Regel muss déi folgend Attributer hunn:

  • id - eenzegaarteg Identifizéierer vun der Regel;
  • severity - Vläicht FAILURE, OPGEPASST и NON_KOMPLIANT;
  • message - wann eng Regel verletzt gëtt, gëtt den Inhalt vun dëser Linn ugewisen;
  • resource - d'Zort vun der Ressource op déi dës Regel gëllt;
  • assertions - eng Lëscht vu Konditiounen, déi par rapport zu dëser Ressource bewäert ginn.

An der Regel uewen assertion opgeruff every kontrolléiert datt all Container am Deployment (key: spec.templates.spec.containers) benotzt vertraut Biller (dh ugefaange mat my-company.com/).

De komplette Reegeleet gesäit esou aus:

version: 1
description: Rules for Kubernetes spec files
type: Kubernetes
files:
  - "*.yaml"
rules:

 - id: DEPLOYMENT_IMAGE_REPOSITORY # !!!
    severity: FAILURE
    message: Deployment must use a valid image repository
    resource: Deployment
    assertions:
      - every:
          key: spec.template.spec.containers
          expressions:
            - key: image
              op: starts-with
              value: "my-company.com/"

(ruleset.yaml)

Fir den Test auszeprobéieren, loosst eis et späicheren als check_image_repo.yaml. Loosst eis d'Datei kontrolléieren base-valid.yaml:

$ config-lint -rules check_image_repo.yaml base-valid.yaml

[
  {
  "AssertionMessage": "Every expression fails: And expression fails: image does not start with my-company.com/",
  "Category": "",
  "CreatedAt": "2020-06-04T01:29:25Z",
  "Filename": "test-data/base-valid.yaml",
  "LineNumber": 0,
  "ResourceID": "http-echo",
  "ResourceType": "Deployment",
  "RuleID": "DEPLOYMENT_IMAGE_REPOSITORY",
  "RuleMessage": "Deployment must use a valid image repository",
  "Status": "FAILURE"
  }
]

De Scheck ass gescheitert. Loosst eis de folgende Manifest mam richtege Bildrepository kucken:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: http-echo
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: http-echo
         image: my-company.com/http-echo:1.0 # !!!
         args: ["-text", "hello-world"]
         ports:
         - containerPort: 5678

(image-valid-mycompany.yaml)

Mir lafen déi selwecht Test mat der uewen Manifestatioun. Keng Problemer fonnt:

$ config-lint -rules check_image_repo.yaml image-valid-mycompany.yaml
[]

Config-lint ass e verspriechende Kader deen Iech erlaabt Är eegen Tester ze kreéieren fir Kubernetes YAML Manifestatiounen mat der YAML DSL ze validéieren.

Awer wat wann Dir méi komplex Logik an Tester braucht? Ass YAML net ze limitéiert fir dëst? Wat wann Dir Tester an enger voller Programméierungssprooch erstellen kéint?

4. Kupfer

Kupfer V2 ass e Kader fir Manifestatiounen ze validéieren mat personaliséierten Tester (ähnlech wéi Config-lint).

Wéi och ëmmer, et ënnerscheet sech vun deem Leschten an datt et YAML net benotzt fir Tester ze beschreiwen. Tester kënnen amplaz a JavaScript geschriwwe ginn. Kupfer bitt eng Bibliothéik mat verschiddene Basisinstrumenter, déi Iech hëllefen Informatiounen iwwer Kubernetes Objeten ze liesen a Feeler ze mellen.

D'Schrëtt fir d'Installatioun vu Kupfer fannt Dir an offiziell Dokumentatioun.

2.0.1 ass déi lescht Verëffentlechung vun dësem Utility zum Zäitpunkt vum Schreiwen vum Originalartikel.

Wéi Config-lint, Kupfer huet keng agebaute Tester. Loosst eis eng schreiwen. Loosst et iwwerpréiwen datt d'Deployementer Container Biller ausschliisslech vu vertrauenswürdege Repositories benotzen wéi my-company.com.

Schafen eng Datei check_image_repo.js mat folgendem Inhalt:

$$.forEach(function($){
    if ($.kind === 'Deployment') {
        $.spec.template.spec.containers.forEach(function(container) {
            var image = new DockerImage(container.image);
            if (image.registry.lastIndexOf('my-company.com/') != 0) {
                errors.add_error('no_company_repo',"Image " + $.metadata.name + " is not from my-company.com repo", 1)
            }
        });
    }
});

Elo fir eist Manifest ze testen base-valid.yaml, benotzt de Kommando copper validate:

$ copper validate --in=base-valid.yaml --validator=check_image_tag.js

Check no_company_repo failed with severity 1 due to Image http-echo is not from my-company.com repo
Validation failed

Et ass kloer datt Dir mat der Hëllef vu Kupfer méi komplex Tester ausféiere kënnt - zum Beispill Domainnamen an Ingress Manifestatiounen iwwerpréiwen oder Pods refuséieren déi am privilegiéierten Modus lafen.

Kupfer huet verschidde Utilityfunktiounen agebaut:

  • DockerImage liest déi spezifizéiert Inputdatei a kreéiert en Objet mat de folgenden Attributer:
    • name - Numm vum Bild,
    • tag - Bild Tag,
    • registry - Bildregistrierung,
    • registry_url - Protokoll (https://) a Bildregistrierung,
    • fqin - voll Plaz vum Bild.
  • Funktioun findByName hëlleft eng Ressource no engem bestëmmten Typ ze fannen (kind) an Numm (name) aus der Inputdatei.
  • Funktioun findByLabels hëlleft eng Ressource no engem spezifizéierten Typ ze fannen (kind) an Etiketten (labels).

Dir kënnt all verfügbare Servicefunktiounen gesinn hei.

Par défaut lued et déi ganz Input YAML Datei an eng Variabel $$ a mécht et fir Scripting verfügbar (eng vertraut Technik fir déi mat jQuery Erfahrung).

Den Haaptvirdeel vu Kupfer ass offensichtlech: Dir musst keng spezialiséiert Sprooch beherrschen an Dir kënnt verschidde JavaScript Feature benotze fir Är eegen Tester ze kreéieren, sou wéi Stringinterpolatioun, Funktiounen, asw.

Et sollt och bemierkt ginn datt déi aktuell Versioun vu Copper mat der ES5 Versioun vum JavaScript-Motor funktionnéiert, net ES6.

Detailer verfügbar um offiziell Projet Websäit.

Wéi och ëmmer, wann Dir JavaScript net wierklech gär hutt an eng Sprooch léiwer speziell entwéckelt fir Ufroen ze kreéieren an Politiken ze beschreiwen, sollt Dir op Conftest oppassen.

5. Confest

Conftest ass e Kader fir d'Konfiguratiounsdaten ze testen. Och gëeegent fir Testen / z'iwwerpréiwen Kubernetes Manifestatiounen. Tester gi beschriwwe mat enger spezialiséierter Ufrosprooch rego.

Dir kënnt Conftest installéiert benotzen Uweisungenop der Websäit vum Projet opgezielt.

Zu der Zäit vum Originalartikel ze schreiwen, war déi lescht verfügbar Versioun 0.18.2.

Ähnlech wéi Config-Lint a Kupfer, Conftest kënnt ouni agebauten Tester. Loosst eis et ausprobéieren an eis eege Politik schreiwen. Wéi a fréiere Beispiller wäerte mir iwwerpréiwen ob d'Containerbiller aus enger zouverléisseg Quell geholl ginn.

Schafen engem Verzeechnes conftest-checks, an et ass e Fichier mam Numm check_image_registry.rego mat folgendem Inhalt:

package main

deny[msg] {

  input.kind == "Deployment"
  image := input.spec.template.spec.containers[_].image
  not startswith(image, "my-company.com/")
  msg := sprintf("image '%v' doesn't come from my-company.com repository", [image])
}

Loosst eis elo testen base-valid.yaml duerch conftest:

$ conftest test --policy ./conftest-checks base-valid.yaml

FAIL - base-valid.yaml - image 'hashicorp/http-echo' doesn't come from my-company.com repository
1 tests, 1 passed, 0 warnings, 1 failure

Den Test ass viraussiichtlech gescheitert well d'Biller aus enger onvertraulecher Quell koumen.

An der Rego Datei definéiere mir de Block deny. Seng Wourecht gëtt als Violatioun ugesinn. Wann blockéiert deny e puer, conftest kontrolléiert se onofhängeg vuneneen, an d'Wourecht vun engem vun de Blocken gëtt als Violatioun behandelt.

Zousätzlech zum Standardoutput ënnerstëtzt conftest JSON, TAP an Tabellformat - eng extrem nëtzlech Feature wann Dir Berichter an eng existent CI Pipeline embedde musst. Dir kënnt de gewënschte Format mat dem Fändel setzen --output.

Fir et méi einfach ze maachen d'Politik ze debuggen, huet conftest e Fändel --trace. Et gëtt eng Spuer eraus wéi Conftest déi spezifizéiert Politikdateien parséiert.

Concours Politik kënnen an OCI (Open Container Initiative) Registry als Artefakt publizéiert a gedeelt ginn.

Équipen push и pull erlaabt Iech en Artefakt ze publizéieren oder en existent Artefakt aus engem Remote Registry ze recuperéieren. Loosst eis probéieren d'Politik ze publizéieren déi mir erstallt hunn an de lokalen Docker Registry benotzt conftest push.

Start Äre lokalen Docker Registry:

$ docker run -it --rm -p 5000:5000 registry

An engem aneren Terminal, gitt an de Verzeichnis deen Dir virdru erstallt hutt conftest-checks a lafen de folgende Kommando:

$ conftest push 127.0.0.1:5000/amitsaha/opa-bundle-example:latest

Wann de Kommando erfollegräich war, gesitt Dir e Message wéi dës:

2020/06/10 14:25:43 pushed bundle with digest: sha256:e9765f201364c1a8a182ca637bc88201db3417bacc091e7ef8211f6c2fd2609c

Erstellt elo en temporäre Verzeichnis a fuert de Kommando dran conftest pull. Et wäert de Package eroflueden, dee vum virege Kommando erstallt gouf:

$ cd $(mktemp -d)
$ conftest pull 127.0.0.1:5000/amitsaha/opa-bundle-example:latest

En Ënnerverzeechnes erschéngt am temporäre Verzeichnis policymat eisem Politikdatei:

$ tree
.
└── policy
  └── check_image_registry.rego

Tester kënnen direkt aus dem Repository lafen:

$ conftest test --update 127.0.0.1:5000/amitsaha/opa-bundle-example:latest base-valid.yaml
..
FAIL - base-valid.yaml - image 'hashicorp/http-echo' doesn't come from my-company.com repository
2 tests, 1 passed, 0 warnings, 1 failure

Leider gëtt DockerHub nach net ënnerstëtzt. Also betruecht Iech Gléck wann Dir benotzt Azure Container Registry (ACR) oder Ären eegene Registry.

Artefakt Format ass d'selwecht wéi Open Policy Agent Packagen (OPA), wat Iech erlaabt Confetest ze benotzen fir Tester aus existéierenden OPA Packagen auszeféieren.

Dir kënnt méi iwwer d'Politikdeele an aner Feature vum Conftest léieren op offiziell Projet Websäit.

6. Polaris

Déi lescht Tool dat an dësem Artikel diskutéiert gëtt ass Polaris. (Seng lescht Joer Ukënnegung mir schonn iwwersat - ca. Iwwersetzung)

Polaris kann an engem Cluster installéiert ginn oder am Kommandozeilmodus benotzt ginn. Wéi Dir vläicht virgestallt hutt, erlaabt et Iech statesch Kubernetes Manifestatiounen ze analyséieren.

Wann Dir am Kommandozeilmodus leeft, sinn agebaute Tester verfügbar déi Beräicher wéi Sécherheet a bescht Praktiken ofdecken (ähnlech wéi Kube-Score). Zousätzlech kënnt Dir Är eegen Tester erstellen (wéi a Config-lint, Kupfer a Confetest).

An anere Wierder, Polaris kombinéiert d'Virdeeler vu béide Kategorien vun Tools: mat agebauten a personaliséierten Tester.

Fir Polaris am Kommandozeilmodus z'installéieren, benotzt Instruktioune op der Websäit vum Projet.

Zu der Zäit vum Originalartikel ze schreiwen ass d'Versioun 1.0.3 verfügbar.

Wann d'Installatioun fäerdeg ass, kënnt Dir Polaris um Manifest lafen base-valid.yaml mat dem folgenden Kommando:

$ polaris audit --audit-path base-valid.yaml

Et gëtt e String am JSON-Format erausginn mat enger detailléierter Beschreiwung vun den duerchgefouerten Tester an hir Resultater. D'Ausgab wäert déi folgend Struktur hunn:

{
  "PolarisOutputVersion": "1.0",
  "AuditTime": "0001-01-01T00:00:00Z",
  "SourceType": "Path",
  "SourceName": "test-data/base-valid.yaml",
  "DisplayName": "test-data/base-valid.yaml",
  "ClusterInfo": {
    "Version": "unknown",
    "Nodes": 0,
    "Pods": 2,
    "Namespaces": 0,
    "Controllers": 2
  },
  "Results": [
    /* длинный список */
  ]
}

Voll Ausgang verfügbar hei.

Wéi de Kube-Score, identifizéiert Polaris Themen a Beräicher wou de Manifest net de beschten Praktiken entsprécht:

  • Et gi keng Gesondheetskontrolle fir Pods.
  • Tags fir Container Biller sinn net uginn.
  • De Container leeft als Root.
  • Ufroen a Limite fir Erënnerung an CPU sinn net spezifizéiert.

All Test, ofhängeg vu senge Resultater, gëtt e Grad vu Kritizitéit zougewisen: Warnung oder Gefor. Fir méi iwwer déi verfügbar agebaut Tester ze léieren, kuckt w.e.g. op Dokumentatioun.

Wann Detailer sinn net néideg, Dir kënnt de Fändel uginn --format score. An dësem Fall gëtt Polaris eng Zuel aus 1 bis 100 - stoung (d.h. Bewäertung):

$ polaris audit --audit-path test-data/base-valid.yaml --format score
68

Wat de Score méi no bei 100 ass, dest méi héich ass de Grad vum Accord. Wann Dir den Ausgangscode vum Kommando kontrolléiert polaris audit, et stellt sech eraus datt et gläich ass 0.

Maacht polaris audit Dir kënnt d'Aarbecht mat Net-Null Code ofschléissen mat zwee Fändelen:

  • Fändel --set-exit-code-below-score hëlt als Argument e Schwellwäert am Beräich 1-100. An dësem Fall wäert de Kommando mat Ausgangscode 4 erausgoen wann de Score ënner der Schwell ass. Dëst ass ganz nëtzlech wann Dir e bestëmmte Schwellwäert hutt (z. 75) an Dir musst eng Alarm kréien wann de Score ënner geet.
  • Fändel --set-exit-code-on-danger wäert de Kommando mat Code 3 versoen wann ee vun de Gefor Tester versoen.

Loosst eis elo probéieren e personaliséierten Test ze kreéieren deen iwwerpréift ob d'Bild aus engem vertrauenswürdege Repository geholl gëtt. Benotzerdefinéiert Tester ginn am YAML Format spezifizéiert, an den Test selwer gëtt mat JSON Schema beschriwwen.

Déi folgend YAML Code Snippet beschreift en neien Test genannt checkImageRepo:

checkImageRepo:
  successMessage: Image registry is valid
  failureMessage: Image registry is not valid
  category: Images
  target: Container
  schema:
    '$schema': http://json-schema.org/draft-07/schema
    type: object
    properties:
      image:
        type: string
        pattern: ^my-company.com/.+$

Loosst eis et méi genau kucken:

  • successMessage - dës Zeil gëtt gedréckt wann den Test erfollegräich ofgeschloss ass;
  • failureMessage - dëse Message gëtt am Fall vun Echec gewisen;
  • category - weist eng vun de Kategorien un: Images, Health Checks, Security, Networking и Resources;
  • target--- bestëmmt wéi eng Zort Objet (spec) Test applizéiert gëtt. Méiglech Wäerter: Container, Pod oder Controller;
  • Den Test selwer gëtt am Objet uginn schema benotzt JSON Schema. De Schlësselwuert an dësem Test ass pattern benotzt fir d'Bildquell mat der néideger ze vergläichen.

Fir den uewe genannten Test auszeféieren, musst Dir déi folgend Polaris Konfiguratioun erstellen:

checks:
  checkImageRepo: danger
customChecks:
  checkImageRepo:
    successMessage: Image registry is valid
    failureMessage: Image registry is not valid
    category: Images
    target: Container
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          pattern: ^my-company.com/.+$

(polaris-conf.yaml)

Loosst eis d'Datei parséieren:

  • Am Beräich checks Tester an hiren Niveau vun der Kritik sinn verschriwwen. Well et wënschenswäert ass eng Warnung ze kréien wann e Bild vun enger net vertrauter Quell geholl gëtt, setzen mir den Niveau hei danger.
  • Den Test selwer checkImageRepo dann am Objet registréiert customChecks.

Späichert d'Datei als custom_check.yaml. Elo kënnt Dir lafen polaris audit mat engem YAML Manifest deen d'Verifizéierung erfuerdert.

Loosst eis eise Manifest testen base-valid.yaml:

$ polaris audit --config custom_check.yaml --audit-path base-valid.yaml

Equipe polaris audit huet nëmmen de Benotzertest hei uewen uginn an et ass gescheitert.

Wann Dir d'Bild fixéiert op my-company.com/http-echo:1.0, Polaris wäert erfollegräich ofgeschloss. De Manifest mat den Ännerungen ass schonn era Repositoriessou kënnt Dir de virdrun Kommando op der Manifest kontrolléieren image-valid-mycompany.yaml.

Elo stellt sech d'Fro: wéi een agebaute Tester zesumme mat personaliséierten Tester ausféiert? Einfach! Dir musst just déi agebaute Testidentifizéierer an d'Konfiguratiounsdatei addéieren. Als Resultat wäert et déi folgend Form huelen:

checks:
  cpuRequestsMissing: warning
  cpuLimitsMissing: warning
  # Other inbuilt checks..
  # ..
  # custom checks
  checkImageRepo: danger # !!!
customChecks:
  checkImageRepo:        # !!!
    successMessage: Image registry is valid
    failureMessage: Image registry is not valid
    category: Images
    target: Container
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          pattern: ^my-company.com/.+$

(config_with_custom_check.yaml)

E Beispill vun enger kompletter Konfiguratiounsdatei ass verfügbar hei.

Kontrolléiert Manifest base-valid.yamlmat agebauten a personaliséierten Tester kënnt Dir de Kommando benotzen:

$ polaris audit --config config_with_custom_check.yaml --audit-path base-valid.yaml

Polaris ergänzt déi agebaute Tester mat personaliséierten, a kombinéiert domat dat Bescht vu béide Welten.

Op der anerer Säit kann d'Onméiglechkeet méi mächteg Sprooche wéi Rego oder JavaScript ze benotzen e limitéierende Faktor sinn, deen d'Schafung vu méi sophistikéierten Tester verhënnert.

Méi Informatioun iwwer Polaris ass verfügbar op Projet Websäit.

Summary

Wärend et vill Tools verfügbar sinn fir Kubernetes YAML Dateien z'inspektéieren an ze evaluéieren, et ass wichteg e kloert Verständnis ze hunn wéi d'Tester entworf an ausgefouert ginn.

Zum Beispill, wann Dir Kubernetes Manifestatiounen hëlt duerch eng Pipeline, kubeval kéint den éischte Schrëtt an esou enger Pipeline sinn. Et géif iwwerwaachen ob Objektdefinitioune mam Kubernetes API Schema entspriechen.

Wann esou eng Iwwerpréiwung ofgeschloss ass, kéint een op méi sophistikéiert Tester weidergoen, sou wéi d'Konformitéit mat Standard Best Practices a spezifesch Politiken. Dëst ass wou Kube-Score a Polaris praktesch kommen.

Fir déi, déi komplex Ufuerderungen hunn a mussen Tester am Detail personaliséiere, Kupfer, Config-lint a Conftest wieren gëeegent.

Conftest a config-lint benotzen YAML fir personaliséiert Tester ze definéieren, a Kupfer gëtt Iech Zougang zu enger voller Programméierungssprooch, wat et eng zimlech attraktiv Wiel mécht.

Op der anerer Säit, ass et derwäert ee vun dësen Tools ze benotzen an dofir all Tester manuell ze kreéieren, oder léiwer Polaris a fügen nëmmen dat wat néideg ass? Et gëtt keng kloer Äntwert op dës Fro.

D'Tabell hei drënner gëtt eng kuerz Beschreiwung vun all Tool:

Tool
Zilsetzung
Defiziter
Benotzer Tester

kubeval
Validéiert YAML manifestéiert géint eng spezifesch Versioun vum API Schema
Kann net mat CRD schaffen
Nee

kube-Score
Analyséiert YAML manifestéiert géint beschten Praktiken
Kann Är Kubernetes API Versioun net auswielen fir Ressourcen ze kontrolléieren
Nee

Koffer
En allgemenge Kader fir personaliséiert JavaScript Tester fir YAML Manifestatiounen ze kreéieren
Keng gebaut-an Tester. Schlecht Dokumentatioun
datt

config-lint
En allgemenge Kader fir Tester ze kreéieren an enger Domain-spezifescher Sprooch agebaut an YAML. Ënnerstëtzt verschidde Konfiguratiounsformater (zB Terraform)
Et gi keng fäerdeg Tester. Built-in Behaaptungen a Funktiounen kënnen net genuch sinn
datt

contest
E Kader fir Är eege Tester mat Rego ze kreéieren (eng spezialiséiert Ufrosprooch). Erlaabt Deele vu Politiken iwwer OCI Bündel
Keng gebaut-an Tester. Ech muss Rego léieren. Docker Hub gëtt net ënnerstëtzt wann Dir Politik publizéiert
datt

Polaris
Bewäertungen YAML manifestéiert géint Standard beschten Praktiken. Erlaabt Iech Är eege Tester mat JSON Schema ze kreéieren
Testfäegkeeten baséiert op JSON Schema kënnen net genuch sinn
datt

Well dës Tools net op den Zougang zum Kubernetes Cluster vertrauen, si si einfach ze installéieren. Si erlaben Iech Quelldateien ze filteren a séier Feedback un d'Auteuren vun Pull-Ufroen a Projeten ze bidden.

PS vum Iwwersetzer

Liest och op eisem Blog:

Source: will.com

Setzt e Commentaire