🥇Kubernetes YAML:n validointi parhaita käytäntöjä ja käytäntöjä vastaan

Huomautus. käännös: K8s-ympäristöjen YAML-kokoonpanojen kasvavan määrän myötä niiden automaattisen todentamisen tarve tulee yhä kiireellisemmäksi. Tämän katsauksen kirjoittaja ei vain valinnut olemassa olevia ratkaisuja tähän tehtävään, vaan käytti myös käyttöönottoa esimerkkinä nähdäkseen, kuinka ne toimivat. Se osoittautui erittäin informatiiviseksi aiheesta kiinnostuneille.

TL; DR: Tässä artikkelissa verrataan kuutta staattista työkalua Kubernetes YAML -tiedostojen validoimiseksi ja arvioimiseksi parhaiden käytäntöjen ja vaatimusten perusteella.

Kubernetes-työkuormat määritellään tyypillisesti YAML-dokumenttien muodossa. Yksi YAML:n ongelmista on vaikeus määritellä luettelotiedostojen välisiä rajoituksia tai suhteita.

Entä jos meidän on varmistettava, että kaikki klusteriin asennetut kuvat tulevat luotetusta rekisteristä?

Kuinka voin estää käyttöönottojen, joissa ei ole PodDisruptionBudgetteja, lähettämisen klusteriin?

Staattisen testauksen integroinnin avulla voit tunnistaa virheet ja käytäntörikkomukset kehitysvaiheessa. Tämä lisää takuuta siitä, että resurssimääritykset ovat oikein ja turvallisia, ja tekee todennäköisemmin, että tuotannon työmäärät noudattavat parhaita käytäntöjä.

Kubernetes-staattinen YAML-tiedostotarkastusekosysteemi voidaan jakaa seuraaviin luokkiin:

API-validaattorit. Tämän luokan työkalut tarkistavat YAML-luettelon Kubernetes API -palvelimen vaatimusten mukaisesti.
Valmiit testaajat. Tämän kategorian työkaluissa on valmiit testit turvallisuudesta, parhaiden käytäntöjen noudattamisesta jne.
Mukautetut validaattorit. Tämän luokan edustajien avulla voit luoda mukautettuja testejä eri kielillä, esimerkiksi Rego ja Javascript.

Tässä artikkelissa kuvaamme ja vertaamme kuutta erilaista työkalua:

kubeval;
kube-pisteet;
config-lint;
kupari;
kilpailu;
polaris.

No, aloitetaan!

Tarkistetaan käyttöönottoja

Ennen kuin aloitamme työkalujen vertailun, luodaan taustaa niiden testaamiseksi.

Alla oleva manifesti sisältää useita virheitä ja parhaiden käytäntöjen noudattamatta jättämistä: kuinka monta niistä löydät?

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)

Käytämme tätä YAML:ää vertaillaksemme erilaisia työkaluja.

Yllä oleva manifesti base-valid.yaml ja muut manifestit tästä artikkelista löytyvät osoitteesta Git arkistot.

Luettelo kuvaa verkkosovellusta, jonka päätehtävänä on vastata "Hello World" -viestillä porttiin 5678. Se voidaan ottaa käyttöön seuraavalla komennolla:

kubectl apply -f hello-world.yaml

Ja niin - tarkista työ:

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

Siirry nyt kohtaan http://localhost:8080 ja vahvista, että sovellus toimii. Mutta noudattaako se parhaita käytäntöjä? Tarkistetaan.

1. Kubeval

Ytimessä kubeval Ajatuksena on, että kaikki vuorovaikutus Kubernetesin kanssa tapahtuu sen REST API:n kautta. Toisin sanoen voit tarkistaa API-skeeman avulla, onko tietty YAML sen mukainen. Katsotaanpa esimerkkiä.

Asennusohjeet kubeval ovat saatavilla hankkeen verkkosivuilla.

Alkuperäistä artikkelia kirjoitettaessa versio 0.15.0 oli saatavilla.

Kun se on asennettu, syötetään se yllä olevaan luetteloon:

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

Jos onnistuu, kubeval poistuu poistumiskoodilla 0. Voit tarkistaa sen seuraavasti:

$ echo $?
0

Kokeillaan nyt kubevalia eri manifestilla:

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)

Löydätkö ongelman silmästä? Aloitetaan:

$ 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

Resurssia ei tarkisteta.

Käyttöönotot API-versiolla apps/v1, tulee sisältää valitsin, joka vastaa pod-tunnistetta. Yllä oleva luettelo ei sisällä valitsinta, joten kubeval ilmoitti virheestä ja poistui nollasta poikkeavalla koodilla.

Mietin, mitä tapahtuu, jos teen kubectl apply -f tämän manifestin kanssa?

No kokeillaan:

$ 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

Tämä on juuri se virhe, josta kubeval varoitti. Voit korjata sen lisäämällä valitsimen:

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)

Kubevalin kaltaisten työkalujen etuna on, että tällaiset virheet voidaan havaita käyttöönottosyklin varhaisessa vaiheessa.

Lisäksi nämä tarkistukset eivät vaadi pääsyä klusteriin, vaan ne voidaan suorittaa offline-tilassa.

Oletusarvoisesti kubeval tarkistaa resurssit viimeisimmän Kubernetes API -skeeman mukaan. Useimmissa tapauksissa saatat kuitenkin joutua tarkistamaan tietyn Kubernetes-julkaisun. Tämä voidaan tehdä käyttämällä lippua --kubernetes-version:

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

Huomaa, että versio on määritettävä muodossa Major.Minor.Patch.

Katso luettelo versioista, joissa vahvistusta tuetaan, osoitteesta JSON-skeema GitHubissa, jota kubeval käyttää validointiin. Jos sinun on suoritettava kubeval offline-tilassa, lataa skeemat ja määritä niiden paikallinen sijainti lipulla --schema-location.

Yksittäisten YAML-tiedostojen lisäksi kubeval voi toimia myös hakemistojen ja stdin-tiedostojen kanssa.

Lisäksi Kubeval integroituu helposti CI-putkistoon. Niille, jotka haluavat suorittaa testejä ennen manifestien lähettämistä klusteriin, on ilo tietää, että kubeval tukee kolmea tulostusmuotoa:

Pelkkä teksti;
JSON;
Test Anything Protocol (TAP).

Ja mitä tahansa muotoa voidaan käyttää lähdön jatkojäsentämiseen, jotta voidaan luoda yhteenveto halutun tyyppisistä tuloksista.

Yksi kubevalin haitoista on se, että se ei tällä hetkellä voi tarkistaa mukautettujen resurssien määritelmien (CRD) mukaisuutta. Kubeval on kuitenkin mahdollista määrittää jättää ne huomiotta.

Kubeval on loistava työkalu resurssien tarkistamiseen ja arviointiin; On kuitenkin syytä korostaa, että testin läpäiseminen ei takaa, että resurssi on parhaiden käytäntöjen mukainen.

Esimerkiksi käyttämällä tagia latest säiliössä ei noudata parhaita käytäntöjä. Kubeval ei kuitenkaan pidä tätä virheenä eikä ilmoita siitä. Toisin sanoen tällaisen YAML:n varmennus suoritetaan ilman varoituksia.

Mutta entä jos haluat arvioida YAML:n ja tunnistaa rikkomukset, kuten tunnisteen latest? Kuinka tarkistan YAML-tiedoston parhaiden käytäntöjen suhteen?

2. Kube-pisteet

Kube-pisteet jäsentää YAML-luetteloita ja arvioi niitä sisäänrakennetuilla testeillä. Nämä testit valitaan turvallisuusohjeiden ja parhaiden käytäntöjen perusteella, kuten:

Säilöä ei suoriteta pääkäyttäjänä.
Koteloiden terveystarkastusten saatavuus.
Pyyntöjen ja rajoitusten asettaminen resursseille.

Testitulosten perusteella annetaan kolme tulosta: OK, VAROITUS и KRIITTINEN.

Voit kokeilla Kube-scorea verkossa tai asentaa sen paikallisesti.

Alkuperäistä artikkelia kirjoitettaessa kube-scoren uusin versio oli 1.7.0.

Kokeillaan sitä manifestissamme 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 läpäisee kubeval-testit, kun taas kube-score viittaa seuraaviin puutteisiin:

Valmiustarkastuksia ei ole määritetty.
CPU-resursseille ja muistille ei ole pyyntöjä tai rajoituksia.
Pod-häiriöbudjetteja ei ole määritetty.
Eroamissääntöjä ei ole (antiaffiniteetti) saatavuuden maksimoimiseksi.
Säiliö toimii pääkäyttäjänä.

Nämä ovat kaikki päteviä seikkoja puutteista, jotka on korjattava, jotta käyttöönotosta voidaan tehdä tehokkaampi ja luotettavampi.

Joukkue kube-score näyttää tiedot ihmisen luettavassa muodossa, mukaan lukien kaikki tyyppirikkomukset VAROITUS и KRIITTINEN, mikä auttaa paljon kehityksen aikana.

Ne, jotka haluavat käyttää tätä työkalua CI-liukuhihnassa, voivat ottaa käyttöön pakatun tulosteen lipun avulla --output-format ci (tässä tapauksessa näytetään myös testit tuloksella 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

Kuten kubeval, kube-score palauttaa nollasta poikkeavan koodin, kun testi epäonnistuu KRIITTINEN. Voit myös ottaa käyttöön samanlaisen käsittelyn VAROITUS.

Lisäksi on mahdollista tarkistaa resurssien yhteensopivuus eri API-versioiden kanssa (kuten kubevalissa). Nämä tiedot on kuitenkin koodattu itse kube-scoressa: et voi valita toista Kubernetes-versiota. Tämä rajoitus voi olla suuri ongelma, jos aiot päivittää klusterin tai jos sinulla on useita klustereita eri K8s-versioilla.

Huomaa, että on jo ongelma ehdotuksen kanssa tämän mahdollisuuden toteuttamiseksi.

Lisätietoja kube-scoresta löytyy osoitteesta virallisilla verkkosivuilla.

Kube-score-testit ovat loistava työkalu parhaiden käytäntöjen toteuttamiseen, mutta entä jos sinun on tehtävä muutoksia testiin tai lisättävä omia sääntöjä? Valitettavasti tätä ei voi tehdä.

Kube-score ei ole laajennettavissa: siihen ei voi lisätä käytäntöjä tai muokata niitä.

Jos sinun on kirjoitettava mukautettuja testejä yrityksen käytäntöjen noudattamisen varmistamiseksi, voit käyttää yhtä seuraavista neljästä työkalusta: config-lint, copper, conftest tai polaris.

3. Config-lint

Config-lint on työkalu YAML-, JSON-, Terraform-, CSV-määritystiedostojen ja Kubernetes-luetteloiden validointiin.

Voit asentaa sen käyttämällä ohjeet hankkeen verkkosivuilla.

Nykyinen julkaisu alkuperäisen artikkelin kirjoittamishetkellä on 1.5.0.

Config-lintissä ei ole sisäänrakennettuja testejä Kubernetes-luetteloiden vahvistamiseksi.

Testien suorittamiseksi sinun on luotava asianmukaiset säännöt. Ne on kirjoitettu YAML-tiedostoihin, joita kutsutaan "säännöstöiksi" (säännöt), ja niillä on seuraava rakenne:

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

(rule.yaml)

Tutkitaanpa tarkemmin:

Kenttä type määrittää, minkä tyyppistä kokoonpanoa config-lint käyttää. K8:n kohdalla tämä on aina Kubernetes.
Kentällä files Itse tiedostojen lisäksi voit määrittää hakemiston.
Kenttä rules tarkoitettu käyttäjätestien asettamiseen.

Oletetaan, että haluat varmistaa, että käyttöönoton kuvat ladataan aina luotettavasta arkistosta, kuten my-company.com/myapp:1.0. Config-lint-sääntö, joka suorittaa tällaisen tarkistuksen, näyttäisi tältä:

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

Jokaisella säännöllä on oltava seuraavat attribuutit:

id — säännön yksilöllinen tunniste;
severity - Voi olla VIKA, VAROITUS и NON_COMPLIANT;
message — jos sääntöä rikotaan, tämän rivin sisältö näytetään;
resource — resurssityyppi, johon tätä sääntöä sovelletaan;
assertions — luettelo ehdoista, jotka arvioidaan suhteessa tähän resurssiin.

Yllä olevassa säännössä assertion oikeutettu every tarkistaa, että kaikki säilöt ovat käyttöönotossa (key: spec.templates.spec.containers) käytä luotettavia kuvia (eli alkaen my-company.com/).

Täydellinen sääntösarja näyttää tältä:

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)

Kokeile testiä tallentamalla se nimellä check_image_repo.yaml. Suoritetaan tiedoston tarkistus 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"
  }
]

Tarkistus epäonnistui. Tarkastellaan nyt seuraavaa manifestia oikealla kuvavarastolla:

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)

Suoritamme saman testin yllä olevan luettelon kanssa. Ei ongelmia löytynyt:

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

Config-lint on lupaava kehys, jonka avulla voit luoda omia testejäsi Kubernetes YAML-luetteloiden vahvistamiseksi YAML DSL:n avulla.

Mutta entä jos tarvitset monimutkaisempaa logiikkaa ja testejä? Eikö YAML ole liian rajoitettu tähän? Mitä jos voisit luoda testejä täydellä ohjelmointikielellä?

4. Kupari

Kupari V2 on kehys luetteloiden validoimiseksi mukautetuilla testeillä (samanlainen kuin config-lint).

Se eroaa kuitenkin jälkimmäisestä siinä, että se ei käytä YAML:ia testien kuvaamiseen. Testit voidaan kirjoittaa JavaScriptillä sen sijaan. Copper tarjoaa kirjaston, jossa on useita perustyökaluja, joiden avulla voit lukea tietoja Kubernetes-objekteista ja raportoida virheistä.

Copperin asennuksen vaiheet löytyvät kohdasta virallinen dokumentaatio.

2.0.1 on tämän apuohjelman viimeisin versio alkuperäistä artikkelia kirjoitettaessa.

Kuten config-lintissä, Copperissa ei ole sisäänrakennettuja testejä. Kirjoitetaan yksi. Anna sen tarkistaa, että käyttöönotot käyttävät säilökuvia yksinomaan luotetuista tietovarastoista, kuten my-company.com.

Luo tiedosto check_image_repo.js seuraavalla sisällöllä:

$$.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)
            }
        });
    }
});

Nyt testataan manifestiamme base-valid.yaml, käytä komentoa 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 selvää, että kuparin avulla voit suorittaa monimutkaisempia testejä - esimerkiksi tarkistaa verkkotunnusten nimet Ingress-luetteloissa tai hylätä etuoikeutetussa tilassa käynnissä olevia podeja.

Kupariin on sisäänrakennettu useita hyödyllisiä toimintoja:

DockerImage lukee määritetyn syöttötiedoston ja luo objektin, jolla on seuraavat attribuutit:
- name - kuvan nimi,
- tag - kuvatunniste,
- registry - kuvarekisteri,
- registry_url - protokolla (https://) ja kuvarekisteri,
- fqin — kuvan täydellinen sijainti.
Toiminto findByName auttaa löytämään resurssin tietyn tyypin mukaan (kind) ja nimi (name) syöttötiedostosta.
Toiminto findByLabels auttaa löytämään resurssin tietyn tyypin mukaan (kind) ja tarrat (labels).

Voit tarkastella kaikkia saatavilla olevia palvelutoimintoja täällä.

Oletuksena se lataa koko syötetyn YAML-tiedoston muuttujaan $$ ja antaa sen saataville komentosarjoille (tuttu tekniikka niille, joilla on kokemusta jQuerysta).

Copperin tärkein etu on ilmeinen: sinun ei tarvitse hallita erikoiskieltä ja voit käyttää erilaisia JavaScript-ominaisuuksia omien testien luomiseen, kuten merkkijonointerpolaatiota, funktioita jne.

On myös huomattava, että Copperin nykyinen versio toimii JavaScript-moottorin ES5-version kanssa, ei ES6:n kanssa.

Tiedot saatavilla osoitteessa hankkeen virallinen verkkosivusto.

Jos et kuitenkaan pidä JavaScriptistä ja pidät kielistä, jotka on suunniteltu erityisesti kyselyjen luomiseen ja käytäntöjen kuvaamiseen, sinun tulee kiinnittää huomiota conftestiin.

5. Kilpailu

Conftest on kehys konfiguraatiotietojen testaamiseen. Soveltuu myös Kubernetes-luetteloiden testaamiseen/varmentamiseen. Testit kuvataan erityisellä kyselykielellä Rego.

Voit asentaa conftestin käyttämällä ohjeetlistattu hankkeen verkkosivuilla.

Alkuperäistä artikkelia kirjoitettaessa viimeisin saatavilla oleva versio oli 0.18.2.

Config-lintin ja kuparin tapaan conftest tulee ilman sisäänrakennettuja testejä. Kokeillaan sitä ja kirjoitetaan oma politiikkamme. Kuten aiemmissa esimerkeissä, tarkistamme, ovatko säilön kuvat otettu luotettavasta lähteestä.

Luo hakemisto conftest-checks, ja siinä on tiedosto nimeltä check_image_registry.rego seuraavalla sisällöllä:

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

Nyt testataan base-valid.yaml kautta 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 epäonnistui ennustettavasti, koska kuvat olivat peräisin epäluotetusta lähteestä.

Rego-tiedostossa määritämme lohkon deny. Sen totuutta pidetään rikkomuksena. Jos estää deny useita, conftest tarkistaa ne toisistaan riippumatta, ja minkä tahansa lohkon totuus käsitellään rikkomuksena.

Oletustulosteen lisäksi conftest tukee JSON-, TAP- ja taulukkomuotoa - erittäin hyödyllinen ominaisuus, jos haluat upottaa raportteja olemassa olevaan CI-liukuhihnaan. Voit asettaa haluamasi muodon lipun avulla --output.

Käytäntöjen virheenkorjauksen helpottamiseksi conftestillä on lippu --trace. Se tulostaa jäljen siitä, kuinka conftest jäsentää määritetyt käytäntötiedostot.

Kilpailukäytännöt voidaan julkaista ja jakaa OCI (Open Container Initiative) -rekistereissä artefakteina.

komennot push и pull Voit julkaista artefaktin tai noutaa olemassa olevan artefaktin etärekisteristä. Yritetään julkaista luomamme käytäntö paikalliseen Docker-rekisteriin käyttämällä conftest push.

Käynnistä paikallinen Docker-rekisteri:

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

Siirry toisessa terminaalissa aiemmin luomaasi hakemistoon conftest-checks ja suorita seuraava komento:

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

Jos komento onnistui, näet seuraavanlaisen viestin:

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

Luo nyt väliaikainen hakemisto ja suorita siinä oleva komento conftest pull. Se lataa edellisen komennon luoman paketin:

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

Väliaikaiseen hakemistoon tulee alihakemisto policysisältää käytäntötiedostomme:

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

Testit voidaan suorittaa suoraan arkistosta:

$ 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

Valitettavasti DockerHubia ei vielä tueta. Joten pidä itseäsi onnekkaana, jos käytät Azure Container Registry (ACR) tai omassa rekisterissäsi.

Artefaktin muoto on sama kuin Avaa Policy Agent -paketit (OPA), jonka avulla voit käyttää conftestiä testien suorittamiseen olemassa olevista OPA-paketeista.

Saat lisätietoja käytäntöjen jakamisesta ja muista conftestin ominaisuuksista osoitteessa hankkeen virallinen verkkosivusto.

6. Polaris

Viimeinen työkalu, josta tässä artikkelissa keskustellaan, on Polaris. (Hänen viime vuoden ilmoituksensa me jo käännetty - noin käännös)

Polaris voidaan asentaa klusteriin tai käyttää komentorivitilassa. Kuten olet ehkä arvannut, sen avulla voit analysoida staattisesti Kubernetes-luetteloita.

Kun ajetaan komentorivitilassa, käytettävissä on sisäänrakennettuja testejä, jotka kattavat muun muassa turvallisuuden ja parhaat käytännöt (samanlaiset kuin kube-score). Lisäksi voit luoda omia testejä (kuten config-lint, copper ja conftest).

Toisin sanoen Polaris yhdistää molempien työkalukategorioiden edut: sisäänrakennetuilla ja mukautetuilla testeillä.

Asenna Polaris komentorivitilassa käyttämällä ohjeet hankkeen verkkosivuilla.

Alkuperäistä artikkelia kirjoitettaessa versio 1.0.3 on saatavilla.

Kun asennus on valmis, voit suorittaa polariksen luettelossa base-valid.yaml seuraavalla komennolla:

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

Se tulostaa JSON-muotoisen merkkijonon, jossa on yksityiskohtainen kuvaus suoritetuista testeistä ja niiden tuloksista. Tuloksen rakenne on seuraava:

{
  "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": [
    /* длинный список */
  ]
}

Täysi tuotanto käytettävissä täällä.

Kuten kube-score, Polaris tunnistaa ongelmat alueilla, joilla luettelo ei täytä parhaita käytäntöjä:

Paloilla ei ole terveystarkastuksia.
Säilön kuvien tunnisteita ei ole määritetty.
Säiliö toimii pääkäyttäjänä.
Muistin ja suorittimen pyyntöjä ja rajoituksia ei ole määritetty.

Jokaiselle testille määritetään sen tuloksista riippuen kriittisyysaste: varoitus tai vaara. Lisätietoja käytettävissä olevista sisäänrakennetuista testeistä on osoitteessa dokumentointi.

Jos tietoja ei tarvita, voit määrittää lipun --format score. Tässä tapauksessa Polaris tulostaa luvun välillä 1 - 100 − pisteet (eli arviointi):

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

Mitä lähempänä pistemäärä on 100, sitä korkeampi on yksimielisyys. Jos tarkistat komennon poistumiskoodin polaris audit, käy ilmi, että se on yhtä suuri kuin 0.

make polaris audit Voit lopettaa työn nollasta poikkeavalla koodilla käyttämällä kahta lippua:

lippu --set-exit-code-below-score ottaa argumentiksi kynnysarvon välillä 1-100. Tässä tapauksessa komento poistuu poistumiskoodilla 4, jos pistemäärä on alle kynnyksen. Tämä on erittäin hyödyllistä, kun sinulla on tietty kynnysarvo (esim. 75) ja sinun on saatava hälytys, jos tulos laskee.
lippu --set-exit-code-on-danger aiheuttaa komennon epäonnistumisen koodilla 3, jos jokin vaaratesteistä epäonnistuu.

Yritetään nyt luoda mukautettu testi, joka tarkistaa, onko kuva otettu luotettavasta arkistosta. Mukautetut testit on määritetty YAML-muodossa, ja itse testi on kuvattu JSON-skeemalla.

Seuraava YAML-koodinpätkä kuvaa uutta testiä nimeltä 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/.+$

Katsotaanpa sitä tarkemmin:

successMessage — tämä rivi tulostetaan, jos testi on suoritettu onnistuneesti;
failureMessage — tämä viesti näytetään virheen sattuessa;
category — osoittaa yhden luokista: Images, Health Checks, Security, Networking и Resources;
target--- määrittää minkä tyyppisen objektin (spec) -testiä käytetään. Mahdolliset arvot: Container, Pod tai Controller;
Itse testi on määritelty objektissa schema käyttämällä JSON-skeemaa. Avainsana tässä testissä on pattern käytetään vertaamaan kuvalähdettä vaadittuun lähteeseen.

Suorittaaksesi yllä olevan testin, sinun on luotava seuraava Polaris-kokoonpano:

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)

Jäsennetään tiedosto:

Kentällä checks testit ja niiden kriittisyysaste määrätään. Koska on toivottavaa saada varoitus, kun kuva on otettu epäluotettavasta lähteestä, asetamme tason tähän danger.
Itse testi checkImageRepo sitten rekisteröity objektiin customChecks.

Tallenna tiedosto nimellä custom_check.yaml. Nyt voit juosta polaris audit YAML-luettelolla, joka vaatii vahvistuksen.

Testataan manifestiamme base-valid.yaml:

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

Joukkue polaris audit suoritti vain yllä määritellyn käyttäjätestin ja se epäonnistui.

Jos korjaat kuvan my-company.com/http-echo:1.0, Polaris poistuu onnistuneesti. Manifesti muutoksineen on jo mukana arkistotjoten voit tarkistaa luettelon edellisen komennon image-valid-mycompany.yaml.

Nyt herää kysymys: kuinka suorittaa sisäänrakennettuja testejä yhdessä mukautettujen kanssa? Helposti! Sinun tarvitsee vain lisätä sisäänrakennetut testitunnisteet määritystiedostoon. Tämän seurauksena se on seuraavassa muodossa:

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)

Saatavilla on esimerkki täydellisestä asetustiedostosta täällä.

Tarkista luettelo base-valid.yamlkäyttämällä sisäänrakennettuja ja mukautettuja testejä, voit käyttää komentoa:

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

Polaris täydentää sisäänrakennettuja testejä mukautetuilla testeillä, mikä yhdistää molempien maailmojen parhaat puolet.

Toisaalta kyvyttömyys käyttää tehokkaampia kieliä, kuten Rego tai JavaScript, voi olla rajoittava tekijä, joka estää kehittyneempien testien luomisen.

Lisätietoja Polarisista on saatavilla osoitteessa projektisivusto.

Yhteenveto

Vaikka saatavilla on monia työkaluja Kubernetes YAML -tiedostojen tarkastamiseen ja arvioimiseen, on tärkeää saada selkeä käsitys siitä, miten testit suunnitellaan ja suoritetaan.

Esimerkiksi jos otat Kubernetes-luetteloita putkilinjan läpi, kubeval voisi olla ensimmäinen askel sellaisessa putkilinjassa. Se valvoisi, ovatko objektimääritykset Kubernetes API -skeeman mukaisia.

Kun tällainen tarkastelu on valmis, voidaan siirtyä kehittyneempiin testeihin, kuten standardien parhaiden käytäntöjen ja erityisten käytäntöjen noudattamiseen. Tässä kube-score ja Polaris olisivat hyödyllisiä.

Niille, joilla on monimutkaisia vaatimuksia ja jotka haluavat mukauttaa testejä yksityiskohtaisesti, kupari, config-lint ja conftest sopivat.

Conftest ja config-lint käyttävät YAML:a mukautettujen testien määrittämiseen, ja kupari antaa sinulle pääsyn täydelliseen ohjelmointikieleen, mikä tekee siitä melko houkuttelevan valinnan.

Toisaalta kannattaako käyttää jotakin näistä työkaluista ja siksi luoda kaikki testit manuaalisesti vai mieluummin Polaris ja lisätä siihen vain tarvittava? Tähän kysymykseen ei ole selvää vastausta.

Alla olevassa taulukossa on lyhyt kuvaus jokaisesta työkalusta:

Työkalu
kohtalo
Rajoitukset
Käyttäjätestit

kubeval
Vahvistaa YAML-luettelot tiettyä API-skeeman versiota vastaan
Ei toimi CRD:n kanssa
Ei

kube-pisteet
Analysoi YAML:n manifesteja parhaita käytäntöjä vastaan
Kubernetes API -versiota ei voi valita resurssien tarkistamista varten
Ei

kupari-
Yleinen kehys mukautettujen JavaScript-testien luomiseen YAML-luetteloille
Ei sisäänrakennettuja testejä. Huono dokumentaatio
Kyllä

config-lint
Yleinen kehys testien luomiseen YAML:ään upotettuun toimialuekohtaiseen kieleen. Tukee erilaisia konfigurointimuotoja (esim. Terraform)
Valmiita testejä ei ole. Sisäänrakennetut väitteet ja toiminnot eivät välttämättä riitä
Kyllä

kilpailu
Kehys omien testien luomiseen Regolla (erityinen kyselykieli). Mahdollistaa käytäntöjen jakamisen OCI-pakettien kautta
Ei sisäänrakennettuja testejä. Minun on opittava Rego. Docker Hubia ei tueta käytäntöjä julkaistaessa
Kyllä

Polaris
Arvostelee YAML-luetteloita tavallisten parhaiden käytäntöjen vastaisesti. Voit luoda omia testejäsi JSON-skeeman avulla
JSON-skeemaan perustuvat testausominaisuudet eivät välttämättä riitä
Kyllä

Koska nämä työkalut eivät ole riippuvaisia Kubernetes-klusterin pääsystä, ne on helppo asentaa. Niiden avulla voit suodattaa lähdetiedostoja ja antaa nopeaa palautetta projektien vetopyyntöjen tekijöille.

PS kääntäjältä

Lue myös blogistamme:

Lähde: will.com

Vahvista Kubernetes YAML parhaiden käytäntöjen ja käytäntöjen suhteen