Kubernetes YAML-i valideerimine parimate praktikate ja poliitikate järgimiseks

Märkus tõlke kohta.: K8s-keskkondade YAML-konfiguratsioonide arvu kasvuga muutub nende automatiseeritud kontrollimise vajadus üha olulisemaks. Selle ülevaate autor on mitte ainult valinud olemasolevad lahendused, vaid ka vaadanud, kuidas need töötavad, kasutades näiteks Deployment'i. Tõenäoliselt on see väga informatiivne neile, keda see teema huvitab.

TL;DR: Artiklis võrreldakse kuut staatilist tööriista Kubernetes YAML-failide kontrollimiseks ja hindamiseks parimate praktikate ja nõuete järgimise osas.

Kubernetes'e laadimised määratakse tavaliselt YAML-dokumentide kujul. Üks suurimaid probleeme YAML-iga on piirangute või manifestifailide vaheliste suhete määramise keerukus.

Mis siis, kui me peame veenduma, et kõik klastrisse juurutatud pildid pärinevad usaldusväärsest registrist?

Kuidas vältida Deployment'ide saatmist klastrisse, mille jaoks ei ole määratud PodDisruptionBudgets?

Statistilise testimise integreerimine võimaldab avastada vigu ja poliitikate rikkumisi juba arenduse käigus. Nii suureneb ressursside määratlemise täpsuse ja ohutuse garantii ning tõenäosus, et tootmislaadimised järgivad parimaid praktikaid.

Kubernetes'e YAML-failide staatilise kontrollimise ökosüsteemi saab jagada järgmistesse kategooriatesse:

• API- valideerijad. Selle kategooria tööriistad kontrollivad YAML-manifesti Kubernetes'e API-serveri nõuete järgimise poolest.
• Valmis testijad. Selle kategooria tööriistad tulevad koos valmis testidega, mis käsitlevad turvalisust, parimate praktikate järgimist jne.
• Kohandatud valideerijad. Selle kategooria esindajad võimaldavad luua kohandatud teste erinevates keeltes, näiteks Regos ja Javascriptis.

Selles artiklis kirjeldame ja võrreldame kuut erinevat tööriista:

1. kubeval;
2. kube-score;
3. config-lint;
4. copper;
5. conftest;
6. Polaris.

Olgu, alustame siis!

Deployment'ide kontrollimine

Enne tööriistade võrdlemise alustamist loome aluse, millel me neid testime.

Allolev manifest sisaldab mitmeid vigu ja parimate praktikate järgimise puudujääke: kui palju neist suudad sina leida?

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)

Kasutame seda YAML-i erinevate tööriistade võrdlemiseks.

Ülaltoodud manifest base-valid.yaml ja muud selle artikli manifestid leiate Git-repositooriumist.

Manifest kirjeldab veebirakendust, mille peamine ülesanne on vastata sõnumiga „Hello World“ pordile 5678. Selle saab juurutada järgmist käsku kasutades:

kubectl apply -f hello-world.yaml

Ja nüüd — kontrollige tööd:

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

Mine nüüd aadressile http://localhost:8080 ja kinnita, et rakendus töötab. Kuid kas see järgib parimaid tavasid? Vaatame järgi.

1. Kubeval

Kubevali aluseks on idee, et kõik suhtlemine Kubernetesega toimub läbi tema REST API. Teisisõnu, saate kasutada API skeemi, et kontrollida, kas antud YAML sellele vastab. Vaatame kühendust. Kubeval'i paigaldusjuhised on saadaval projekti veebilehel. Originaali kirjutamise ajal oli saadaval versioon 0.15.0.

Pärast paigaldamist laske sellel analüüsida ülaltoodud manifesti: $ kubeval base-valid.yaml PASS - base-valid.yaml sisaldab kehtivat Deployment'i (http-echo) PASS - base-valid.yaml sisaldab kehtivat Service'i (http-echo)

Kui kõik õnnestub, lõpetab kubeval töö exit-koodiga 0. Selle saab kontrollida järgmisel viisil:

$ echo $? 0

Nüüd katsetame kubeval teise manifestiga:

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

Kas saate palja silmaga probleemi määrata? Käivitage:

$ kubeval kubeval-invalid.yaml
WARN - kubeval-invalid.yaml sisaldab kehtivat Deployment'i (http-echo) - selector: selector on vajalik
PASS - kubeval-invalid.yaml sisaldab kehtivat Service'i (http-echo)

# kontrollime tagastuskoode
$ echo $?
1

(Ressurssi ei suudeta valideerida.)

Deployment'id, mis kasutavad API versiooni

apps/v1

, peavad sisaldama selektorit, mis vastab pod'i märgisele. Ülaltoodud manifest ei sisalda selektorit, seetõttu teatas kubeval veast ja lõpetas mitte-null koodiga.

Huvitav, mis juhtub, kui käivitada kubectl apply -fselle manifestiga?

Huvitav, mis juhtub, kui täitmine kubectl apply -f selle manifestiga?

No nii, proovime siis;

$ 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

Just see, the error that kubeval warned about. You can fix it by adding a selector:

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)

Kubevali tööriistade eelis on see, et sarnaseid vigu saab tuvastada varases juurutamisfaasis.

Lisaks ei vaja nende kontrollide jaoks klastrisse pääsu: neid saab teha ka offline.

Kubeval kontrollib vaikimisi ressursse vastavuses Kubernetes API kõige uuema skeemiga. Kuid enamikul juhtudel võib teil olla vaja kontrollida vastavust konkreetse Kubernetes versiooniga. Seda saab teha lipuga --kubernetes-version:

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

Pange tähele, et versioon tuleb esitada formaadis Major.Minor.Patch.

To View the list of versions that are supported for validation, see the JSON schema on GitHub, which kubeval uses for validation. If you need to run kubeval offline, download the schemas and specify their local location using the flag --schema-location.

Lisaks üksikutele YAML-failidele, saab kubeval töötada ka kataloogide ja stdin'iga.

Samuti integreerub Kubeval hõlpsasti CI-pipeline'iga. Need, kes soovivad teste enne manifestide saatmist klastrisse läbi viia, on rõõmsad teada, et kubeval toetab kolme väljundiformaati:

1. Tavaline tekst;
2. JSON;
3. Test Anything Protocol (TAP).

Ja ükskõik millist formaati saab kasutada väljundi edasiseks töötlemiseks, et luua soovitud tulemuste kokkuvõte.

Üks kubevali puudustest on see, et praegu ei kontrolli see Custom Resource Definitions (CRDs) vastavust. Kuid kubeval'i saab seadistada nende ignoreerimiseks.

Kubeval on suurepärane tööriist ressursside kontrollimiseks ja hindamiseks; tõsi, on oluline rõhutada, et testi edukas läbimine ei garanteeri, et ressurss vastab parimatele praktikatele.

Näiteks sildi kasutamine latest Konteiner ei vasta parimaid tavasid. Kuid kubeval ei loe seda veaks ega teata sellest. See tähendab, et selline YAML-i kontroll lõpeb ilma hoiatusteta.

Aga mis siis, kui peame hindama YAML-i ja tuvastama rikkumisi, näiteks sildi latest? Как проверить YAML-файл на соответствие лучшим практикам?

2. Kube-score

Kube-score analüüsib YAML-i manifestide ja hindab neid sisseehitatud testide põhjal. Need testid valitakse turvalisuse ja parimate praktikate soovituste järgi, näiteks:

• Konteineri käitamine ei ole root'i all.
• Pod-ide tervisekontrollide olemasolu.
• Ressursside request'ide ja limit'ide määramine.

Testi tulemuseks on kolm tulemust: OK, HOIATUS ja KRITILINE.

Kube-score'i saab proovida veebis või installida seda kohalikult.

Originaalartikli kirjutamise ajal oli kube-score'i uusim versioon 1.7.0.

Proovime seda meie manifestil base-valid.yaml:

$ kube-score score base-valid.yaml

apps/v1/Deployment http-echo
[KRITILINE] Konteineri pildil silti
  · http-echo -> Pilt, millel on viimane silt
      Soovitatav on kasutada fikseeritud silti, et vältida juhuslikke värskendusi
[KRITILINE] Pod NetworkPolicy
  · Pod-il puudub vastav võrgupoliitika
      Looge NetworkPolicy, mis suunab selle pod'i
[KRITILINE] Pod Probes
  · Konteinerel puudub readinessProbe
      ReadinessProbe'i tuleks kasutada, et näidata, millal teenus on valmis liiklust vastu võtma.
      Ilma selleta riskib Pod liikluse saamisega enne, kui see on käivitatud. Seda kasutatakse ka väljaandmisel ning see võib ära hoida seisakuid, kui uue rakenduse versioon ebaõnnestub.
      Rohkem teavet: https://github.com/zegl/kube-score/blob/master/README_PROBES.md
[KRITILINE] Konteineri turvakontekst
  · http-echo -> Konteineril puudub konfigureeritud turvakontekst
      Määrake securityContext, et käitada konteinerit turvalisemas kontekstis.
[KRITILINE] Konteineri ressursid
  · http-echo -> CPU piirangut ei ole seadistatud
      Ressursipiirangud on soovitatavad, et vältida ressursi DDOS-i. Määrake resources.limits.cpu
  · http-echo -> Mälupiirangut ei ole seadistatud
      Ressursipiirangud on soovitatavad, et vältida ressursi DDOS-i. Määrake resources.limits.memory
  · http-echo -> CPU request'i ei ole seadistatud
      Ressursi soovitused on soovitatavad, et veenduda, et rakendus saab käivituda ja töötada ilma kokku kukkumata. Määrake resources.requests.cpu
  · http-echo -> Mälrequest'i ei ole seadistatud
      Ressursi soovitused on soovitatavad, et veenduda, et rakendus saab käivituda ja töötada ilma kokku kukkumata.
      Määrake resources.requests.memory
[KRITILINE] Deployment'il puudub PodDisruptionBudget
  · Vastavat PodDisruptionBudget'i ei leitud
      Soovitatav on määrata PodDisruptionBudget, et vältida ootamatuid seisakuid Kubernetes'e hooldusoperatsioonide ajal, näiteks sõlme tühjendamisel.
[HOIATUS] Deployment'il on host PodAntiAffinity
  · Deployment'il ei ole seadistatud host podAntiAffinity't
      Soovitatav on seada podAntiAffinity, et takistada mitmete pod'ide paigutamist samasse sõlme. See suurendab kättesaadavust juhul, kui sõlm muutub kättesaamatuks.

YAML läbib kubeval'i kontrolle, samas kui kube-score osutab järgmistele puudustele:

• Tervisekontrollid ei ole seadistatud.
• CPU ja mälu jaoks puuduvad request'id ja limit'id.
• Pod disruption budgets ei ole määratud.
• Puuduvad eraldi eksistentsi reeglid (anti-affinity) maksimaalse kättesaadavuse saavutamiseks.
• Konteiner töötab root-kasutajana.

Kõik need on asjakohased märkused puuduste kohta, mida tuleb kõrvaldada, et Deployment muutuks tõhusamaks ja usaldusväärsemaks.

Meeskond kube-score esitab teavet loetavas vormingus, sealhulgas kõiki rikkumisi tüübi HOIATUS ja KRITILINE, mis on arendamise ajal väga abiks.

Soovijad kasutada seda tööriista CI-pipeline'is saavad lubada kompaktsemat väljundit, kasutades lippu --output-format ci (sel juhul kuvatakse ka testid tulemusega 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 piiri ei ole seatud
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Mälupiiri ei ole seatud
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) CPU nõuet ei ole seatud
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Mälenuhte nõuet ei ole seatud
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Pilti ei ole seadistatud viimase märgisega
[OK] http-echo apps/v1/Deployment
[CRITICAL] http-echo apps/v1/Deployment: Podil ei ole vastavat võrgupoliitikat
[CRITICAL] http-echo apps/v1/Deployment: Konteineril puudub readinessProbe
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Konteineril ei ole seadistatud turvakonteksti
[CRITICAL] http-echo apps/v1/Deployment: Ei leitud vastavat PodDisruptionBudget'i
[WARNING] http-echo apps/v1/Deployment: Deployment'il ei ole seadistatud host-podAntiAffinity't
[OK] http-echo v1/Service
[OK] http-echo v1/Service
[OK] http-echo v1/Service
[OK] http-echo v1/Service

Sarnaselt kubeval'iga tagastab kube-score mitte-null väljumiskoodi, kui mõni test lõppeb veaga. KRITILINESarnast töötlemist saab lubada ka HOIATUS.

Lisaks on olemas võimalus kontrollida ressursse erinevate API versioonide vastavust (nagu ka kubeval puhul). Siiski, see teave on 'hardcode'itud ise kube-score'i: ei saa valida teist Kubernetes'i versiooni. Selline piirang võib olla suur probleem, kui kavatsete klastrit uuendada või teil on mitu klastrit erinevate K8s versioonidega.

Pange tähele, et on juba olemas issue ettepanekuga selle võimaluse rakendamiseks.

Kube-score'ist saab rohkem teavet leida ametlikul kodulehe.

Kube-score testid on suurepärane tööriist parimate praktikate rakendamiseks, kuid mis siis, kui on vaja teha muudatusi testis või lisada oma reeglid? Kahjuks ei ole see võimalik.

Kube-score ei ole laiendatav: poliitikaid ei saa lisada ega kohandada.

Kui on vaja kirjutada kohandatud teste poliitikate vastavuse kontrollimiseks, saab kasutada ühte järgmistest neljast tööriistast: config-lint, copper, conftest või polaris.

3. Config-lint

Config-lint on YAML, JSON, Terraform, CSV ja Kubernetes manifestide konfiguratsioonifailide valideerimise tööriist.

Selle installimiseks saavad kasutada juhiseid projekti veebilehelt.

Originaali kirjutamise hetkel on praegune versioon — 1.5.0.

Config-lint ei sisalda sisseehitatud teste Kubernetes'i manifestide kontrollimiseks.

Igaks testiks tuleb luua vastavad reeglid. Need salvestatakse YAML-failidesse, mida nimetatakse «reeglite komplektideks» (rulesets), ja neil on järgmine struktuur:

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

(rule.yaml)

Vaatame seda lähemalt:

• Väli type määra, millist tüüpi konfiguratsiooni config-lint kasutab. Kubernetes'i manifestide jaoks on see alati Kubernetes.
• Väljal files nende failide kõrval saab määrata ka kausta.
• Väli rules on mõeldud kasutaja määratud testide määratlemiseks.

Oletame, et soovite veenduda, et pildid Deployment’is laaditakse alati usaldusväärsest repositooriumist nagu my-company.com/myapp:1.0. Config-linti reegel sarnase kontrolli teostamiseks näeb välja järgmine:

- id: MY_DEPLOYMENT_IMAGE_TAG
  severity: FAILURE
  message: Deployment peab kasutama kehtivat pilditagumist
  resource: Deployment
  assertions:
    - every:
        key: spec.template.spec.containers
        expressions:
          - key: image
            op: starts-with
            value: "my-company.com/"

(rule-trusted-repo.yaml)

Iga reegli puhul peavad olema määratud järgmised atribuudid:

• id — unikaalne reegli identifikaator;
• severity — võib olla FAILURE, HOIATUS ja NON_COMPLIANT;
• message — reegli rikkumise korral kuvatakse selle rea sisu;
• resource — ressursitüüp, millele see reegel kehtib;
• assertions — loetelu tingimustest, mida hinnatakse antud ressursi suhtes.

Ülaltoodud reeglis assertion nimega every kontrollib, et kõik konteinerid Deployment’is (key: spec.templates.spec.containers) kasutaksid usaldusväärseid pilte (st need, mis algavad my-company.com/).

Kogu reeglite komplekt näeb välja järgmiselt:

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

 - id: DEPLOYMENT_IMAGE_REPOSITORY # !!!
    severity: FAILURE
    message: Deployment peab kasutama kehtivat pildirepositooriumi
    resource: Deployment
    assertions:
      - every:
          key: spec.template.spec.containers
          expressions:
            - key: image
              op: starts-with
              value: "my-company.com/"

(ruleset.yaml)

Selle testi katsetamiseks salvestame selle kui check_image_repo.yaml. Käivitame faili kontrollimiseks testimise base-valid.yaml:

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

[
  {
  "AssertionMessage": "Iga väljendus ebaõnnestus: Ja väljendus ebaõnnestus: pilt ei alga 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": "Käivitus peab kasutama kehtivat pildi tugiteenust",
  "Status": "FAILURE"
  }
]

Kontroll lõppes ebaõnnestumisega. Nüüd vaatame järgmist manifeste, kasutades õiget pildi tugiteenust:

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)

Käivitame sama testi ülaltoodud manifeste kasutades. Probleeme ei leitud:

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

Config-lint on perspektiivne raamistiku, mis võimaldab luua enda teste Kubernetes YAML-manifestide kontrollimiseks YAML DSL abil.

Aga mida teha, kui toimub keerulisem loogika ja testimised? Kas YAML võimalused ei ole selle jaoks liiga väikesed? Mida, kui saaks luua teste täisfunktsionaalses programmeerimiskeeles?

4. Copper

Copper V2 on raamistiku, mis valideerib manifeste kasutades kasutajate teste (nagu config-lint).

Erinevalt viimasest ei kasuta see teste kirjeldamisel YAML-i. Selle asemel saab teste luua JavaScriptis. Copper pakub raamatukogusid mitmete põhivahenditega, mis aitavad lugeda teavet Kubernetes objektide kohta ja aru anda vigadest.

Copperi installimise sammude jada leiab ametlikust dokumentatsioonist.

2.0.1 on see utiliidi kõige uuem versioon originaalse artikli kirjutamise ajal.

Nagu config-lint, ei ole Copperil siserakendusi. Kirjutame ühe. Oletame, et see kontrollib, et käivitused kasutavad konteineripilte ainult usaldusväärsetest tugiteenustest nagu my-company.com.

Looge fail check_image_repo.js järjgnevate sisuga:

$$.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',"Pilt " + $.metadata.name + " ei ole my-company.com tugiteenusest", 1)
            }
        });
    }
});

Nüüd, et kontrollida meie manifesti base-valid.yaml, kasutage käsku 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

On selge, et copper võimaldab läbi viia keerukamaid teste — näiteks kontrollida domeeninimesid Ingress'i manifesteerimisel või tagasi lükata pod'e, mis töötavad privileege tasemel.

Copperis on erinevad teenusfunktsioonid:

• DockerImage loeb määratud sisendfaili ja loob objekti järgmiste atribuutidega:
  • nimi — pildi nimi,
  • tag — pildi silt,
  • registry — piltide register,
  • registry_url — protokoll (https://) ja piltide register,
  • fqin — pildi täielik asukoht.
• Funktsioon findByName aitab leida ressursi antud tüübi (kind) ja nime (nimi) põhjal sisendfailist.
• Funktsioon findByLabels aitab leida ressursi määratud tüübi (kind) ja siltide (labels).

Kõigi kätte saadavate teenusfunktsioonidega saab tutvuda siin.

Seda laetakse vaikimisi kogu sisend-YAML-fail muutuja sisse $$ ja see on skriptidele kergesti kättesaadav (tuntud meetod neile, kes on töötanud jQuery'ga).

Copperi peamine eelis on ilmne: teil ei ole vaja omandada spetsialiseeritud keelt ja saate kasutada erinevaid JavaScripti võimalusi oma testide loomiseks, nagu stringide interpoleerimine, funktsioonid jne.

Oluline on märkida, et Copperi praegune versioon töötab JavaScripti ES5 mootoriversiooniga, mitte ES6-ga.

Lisainfot leiate projekti ametlikult veebilehelt.

Kuid kui te ei armasta eriti JavaScripti ja eelistate keelt, mis on spetsiaalselt loodud päringute loomiseks ja poliitikate kirjeldamiseks, peaksite tähelepanu pöörama conftest'ile.

5. Conftest

Conftest on raamistik konfiguratsioonide kontrollimiseks. Sobib ka Kubernetes'i manifestide testimiseks/verifitseerimiseks. Testid on kirjeldatud spetsialiseeritud päringute keeles Rego.

Conftest'i saab installida juhiseid, mis on välja toodud projekti lehel.

Kuna algse artikli kirjutamise ajal oli viimane kättesaadav versioon 0.18.2.

Sarnaselt config-lint'ile ja copper'ile, ei sisalda conftest mingeid sisseehitatud teste. Proovime seda ja kirjutame oma poliitika. Nagu eelmistel näidetel, kontrollime, kas konteinerite pildid pärinevad usaldusväärsest allikast.

Looge kataloog conftest-checks, ja sinna — fail nimega check_image_registry.rego järjgnevate sisuga:

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

Nüüd katsetame base-valid.yaml läbi 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

Test ebaõnnestus, kuna pildid pärinevad usaldamatust allikast.

Rego failis määratleme bloki deny. Selle tõde loetakse rikkumiseks. Kui bloki deny on mitu, kontrollib conftest neid iseseisvalt ja mistahes bloki tõde käsitletakse rikkumisena.

Lisaks vaikeväljundile toetab conftest JSON, TAP ja tabeliformaati — väga kasulik omadus, kui soovite aruandeid integreerida olemasolevasse CI torustikku. Soovitud formaati saab määrata lipuga --output.

Poliitikate tõrkeotsinguks on conftestis lipp --trace. See väljastab jälgimise, kuidas conftest määratud poliitikafaile analüüsib.

Conftest poliitikaid saab avaldada ja jagada OCI-registreerimisüksustes (Open Container Initiative) artefaktidena.

Käsklused push ja pull lubavad artefakti avaldamist või olemasoleva artefakti tõmbamist kaugregistrist. Proovime avaldada loodud poliitika meie kohalikku Docker registreerimisse conftest push.

Käivitage kohalik Docker register:

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

Teises terminalis liikuge varasema loomise kausta conftest-checks ja käivitage järgmine käsk:

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

Kui käsk õnnestus, näete järgmise tüüpi teateid:

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

Nüüd looge ajutine kaust ja käivitage seal käsk conftest pull. See taandab selles loodud paketi:

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

Ajutises kaustas ilmub alamkaust policy, mis sisaldab meie poliitikafaili:

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

Testimiseks saab otse hoidlast:

$ 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

Kahjuks ei toetata praegu DockerHub'i. Niisiis, looge endale õnne, kui kasutate Azure Container Registry (ACR) või oma kohalikke registerit.

Artefaktide formaat on sama mis Open Policy Agent paketidel. (OPA), mis võimaldab conftesti kasutada testide käivitamiseks olemasolevatest OPA pakettidest.

Rohkem conftesti poliitikate jagamise ja teiste omaduste kohta leiate projekti ametlikult veebilehelt.

6. Polaris

Viimane tööriist, millest selles artiklis juttu tuleb, on Polaris. (Eelmise aasta teadaanne me oleme juba tõlkinud — märkus tõlke kohta.)

Polarist saab paigaldada klastrisse või kasutada käsurežiimis. Nagu te juba arvasite, võimaldab see Kubernetes'i manifestide staatilist analüüsi.

Käsurežiimis on saadaval sisseehitatud testid, mis katab selliseid valdkondi nagu turvalisus ja parimad praktikad (sarnaselt kube-score'iga). Samuti saab luua oma teste (nagu config-lint, copper ja conftest).

Teisisõnu, Polaris ühendab endas mõlema kategooria tööriistade eelised: nii sisseehitatud kui ka kasutaja loodud testid.

Polari käsurežiimis installimiseks järgige projekti veebisaidi juhiseid..

Origināli artikli kirjutamise hetkel on saadaval versioon 1.0.3.

Pärast installimise lõpetamist saab polaris’e manifesti käivitada base-valid.yaml järgmise käsuga:

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

See väljastab JSON-formaadis rea, kus on üksikasjalik ülevaade tehtud testidest ja nende tulemustest. Väljundil on järgmine struktuur:

{
  "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": [
    /* pikk nimekiri */
  ]
}

Täielik väljund on saadaval siin.

Nagu kube-score, tuvastab Polaris probleemid nendes valdkondades, kus manifest ei vasta parimatele praktikatele:

• Pod'i tervisekontrollid puuduvad.
• Konteineripiltide jaoks märke ei ole määratud.
• Konteiner töötab root-kasutajana.
• Mälu ja CPU jaoks ei ole määratud request'e ja limit'e.

Iga testile määratakse vastavalt sellele, millised on nende tulemused, kriitilisuse tase: warning või danger. Lisateabe saamiseks olemasolevate sisseehitatud testide kohta pöörduge dokumentatsioon.

Kui detailid pole vajalikud, saate määrata lipu --format score. Sel juhul väljendab Polaris numbrit vahemikus 1 kuni 100 — hinnang (st skoor):

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

Mida lähemal hinnang 100-le, seda suurem on vastavusaste. Kui kontrollite käsu polaris audit, leiate, et see on 0.

Sundida polaris audit lõpetama mittesnullkoodiga saab kahe lipu abil:

• Lipp --set-exit-code-below-score võtab argumentidena läveväärtuse vahemikus 1–100. Sel juhul lõpeb käsk väljaandmise koodiga 4, kui hind jääb allapoole läveväärtust. See on väga kasulik, kui teil on mõni läveväärtus (ütleme 75) ja soovite saada hoiatust, kui hind langeb madalamale.
• Lipp --set-exit-code-on-danger toob kaasa selle, et käsk lõpeb koodiga 3, kui ükski ohtlike testide seast ebaõnnestub.

Nüüd proovime luua kohandatud testi, mis kontrollib, kas pilt on saadud usaldusväärsest registrist. Kohandatud testid määratletakse YAML formaadis ja test ise kirjeldatakse JSON skeemi abil.

Järgmine YAML-koodi fragment kirjeldab uut testi, mida nimetatakse checkImageRepo:

checkImageRepo:
  successMessage: Pildiregister on kehtiv
  failureMessage: Pildiregister ei ole kehtiv
  category: Pildid
  target: Konteiner
  schema:
    '$schema': http://json-schema.org/draft-07/schema
    type: object
    properties:
      image:
        type: string
        pattern: ^my-company.com/.+$

Vaadakem sellele lähemalt:

• successMessage — see rida kuvatakse, kui test lõpeb edukalt;
• failureMessage — see sõnum kuvatakse, kui test ebaõnnestub;
• category — näitab ühte kategooriat: Pildid, Tervise Kontrollerid, Turve, Võrgundus ja Ressursid;
• target— määratleb, millisele objekti tüübile (spec) test rakendub. Võimalikud väärtused: Konteiner, Pod või Kontroller;
• Test ise määratakse objektis schema kasutades JSON skeemi. Käesolevas testis kasutatakse märksõna pattern pildi allika võrreldamiseks nõutud väärtusega.

Eelneva testi käivitamiseks on vajalik järgmise Polaris konfiguratsiooni loomine:

checks:
  checkImageRepo: danger
customChecks:
  checkImageRepo:
    successMessage: Pildiregister on kehtiv
    failureMessage: Pildiregister ei ole kehtiv
    category: Pildid
    target: Konteiner
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          pattern: ^my-company.com/.+$

(polaris-conf.yaml)

Vaatame faili:

• Väljal checks määratlevad testid ja nende tõsiduse taseme. Kuna on soovitav saada hoiatust, kui pilt saadakse usaldusväärsest allikast, määrame siia taseme danger.
• Test checkImageRepo määratakse seejärel objektis customChecks.

Salvesta fail nimega custom_check.yaml. Nüüd saab käivitada polaris audit YAML-maniifistiga, mis vajab kontrollimist.

Testime meie maniifisti base-valid.yaml:

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

Meeskond polaris audit käivitas ainult eespool määratud kohandatud testi ja see ebaõnnestus.

Kui parandada pilti my-company.com/http-echo:1.0, Polaris lõpetab edukalt. Muudetud maniifist on juba olemas hoidlad, nii et saate kontrollida eelmist käsku manifestis image-valid-mycompany.yaml.

Nüüd tekib küsimus: kuidas käivitada sisseehitatud teste koos kasutaja loodud testidega? Kergesti! Lihtsalt lisage sisseehitatud testide ID-d konfiguratsioonifaili. Seetõttu näeb see välja järgmiselt:

checks:
  cpuRequestsMissing: warning
  cpuLimitsMissing: warning
  # Teised sisseehitatud kontrollid..
  # ..
  # kasutaja loodud kontrollid
  checkImageRepo: danger # !!!
customChecks:
  checkImageRepo:        # !!!
    successMessage: Pildi register on kehtiv
    failureMessage: Pildi register ei ole kehtiv
    category: Pildid
    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)

Täieliku konfiguratsioonifaili näidis on saadaval siin.

Kontrollige manifesti base-valid.yaml, kasutades sisseehitatud ja kasutaja loodud teste, saab käsklusega:

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

Polaris täiendab sisseehitatud teste kasutaja loodud testidega, kombineerides kahte maailma parimat.

Teisest küljest võib arenenumate testide loomise takistuseks olla võimetus kasutada võimsamaid keeli nagu Rego või JavaScript.

Lisainfot Polari kohta on saadaval projekti lehelt.

Elulookirjeldus

Kuigi on mitmeid tööriistu Kubernetes YAML-failide kontrollimiseks ja hindamiseks, on oluline omada selget arusaama, kuidas teste projekteerida ja läbi viia.

Näiteks, kui võtta Kubernetes'e manifeedid, mis läbivad torustiku, võiks kubeval olla esimene samm selles torustikus.See jälgiks, kas objektide määratlused vastavad Kubernetes'e API skeemile.

Pärast sellist kontrollimist oleks võimalik liikuda keerukamate testide juurde, mis vastavad parimatele praktikatele ja konkreetsetele poliitikatele. Ja siin tuleksid appi kube-score ja Polaris.

Neile, kellel on keerukad nõuded ja vajadus teste üksikasjalikult kohandada, sobivad copper, config-lint ja conftest..

Conftest ja config-lint kasutavad kasutaja loodud testide määramiseks YAML-i, samas kui copper pakub juurdepääsu täisfunktsionaalsele programmeerimiskeelele, mis muudab selle üsna atraktiivseks valikuks.

Kuid küsimus on, kas kasutada mõnda neist tööriistadest ja seega luua kõik testid käsitsi, või eelistada Polaris't ning kirjutada sinna vaid vajalikud osad? Sellele küsimusele ei ole üheselt mõistetavat vastust..

Allpool tabel sisaldab iga tööriista lühikirjeldust:

Tööriist
Eesmärk
Puudused
Kasutajatestid

Kubeval'i paigaldusjuhised on saadaval projekti veebilehel.
Kontrollib YAML-manifeste vastavust kindla API skeemi versioonile
Ei oska töötada CRD-dega
Ei

kube-score
Analüüsib YAML-manifeste vastavust parimatele praktikatele
Ei saa valida oma Kubernetes API versiooni ressursside kontrollimiseks
Ei

copper
Üksnes raamistik oma JavaScript-testide loomiseks YAML-manifeste jaoks
Pole sisseehitatud teste. Piiratud dokumentatsioon
Jah

config-lint
Üksnes raamistik testide loomiseks objekti-orienteeritud keeles, mis on sisseehitatud YAML-i. Toetab erinevaid konfiguratsiooniformaate (nt Terraform)
Pole valmis teste. Sisseehitatud väiteid ja funktsioone võib olla liiga vähe
Jah

conftest
Raamistik oma testide loomiseks Rego-s (spetsialiseeritud päringute keel). Lubab jagada poliitikaid OCI paketina
Pole sisseehitatud teste. Tuleb õppida Rego. Docker Hub ei toeta poliitikate avaldamist
Jah

Polaris
Analüüsib YAML-manifeste vastavust standardsetele parimatele praktikatele. Lubab luua oma teste JSON Schema abil
JSON Schema põhiseid teste võib jääda puudu
Jah

Kuna need tööriistad ei sõltu juurdepääsust Kubernetes klastrile, on nende paigaldamine lihtne. Need võimaldavad allikafailide filtreerimist ja annavad kiire tagasiside pull requestide autoritele projektides.

P.S. tõlkijalt

Lugege ka meie blogist:

• «Esitletud on Polaris Kubernetes klastrite hea seisundi hoidmiseks»;
• «YAML-tugi Vim Kubernetes jaoks»;
• «Google'i versiooni järgi 7 parimat praktikat konteinerite kasutamiseks».

Allikas: habr.com