🥇Validimi i Kubernetes YAML për t'u siguruar që përputhet me praktikat dhe politikat më të mira

Shën. përkth.: Me rritjen e numrit të konfiguracioneve YAML për mjediset K8s, nevojat për verifikimin e tyre automatizuar po bëhen gjithnjë e më të rëndësishme. Autori i këtij shqyrtimi jo vetëm që ka përzgjedhur zgjidhjet ekzistuese për këtë detyrë, por edhe ka shqyrtuar, me ndihmën e Deployment-it, se si ato funksionojnë. Doli mjaft informuese për ata që e kanë këtë temë interesante.

TL;DR: Në këtë artikull krahasohen gjashtë mjete statike për verifikimin dhe vlerësimin e skedarëve YAML të Kubernetes për t'u siguruar që ata përputhen me praktikat më të mira dhe kërkesat.

Ngarkesat e punës në Kubernetes zakonisht definirhen në formën e dokumenteve YAML. Një nga problemet me YAML-n është vështirësia e caktimit të kufizimeve ose marrëdhënieve midis skedarëve të manifestit.

Çfarë nëse na duhet të sigurohemi që të gjitha imazhet që shfaqen në klaster vijnë nga një regjistër i besueshëm?

Si të parandalohet dërgimi në klaster i Deployment-eve, për të cilat nuk janë caktuar PodDisruptionBudgets?

Integrimi i testimit statik lejon identifikimin e gabimeve dhe shkeljeve të politikave ende në fazën e zhvillimit. Kështu, rriten garancitë për saktësinë dhe sigurinë e definicioneve të burimeve dhe rritet probabiliteti që ngarkesat në prodhim të ndjekin praktikat më të mira.

Ekosistemi i verifikimit statik të skedarëve YAML të Kubernetes mund të ndahet në kategoritë e mëposhtme:

Validuesit e API-ve. Mjetet në këtë kategori verifikojnë manifestin YAML për të siguruar që ai përputhet me kërkesat e serverit API të Kubernetes.
Testuesit e gatshëm. Mjetet nga kjo kategori vijnë me teste të gatshme për sigurinë, përputhshmërinë me praktikat më të mira, etj.
Validuesit e personalizuar. Përfaqësuesit e kësaj kategorie lejojnë krijimin e testeve përdoruese në gjuhë të ndryshme, për shembull, në Rego dhe Javascript.

Në këtë artikull do të përshkruajmë dhe krahasojmë gjashtë mjete të ndryshme:

kubeval;
kube-score;
config-lint;
copper;
conftest;
Polaris.

Mirë, le të fillojmë!

Verifikimi i Deployment-eve

Para se të fillojmë me krahasimin e mjeteve, le të krijojmë një bazë, mbi të cilën do i testojmë.

Manifesti i dhënë më poshtë përmban një numër gabimesh dhe mos përputhjesh me praktikat më të mira: sa nga ato do të jeni në gjendje t'i gjeni?

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)

Ne do të përdorim këtë YAML për të krahasuar mjete të ndryshme.

Manifesti i përmendur më lart base-valid.yaml dhe manifestet e tjera nga ky artikull mund të gjenden në repo Git.

Manifesti përshkruan një aplikacion web, qëllimi kryesor i të cilit është të përgjigjet me mesazhin "Hello World" në portin 5678. Ai mund të implementohet me komandën e mëposhtme:

kubectl apply -f hello-world.yaml

Tani kontrolloni funksionimin:

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

Tani shkoni në http://localhost:8080 dhe konfirmoni që aplikacioni po funksionon. Por a është ai në përputhje me praktikat më të mira? Le të kontrollojmë.

1. Kubeval

Në thelb kubeval bazohet në idenë se çdo ndërveprim me Kubernetes ndodh përmes API-së së tij REST. Me fjalë të tjera, mund të përdorni skemën e API-së për të verifikuar nëse ky YAML i përgjigjet asaj. Le të shohim një shembull.

Udhëzimet për instalimin e kubeval janë të disponueshme në faqen e projektit.

Në momentin e shkrimit të artikullit origjinal, versioni 0.15.0 ishte i disponueshëm.

Pas instalimit, le të 'ngremë' manifestin e lartpërmendur:

$ kubeval base-valid.yaml
PASS - base-valid.yaml përmban një Deployment të vlefshëm (http-echo)
PASS - base-valid.yaml përmban një Shërbim të vlefshëm (http-echo)

Në rast sukses, kubeval do të përfundojë me kodin e daljes 0. Mund ta verifikoni kështu:

$ echo $?
0

Tani le të provojmë kubeval me një manifest tjetër:

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)

A mund të identifikoni problemin me sy? Aktivizojmë:

$ kubeval kubeval-invalid.yaml
WARN - kubeval-invalid.yaml përmban një Deployment të pavlefshëm (http-echo) - selector: selektori është i nevojshëm
PASS - kubeval-invalid.yaml përmban një Shërbim të vlefshëm (http-echo)

# le t'i kontrollojmë kodin e daljes
$ echo $?
1

Burimi nuk kalon verifikimin.

Deployment'ët, që përdorin versionin e API-së apps/v1, duhet të përfshijnë një selektor që përputhet me etiketën e pod'it. Manifesti i lartpërmendur nuk përfshin selektor, ndaj kubeval raportoi një gabim dhe doli me një kod jo zero.

E interesant është, çfarë do të ndodhë nëse ekzekutohet kubectl apply -f me këtë manifest?

Epo, le ta provojmë:

$ 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

Kjo është saktësisht gabimi për të cilin paralajmëroi kubeval. Mund ta ndreqni atë duke shtuar një selektor:

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)

Avantazhi i mjeteve si kubeval është se gabime të tilla mund të kapen në fazat e hershme të ciklit të implementimit.

Për më tepër, për këto kontrollime nuk nevojitet qasje në klaster: ato mund të kryhen offline.

Sipas parazgjedhjes, kubeval kontrollon burimet për përputhshmërinë me skemën më të fundit të Kubernetes API. Megjithatë, në shumicën e rasteve, mund t'ju nevojitet të bëni kontrollin për përputhshmërinë me një version specifik të Kubernetes. Këtë mund ta bëni përmes flagut --kubernetes-version:

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

Vini re se versioni duhet të jepet në formatin Major.Minor.Patch.

Për të parë një listë versionesh, për të cilat mbështetet kontrolli, merrni parasysh JSON-sheminë në GitHub, e cila përdoret nga kubeval për validimin. Nëse duhet të ekzekutoni kubeval offline, shkarkoni skemat dhe tregoni vendndodhjen e tyre lokale përmes flagut --schema-location.

Përveç skedave YAML individuale, kubeval gjithashtu mund të punojë me drejtoritë dhe stdin.

Për më tepër, Kubeval lehtë integron në pipeline CI. Ata që duan të kryejnë teste para dërgimit të manifestëve në klaster do të gëzohen të dinë se kubeval mbështet tri formate dalëse:

Tekst të zakonshëm;
JSON;
Test Anything Protocol (TAP).

Dhe cilindo nga formatet mund të përdoret për parsing të mëtejshëm të daljes, për të formuar një përmbledhje të rezultateve në llojin e dëshiruar.

Një nga mangësitë e kubeval është se aktualisht ai nuk di të kontrollojë për përputhshmërinë me Custom Resource Definitions (CRDs). Megjithatë, mund të konfigurohet kubeval të injorojë ato.

Kubeval është një mjet i shkëlqyer për kontrollin dhe vlerësimin e burimeve; megjithatë, duhet theksuar se kalimi me sukses i testit nuk garanton që burimi përputhet me praktikat më të mira.

Për shembull, përdorimi i etiketës latest në kontenieri nuk i përgjigjet praktikave më të mira. Sidoqoftë, kubeval nuk e konsideron këtë si një gabim dhe nuk e njofton atë. Pra, kontrolli i tillë YAML do të përfundojë pa paralajmërime.

Por çfarë, nëse duhet të përvijohet YAML dhe të zbulohen shkelje si p.sh. etiketat latest? Как проверить YAML-файл на соответствие лучшим практикам?

2. Kube-score

Kube-score analizon manifestet YAML dhe i vlerëson ato sipas testeve të integruara. Këto teste zgjidhen bazuar në rekomandimet për sigurinë dhe praktikat më të mira, si p.sh.:

Ekzekutimi i kontejnerit jo si root.
Prania e kontrollimeve të shëndetit të pod'ave.
Caktimi i kërkesave dhe kufijve të burimeve.

Pas testeve jepen tre rezultate: OK, KËSHILLË dhe KRITIKE.

Kube-score mund të provohet në internet ose të instalohet lokal.

Në momentin e shkrimit të artikullit origjinal, versioni më i ri i kube-score ishte 1.7.0.

Le të provojmë atë në manifestin tonë base-valid.yaml:

$ kube-score score base-valid.yaml

apps/v1/Deployment http-echo
[KRITIKE] Etiketa e Imazhit të Konteinerit
  · http-echo -> Imazh me etiketen e fundit
      Përdorimi i një etikete fikse rekomandohet për të shmangur përmirësimet aksidentale
[KRITIKE] Politika e Rrjetit të Pod’ave
  · Pod'i nuk ka një politikë rrjeti përputhëse
      Krijoni një NetworkPolicy që cakton këtë pod
[KRITIKE] Kontrolloret e Pod’ave
  · Kontejneri nuk ka një readinessProbe
      Një readinessProbe duhet të përdoret për të treguar kur shërbimi është gati për të pranuar trafik.
      Pa të, Pod'i rrezikon të pranojë trafik para se të jetë ngarkuar. Përdoret gjithashtu gjatë
      nisjeve dhe mund të parandalojë ndalimin nëse një version i ri i aplikacionit dështon.
      Informacione të tjera: https://github.com/zegl/kube-score/blob/master/README_PROBES.md
[KRITIKE] Konteksti i Sigurisë së Konteinerit
  · http-echo -> Kontejneri nuk ka një kontekst sigurie të konfiguruar
      Caktoni securityContext për të ekzekutuar kontejnerin në një kontekst më të sigurt.
[KRITIKE] Burimet e Konteinerit
  · http-echo -> Kufiri i CPU nuk është i caktuar
      Kufizimet e burimeve rekomandohen për të shmangur DDOS burimesh. Caktoni resources.limits.cpu
  · http-echo -> Kufiri i Memories nuk është i caktuar
      Kufizimet e burimeve rekomandohen për të shmangur DDOS burimesh. Caktoni resources.limits.memory
  · http-echo -> Kërkesa për CPU nuk është e caktuar
      Kërkesat për burime rekomandohen për të siguruar që aplikacioni të mund të fillojë dhe të funksionojë pa
      dështuar. Caktoni resources.requests.cpu
  · http-echo -> Kërkesa për Memory nuk është e caktuar
      Kërkesat për burime rekomandohen për të siguruar që aplikacioni të mund të fillojë dhe të funksionojë pa dështuar.
      Caktoni resources.requests.memory
[KRITIKE] Një Politika e Shkëputjes së Pod’ave është e caktuar
  · Nuk u gjet asnjë PodDisruptionBudget përputhës
      Rekomandohet të përcaktohet një PodDisruptionBudget për të shmangur ndalimin e papritur gjatë operacioneve të mirëmbajtjes së Kubernetes,
      si kur derdhni një nod.
[KËSHILLË] Një Politika e PodAntiAffinity për host’in është e caktuar
  · Dispozita nuk ka një podAntiAffinity të caktuar
      Rekomandohet të caktohet një podAntiAffinity që ndalon shumë pod'ave nga një dispozitë të programohen në të njëjtin nod. Kjo rrit disponueshmërinë në rast se nodi bëhet i paqëndrueshëm.

YAML kalon verifikimet kubeval, ndërsa kube-score nënvizon mangësitë e mëposhtme:

Nuk janë konfiguruar kontrollorët e gatishmërisë.
Kërkesat dhe kufijtë për burimet CPU dhe memorie mungojnë.
Nuk janë caktuar buxhetet e shkëputjes së Pod’ave.
Mungojnë rregullat e ndarjes së jetesës (anti-affinity) për maksimizimin e disponueshmërisë.
Kontejneri ekzekutohet nën root.

Këto janë vërejtje të arsyeshme për mungesat që duhen përmirësuar në mënyrë që Deploymendi të jetë më efikas dhe i besueshëm.

Ekipa kube-score jep informacion në një formë të lehtë për t'u lexuar duke përfshirë të gjitha shkeljet e llojit KËSHILLË dhe KRITIKE, çka ndihmon shumë gjatë zhvillimit.

Atyre që dëshirojnë të përdorin këtë mjet në kuadër të pipeline-it CI, mund t'u aktivizohet një nxjerrje më e përmbledhur me ndihmën e flagut --output-format ci (në këtë rast, gjithashtu shfaqen testet me rezultat OK):

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

[OK] http-echo apps/v1/Deployment
[OK] http-echo apps/v1/Deployment
[KRITIK] http-echo apps/v1/Deployment: (http-echo) Kufiri i CPU-së nuk është vendosur
[KRITIK] http-echo apps/v1/Deployment: (http-echo) Kufiri i memories nuk është vendosur
[KRITIK] http-echo apps/v1/Deployment: (http-echo) Kërkesa për CPU-në nuk është vendosur
[KRITIK] http-echo apps/v1/Deployment: (http-echo) Kërkesa për memorjen nuk është vendosur
[KRITIK] http-echo apps/v1/Deployment: (http-echo) Imazhi me tagun e fundit
[OK] http-echo apps/v1/Deployment
[KRITIK] http-echo apps/v1/Deployment: Pod-i nuk ka një politikë rrjeti përputhëse
[KRITIK] http-echo apps/v1/Deployment: Konteneri i mungon një readinessProbe
[KRITIK] http-echo apps/v1/Deployment: (http-echo) Konteneri nuk ka një kontekst sigurie të konfiguruar
[KRITIK] http-echo apps/v1/Deployment: Nuk u gjet asnjë PodDisruptionBudget përputhës
[KGJITHASHTU] http-echo apps/v1/Deployment: Deploymendi nuk ka një host podAntiAffinity të vendosur
[OK] http-echo v1/Service
[OK] http-echo v1/Service
[OK] http-echo v1/Service
[OK] http-echo v1/Service

Në përputhje me kubeval, kube-score ktheu një kod dalës jo zero kur ndodhi një test me gabim. KRITIKE. Po ashtu, mund të aktivizohet një përpunim i tillë edhe për KËSHILLË.

Për më tepër, ka mundësi për të verifikuar burimet për përputhshmëri me versione të ndryshme API (ashtu si në kubeval). Sidoqoftë, këtë informacion e gjejmë të 'hardcoduar' në kube-score: nuk mund të zgjidhet një version tjetër Kubernetes. Ky kufizim mund të bëhet një problem i madh nëse planifikoni të azhurnoni klasterin ose keni disa klastera me versione të ndryshme të K8s.

Vini re se prej tashmë ekziston një çështje me propozimin për ta realizuar këtë mundësi.

Për më shumë rreth kube-score, mund të mësoni në faqen zyrtare.

Testet kube-score janë një mjet i shkëlqyer për implementimin e praktikave më të mira, por çfarë nëse duhet të bëhen ndryshime në test ose të shtohen rregulla të veta? Fatkeqësisht, kjo nuk është e mundur.

Kube-score nuk është e zgjerueshme: nuk mund të shtohen politika ose të përshtaten ato.

Nëse nevojitet të shkruhen teste të personalizuara për të verifikuar përputhshmërinë me politikat e pranuara në kompani, mund të përdoren një nga katër mjetet e mëposhtme: config-lint, copper, conftest ose polaris.

3. Config-lint

Config-lint — është një mjet për validimin e skedarëve të konfigurimit në formatin YAML, JSON, Terraform, CSV dhe manifestet Kubernetes.

Mund ta instaloni duke përdorur udhëzimet në faqen e projektit.

Lëshimi aktual deri në momentin e shkruarjes së artikulli origjinal është 1.5.0.

Config-lint nuk përmban teste të ndërtuara për të verifikuar manifestet Kubernetes.

Për të kryer çdo test, është e nevojshme të krijoni rregulla përkatëse. Ato shkruhen në skedarë YAML, të quajtura 'grupe rregullash' (rulesets), dhe kanë strukturën e mëposhtme:

version: 1
description: Rregulla për skedarët spec të Kubernetes
type: Kubernetes
files:
  - "*.yaml"
rules:
   # lista e rregullave

(rule.yaml)

Le të shqyrtojmë atë më nga afër:

Fusha lloji tregon se cili tip konfigurimi do të përdorë config-lint. Për manifestet K8s, kjo të ashpër në Kubernetes.
Në fushën files përveç skedarëve mund të caktoni një dosje.
Fusha rregullat është e destinuar për të specifikuar testet e përdoruesve.

Supozoni se dëshironi të siguroheni që imazhet në Deployment gjithmonë shkarkohen nga një depo e besueshme si my-company.com/myapp:1.0. Rregulla për config-lint, që realizon një kontroll të tillë, do të duket si më poshtë:

- id: MY_DEPLOYMENT_IMAGE_TAG
  severity: FAILURE
  message: Deployment duhet të përdorë një etiketë të vlefshme imazhi
  resource: Deployment
  assertions:
    - every:
        key: spec.template.spec.containers
        expressions:
          - key: image
            op: starts-with
            value: "my-company.com/"

(rule-trusted-repo.yaml)

Për secilën rregull duhet të saktësohen atributet e mëposhtme:

id — identifikues unik i rregullit;
severity — mund të jetë FAILURE, KËSHILLË dhe NON_COMPLIANT;
message — në rast shkeljeje, përmbajtja e kësaj fushe shfaqet;
resource — tipi i burimit, për të cilin aplikohet kjo rregull;
assertions — lista e kushteve që do të vlerësohen për këtë burim.

Në rregullin më sipër assertion me emrin every verifikon që të gjitha kontenierët në Deployment (key: spec.templates.spec.containers) përdorin imazhe të besueshme (dmth, që fillojnë me my-company.com/).

Seti komplet i rregullave duket si më poshtë:

version: 1
description: Rregulla për skedarët spec të Kubernetes
type: Kubernetes
files:
  - "*.yaml"
rules:

 - id: DEPLOYMENT_IMAGE_REPOSITORY # !!!
    severity: FAILURE
    message: Deployment duhet të përdorë një depo të vlefshme të imazheve
    resource: Deployment
    assertions:
      - every:
          key: spec.template.spec.containers
          expressions:
            - key: image
              op: starts-with
              value: "my-company.com/"

(ruleset.yaml)

Për të provuar testin, le të ruajmë atë si check_image_repo.yaml. Të bëjmë verifikimin mbi skedarin base-valid.yaml:

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

[
  {
  "AssertionMessage": "Çdo shprehje dështon: Shprehja dhe dështon: imazhi nuk fillon me 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 duhet të përdorë një depo imazhesh të vlefshme",
  "Status": "FAILURE"
  }
]

Kontrolli përfundoi me dështim. Tani le të kontrollojmë manifestin e ardhshëm me një depo të saktë imazhesh:

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)

Po e nisim sërish testin me manifestin e mësipërm. Nuk u gjetën probleme:

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

Config-lint është një kornizë e avancuar që lejon krijimin e testeve të personalizuara për verifikimin e manifestëve YAML të Kubernetes duke përdorur YAML DSL.

Por çfarë nëse kërkohet logjikë dhe teste më të ndërlikuara? A nuk janë mundësitë e YAML të vogla për këtë? Çfarë nëse mund të krijoheshin teste në një gjuhë të plotë programimi?

4. Copper

Copper V2 — është një kornizë për validimin e manifestëve me teste të personalizuara (analog me config-lint).

Megjithatë, ai dallon nga i fundit që nuk përdor YAML për të përshkruar testet. Në vend të kësaj, testet mund të krijohen në JavaScript. Copper ofron një bibliotekë me disa mjete të bazuara, të cilat ndihmojnë në leximin e informacionit mbi objektet Kubernetes dhe raportimin e gabimeve.

Rendi i hapave për instalimin e Copper mund të gjendet në dokumentacionin zyrtar.

2.0.1 — lëshimi më i fundit i kësaj utilities në momentin e shkrimit të artikullit origjinal.

Si config-lint, Copper nuk ka teste të built-in. Le ta shkruajmë një. Le të kontrollojmë që deployment-et të përdorin imazhe konteinerësh vetëm nga depo të besueshme si my-company.com.

Krijoni një skedar check_image_repo.js me përmbajtjen e mëposhtme:

$$.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',"Imazhi " + $.metadata.name + " nuk është nga depo my-company.com", 1)
            }
        });
    }
});

Tani, për të kontrolluar manifestin tonë base-valid.yaml, përdorni urdhërin copper validate:

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

Kontrolli no_company_repo dështoi me rëndësi 1 për shkak se Imazhi http-echo nuk është nga depo my-company.com

Êshtë e qartë se me anë të copper mund të kryhen teste më komplekse — për shembull, të kontrollohen emrat e domeneve në manifestet Ingress ose të refuzohen pod’ët që funksionojnë në mënyrë privilegjuese.

Copper përmban funksione të ndryshme ndihmëse:

DockerImage lexon skedarin hyrës të specifikuar dhe krijon një objekt me atributet e mëposhtme:
- emri — emri i imazhit,
- tag — etiketa e imazhit,
- registry — regjistri i imazheve,
- registry_url — protokolli (https://) dhe regjistri i imazheve,
- fqin — vendndodhja e plotë e imazhit.
Funksioni findByName ndihmon për të gjetur burimin sipas tipit të dhënë (kind) dhe emrit (emri) nga skedari hyrës.
Funksioni findByLabels ndihmon për të gjetur burimin sipas tipit të dhënë (kind) dhe etiketave (labels).

Me të gjitha funksionet ndihmëse të disponueshme mund të njoheni këtu.

Sipërfaqësisht, ai ngarkon të gjithë skedarin YAML hyrës në një variabël $$ dhe e bën atë të disponueshme për skriptet (metodë e njohur për ata që kanë përvojë me jQuery).

Pika kryesore e Copper është e qartë: nuk keni nevojë të mësoni një gjuhë të specializuar dhe mund të shfrytëzoni mundësitë e ndryshme të JavaScript për të krijuar testet tuaja, si ndërhyrja e vargjeve, funksionet etj.

Duhet të theksohet gjithashtu se versioni aktual i Copper punon me versionin ES5 të motorit JavaScript, dhe jo me ES6.

Detajet janë të disponueshme në faqen zyrtare të projektit.

Megjithatë, nëse nuk e doni shumë JavaScriptin dhe preferoni një gjuhë, e cila është posaçërisht e destinuar për të krijuar kërkesa dhe përshkrimin e politikave, duhet të hedhni një sy te conftest.

5. Conftest

Conftest është një kornizë për kontrollin e të dhënave të konfigurimit. Përshtatet gjithashtu për testimin/verifikimin e manifestëve Kubernetes. Testet përshkruhen duke përdorur një gjuhë të specializuar të kërkesave Rego.

Instalimi i conftest mund të bëhet nëpërmjet udhëzimet, të dhënat e ofruara në faqen e projektit.

Në momentin e shkruarjes së artikullit origjinal, versioni më i fundit i disponueshëm ishte 0.18.2.

Si në rastin e config-lint dhe copper, conftest vjen pa ndonjë test të integruar. Le të provojmë atë dhe të shkruajmë politikën tonë. Si në shembujt e mëparshëm, do të kontrollojmë nëse imazhet e kontejnerëve vijnë nga një burim i besueshëm.

Krijoni një drejtorinë conftest-checks, dhe brenda saj — një skedar me emrin check_image_registry.rego me përmbajtjen e mëposhtme:

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])
}

Tani le të testojmë base-valid.yaml nëpërmjet 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

Testi pritet që dështojë, pasi imazhet vijnë nga një burim i paautorizuar.

Në skedarin Rego, ne përcaktojmë bllokun ndalo. Vërtetësia e tij konsiderohet si shkelje. Nëse janë disa blloqe, conftest i kontrollon ato të pavarur nga njëri-tjetri, dhe vërtetësia e ndonjërit prej blloqeve interpretohet si shkelje. ndalo Përveç daljes nga default, conftest mbështet formate JSON, TAP dhe tabelar - një mundësi tejet e dobishme, nëse duhet të integrohen raporte në pipeline ekzistuese CI. Formati i nevojshëm mund të caktohet me flagun

--output Për të lehtësuar debuggimin e politikave, conftest ka një flag.

--trace . Ai tregon ndjekjen e mënyrës se si conftest analizon skedarët e politikave të caktuar.Politikat conftest mund të publikohen dhe ndahen në regjistrat OCI (Open Container Initiative) në formën e artefakteve.

lejojnë publikimin e një artefakti ose nxjerrjen e një arti ekzistues nga regjistri i largët. Le të provojmë të publikojmë politikën që krijuam në regjistrin lokal Docker duke përdorur

Komandat push dhe pull conftest push Startoni regjistrin lokal Docker:.

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

Në një terminal tjetër kaloni në katalogun e krijuar më parë

$ conftest push 127.0.0.1:5000/amitsaha/opa-bundle-example:latest conftest-checks dhe ekzekutoni komandën e mëposhtme:

Nëse komanda i kaloi me sukses, do të shihni një mesazh të tillë:

2020/06/10 14:25:43 shtuar bundle me digjest: sha256:e9765f201364c1a8a182ca637bc88201db3417bacc091e7ef8211f6c2fd2609c

Tani krijoni një katalog të përkohshëm dhe ekzekutoni në të komandën

conftest pull . Ajo do ta shkarkojë paketën e krijuar nga komanda e mëparshme:$ cd $(mktemp -d) $ conftest pull 127.0.0.1:5000/amitsaha/opa-bundle-example:latest

Në katalogun e përkohshëm do të shfaqet një nënkatalog

, që përmban skedarin tonë të politikës: policy$ tree . └── policy └── check_image_registry.rego

Testet mund të kryhen direkt nga repository:

$ conftest test --update 127.0.0.1:5000/amitsaha/opa-bundle-example:latest base-valid.yaml .. DËSHTIM - base-valid.yaml - imazhi 'hashicorp/http-echo' nuk vjen nga regjistri my-company.com 2 teste, 1 kaloi, 0 paralajmërime, 1 dështim

Fatkeqësisht, DockerHub aktualisht nuk mbështetet. Prandaj, konsideroni se keni fat nëse përdorni

Azure Container Registry (ACR) ose regjistrin tuaj të vlast. Formati i artefakteve është i njëjtë si ai i

paketave Open Policy Agent (OPA), duke lejuar që conftest të ekzekutojë teste nga paketat ekzistuese OPA. Më shumë mbi ndarjen e politikave dhe funksionalitete të tjera të conftest mund të mësoni në

6. Polaris faqen zyrtare të projektit.

Mjeti i fundit që do të diskutohet në këtë artikull është

(Njoftimi i tij vitin e kaluar ne Polaris. e kemi përkthyer tashmë tani e përkthyer — shënim i përkthyesit.)

Polaris mund të instalohet në një klaster ose të përdoret në modalitetin e komandës. Siç e keni kuptuar, ai lejon analizën statike të manifestëve Kubernetes.

Kur punoni në modalitetin e komandës, janë të disponueshme teste të ndërtuara, që mbulojnë fusha si siguria dhe praktikat më të mira (analogjisht me kube-score). Për më tepër, mund të krijoni teste të personalizuara (si në config-lint, copper dhe conftest).

Me fjalë të tjera, Polaris kombinon përparësitë e të dy grupeve të mjeteve: me teste të ndërtuara dhe ato të personalizuara.

Për të instaluar Polaris në modalitetin e komandës, përdorni udhtimet në faqen e projektit..

Në momentin e shkruajtjes së artikullit origjinal, versioni i disponueshëm është 1.0.3.

Pasi të përfundojë instalimi, mund të lançoni polaris mbi manifestin base-valid.yaml me komandën e mëposhtme:

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

Ajo do të japë një varg në formatin JSON me një përshkrim të detajuar të testeve të kryera dhe rezultateve të tyre. Dalja do të ketë strukturën e mëposhtme:

{
  "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": [
    /* lista e gjatë */
  ]
}

Dalja e plotë është e disponueshme. këtu.

Si kube-score, Polaris identifikon probleme në ato fusha ku manifesti nuk i përmbush praktikat më të mira:

Mungojnë kontrollet e shëndetit të pod’ave.
Nuk janë specifikuar etiketa për imazhet e kontejnerëve.
Kontejneri ekzekutohet nën root.
Nuk janë specifikuar kërkesat dhe kufizimet për memorien dhe CPU.

Çdo testi, në varësi të rezultateve të tij, i jepet një gradë kriticizmi: warning ose danger. Për të mësuar më shumë rreth testeve të ndërtuara që ekzistojnë, referojuni dokumentacionin.

Nëse detajet nuk janë të nevojshme, mund të specifikoni flamurin --format score. Në këtë rast, Polaris do të nxjerrë një numër në intervalin nga 1 në 100 — score (dmth, vlerësimi):

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

Sa më afër të jetë vlerësimi 100, aq më i lartë është niveli i përputhshmërisë. Nëse kontrolloni kodin e diljes së komandës polaris audit, do të zbuloni se ai është 0.

Të detyrosh polaris audit të përfundojë me një kod jo zero mund të bëhet me dy flamuj:

Flamuri --set-exit-code-below-score pranon si argument një vlerë pragu në intervalin 1-100. Në këtë rast, komanda do të përfundojë me kodin e diljes 4, nëse vlerësimi është nën prag. Kjo është shumë e dobishme kur keni një vlerë pragu (p.sh., 75), dhe keni nevojë të merrni një alert nëse vlerësimi bie nën të.
Flamuri --set-exit-code-on-danger do të çojë në një përfundim me kod 3, nëse një nga testet e rrezikut përfundon me dështim.

Tani le të provojmë të krijojmë një test të personalizuar që kontrollon nëse imazhi merret nga një depo besuese. Testet e personalizuara përshkruhen në formatin YAML, dhe testi vetë përshkruhet me anë të JSON Schema.

Fragmenti i mëposhtëm YAML përshkruan një test të ri të quajtur checkImageRepo:

checkImageRepo:
  successMessage: Regjistri i imazhit është i vlefshëm
  failureMessage: Regjistri i imazhit nuk është i vlefshëm
  category: Imazhe
  target: Kontejner
  schema:
    '$schema': http://json-schema.org/draft-07/schema
    type: object
    properties:
      image:
        type: string
        pattern: ^my-company.com/.+$

Le të hedhim një sy më nga afër:

successMessage — kjo linjë do të shfaqet nëse testi përfundon me sukses;
failureMessage — ky mesazh do të shfaqet në rast dështimi;
category — tregon një nga kategoritë: Imazhe, Kontrolli i Shëndetit, Siguria, Networking dhe Burime;
target— përcakton se në cilin tip objekti (spec) aplikohet testi. Vlerat e mundshme: Litecoin, Pod ose Controller;
Testi vetë përshkruhet në objektin schema nëpërmjet JSON schema. Në këtë test, fjala kyçe pattern përdoret për të krahasuar burimin e imazhit me atë të kërkuar.

Për të ekzekutuar testin e mësipërm, duhet të krijoni konfigurimin e mëposhtëm të Polaris:

checks:
  checkImageRepo: danger
customChecks:
  checkImageRepo:
    successMessage: Regjistri i imazhit është i vlefshëm
    failureMessage: Regjistri i imazhit nuk është i vlefshëm
    category: Imazhe
    target: Kontejner
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          pattern: ^my-company.com/.+$

(polaris-conf.yaml)

Le të analizojmë skedarin:

Në fushën checks përshkruajnë testet dhe nivelin e rëndësisë së tyre. Duke qenë se është e dëshirueshme të merrni një paralajmërim kur imazhi merret nga një burim të pa sigurt, e vendosim këtu nivelin danger.
Testi vetë checkImageRepo pastaj përshkruhet në objektin customChecks.

Ruani skedarin si custom_check.yaml. Tani mund të ekzekutoni polaris audit me manifestin YAML që kërkon verifikim.

Të testojmë manifestin tonë base-valid.yaml:

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

Ekipa polaris audit ka ekzekutuar vetëm testin e personalizuar të caktuar më sipër, dhe ai nuk pati sukses.

Nëse e rregulloni imazhin në my-company.com/http-echo:1.0, Polaris do të përfundojë me sukses. Manifesti me ndryshimet tashmë është në repotitë e tij, kështu që ju mund të kontrolloni komandën e mëparshme në manifestin image-valid-mycompany.yaml.

Tani lind pyetja: si të ekzekutoni testet e integruara së bashku me ato të personalizuara? Lehtë! Thjesht duhet të shtoni identifikuesit e testeve të integruara në skedarin e konfigurimit. Si rezultat, ai do të duket si më poshtë:

kontrollon:
  cpuRequestsMissing: paralajmërim
  cpuLimitsMissing: paralajmërim
  # Kontrolla të tjera të ndërtuara..
  # ..
  # kontrolla të personalizuara
  checkImageRepo: rrezik # !!!
kontrollatEPersonalizuara:
  checkImageRepo:        # !!!
    mesazhiUSuksesshëm: Regjistri i imazhit është e vlefshme
    mesazhiFail: Regjistri i imazhit nuk është i vlefshëm
    kategoria: Imazhe
    objektivi: Kontejner
    skema:
      '$schema': http://json-schema.org/draft-07/schema
      lloji: objekt
      pronave:
        imazhi:
          lloji: string
          model: ^my-company.com/.+$

(config_with_custom_check.yaml)

Shembulli i plotë i skedarit të konfigurimit është i disponueshëm këtu.

Kontrolloni manifestin base-valid.yaml, duke përdorur testet e ndërtuara dhe ato të personalizuara, mund të bëhet me komandën:

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

Polaris plotëson testet e ndërtuara me ato të personalizuara, duke kombinuar kështu më të mirat nga të dy botët.

Nga ana tjetër, pamundësia për të përdorur gjuhë më të fuqishme, si Rego ose JavaScript, mund të shndërrohet në një faktor kufizues që pengon krijimin e testeve më të sofistikuara.

Informacione të tjera rreth Polaris janë të disponueshme në faqen e projektit.

CV

Ndërsa janë shumë mjete për të verifikuar dhe vlerësuar skedarët YAML të Kubernetes, është e rëndësishme të kemi një përvoje të qartë se si do të projektohen dhe ekzekutohen testet.

Për shembull, nëse marrim manifestet Kubernetes që kalojnë nëpër pipeline, kubeval do të ishte hapa i parë në atë pipeline. Ai do të monitoronte nëse përkdefined e objekteve përputhen me skemën e API Kubernetes.

Pasi të përfundojë një kontroll të tillë, do të kalojmë në teste më të sofistikuara, si përputhja me praktikat më të mira standarde dhe politikat e veçanta. Dhe këtu do të ishin të dobishme kube-score dhe Polaris.

Për ata që kanë kërkesa të komplikuara dhe kanë nevojë të konfigurojnë testet në detaje, do të shkonin copper, config-lint dhe conftest.

Conftest dhe config-lint përdorin YAML për të caktuar teste të personalizuara, ndërsa copper ofron akses në një gjuhë të plotë programimi, që e bën atë një zgjedhje mjaft tërheqëse.

Nga ana tjetër, a duhen përdorur një nga këto mjete dhe kështu të krijohen të gjitha testet manualisht, apo të preferohet Polaris dhe të shtohet vetëm ajo që është e nevojshme? Nuk ka një përgjigje të qartë për këtë pyetje.

Tabela më poshtë përmban një përshkrim të shkurtër të çdo mjeti:

Mjeti
Qëllimi
Mangësitë
Testet e personalizuara

kubeval
Kontrollojnë manifestet YAML për përputhje me një version të caktuar të skemës së API
Nuk di të punojë me CRD
Jo

kube-score
Analizon manifestet YAML për përputhjen me praktikat më të mira
Nuk mund të zgjidhet versioni juaj i API Kubernetes për të kontrolluar burimet
Jo

copper
Kornza i përgjithshëm për krijimin e testeve të personalizuara JavaScript për manifestet YAML
Nuk ka teste të integruara. Dokumentacion i varfër
Po.

config-lint
Kornza e përgjithshme për krijimin e testeve në një gjuhë të orientuar nga subjektet, e integruar në YAML. Mbështet formate të ndryshme konfiguracionesh (p.sh., Terraform)
Nuk ka teste gati. Mund të ketë mungesë të asertciave dhe funksioneve të integruara
Po.

conftest
Kornza për krijimin e testeve të personalizuara në Rego (një gjuhë e specializuar kërkese). Lejon ndarjen e politikave përmes bundles OCI
Nuk ka teste të integruara. Duhet të mësohet Rego. Docker Hub nuk mbështetet gjatë publikimit të politikave
Po.

Polaris
Analizon manifestet YAML për t'u siguruar që përputhen me praktikat më të mira standarde. Lejon krijimin e testeve të personalizuara me ndihmën e JSON Schema
Mund të mos mjaftojnë mundësitë e testeve të bazuara në JSON Schema
Po.

Pasi këto mjete nuk varen nga aksesimi në klasterin Kubernetes, ato janë të lehta për t'u instaluar. Ato lejojnë filtrimin e skedarëve burimorë dhe ofrojnë reagim të shpejtë autorëve të kërkesave pull në projekte.