Preverite Kubernetes YAML glede na najboljše prakse in politike

Opomba. prevod: Z naraščajočim številom konfiguracij YAML za okolja K8s postaja potreba po njihovem avtomatiziranem preverjanju vedno bolj nujna. Avtor tega pregleda ni le izbral obstoječih rešitev za to nalogo, ampak je tudi pogledal, kako delujejo, na primeru uvajanja. Izkazalo se je zelo informativno za tiste, ki jih ta tema zanima.

TL; DR: Ta članek primerja šest statičnih orodij za preverjanje in vrednotenje datotek Kubernetes YAML glede na najboljše prakse in zahteve.

Delovne obremenitve Kubernetes so običajno definirane v obliki dokumentov YAML. Ena od težav z YAML je težava pri določanju omejitev ali odnosov med datotekami manifesta.

Kaj pa, če moramo zagotoviti, da vse slike, nameščene v gručo, izvirajo iz zaupanja vrednega registra?

Kako lahko preprečim, da bi se razmestitve, ki nimajo PodDisruptionBudgets, poslale v gručo?

Integracija statičnega testiranja vam omogoča prepoznavanje napak in kršitev pravilnika v fazi razvoja. To poveča jamstvo, da so definicije virov pravilne in varne, in poveča verjetnost, da bodo proizvodne delovne obremenitve sledile najboljšim praksam.

Ekosistem pregledovanja statičnih datotek Kubernetes YAML lahko razdelimo v naslednje kategorije:

• API validatorji. Orodja v tej kategoriji preverjajo manifest YAML glede na zahteve strežnika Kubernetes API.
• Pripravljeni testerji. Orodja iz te kategorije imajo že pripravljene teste za varnost, skladnost z najboljšimi praksami itd.
• Validatorji po meri. Predstavniki te kategorije vam omogočajo ustvarjanje testov po meri v različnih jezikih, na primer Rego in Javascript.

V tem članku bomo opisali in primerjali šest različnih orodij:

1. kubeval;
2. rezultat kube;
3. config-lint;
4. baker;
5. tekmovanje;
6. polaris.

No, pa začnimo!

Preverjanje razmestitev

Preden začnemo primerjati orodja, ustvarimo ozadje, na katerem jih bomo preizkusili.

Spodnji manifest vsebuje številne napake in neupoštevanje najboljših praks: koliko jih lahko najdete?

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)

Ta YAML bomo uporabili za primerjavo različnih orodij.

Zgornji manifest base-valid.yaml in druge manifeste iz tega članka lahko najdete v Git repozitoriji.

Manifest opisuje spletno aplikacijo, katere glavna naloga je odgovoriti s sporočilom »Hello World« na vrata 5678. Razmestiti jo je mogoče z naslednjim ukazom:

kubectl apply -f hello-world.yaml

In tako - preverite delo:

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

Zdaj pa pojdi na http://localhost:8080 in potrdite, da aplikacija deluje. Toda ali sledi najboljšim praksam? Preverimo.

1. Kubeval

V središču kubeval Ideja je, da vsaka interakcija s Kubernetesom poteka prek njegovega API-ja REST. Z drugimi besedami, lahko uporabite shemo API, da preverite, ali je dani YAML skladen z njo. Poglejmo si primer.

navodila za namestitev kubeval so na voljo na spletni strani projekta.

V času pisanja izvirnega članka je bila na voljo različica 0.15.0.

Ko je nameščen, ga napolnimo z zgornjim manifestom:

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

Če bo uspešen, bo kubeval zapustil z izhodno kodo 0. To lahko preverite na naslednji način:

$ echo $?
0

Zdaj pa poskusimo kubeval z drugačnim manifestom:

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)

Ali lahko opazite težavo na oko? Zaženimo:

$ 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

Vir se ne preverja.

Razmestitve z uporabo različice API-ja apps/v1, mora vsebovati izbirnik, ki se ujema z oznako sklopa. Zgornji manifest ne vključuje izbirnika, zato je kubeval prijavil napako in zapustil kodo, ki ni ničelna.

Sprašujem se, kaj se bo zgodilo, če to storim kubectl apply -f s tem manifestom?

No, poskusimo:

$ 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

Prav na to napako je opozarjal kubeval. To lahko popravite tako, da dodate izbirnik:

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)

Prednost orodij, kot je kubeval, je, da je takšne napake mogoče odkriti zgodaj v ciklu uvajanja.

Poleg tega ta preverjanja ne zahtevajo dostopa do gruče; lahko jih izvedete brez povezave.

Kubeval privzeto preverja vire glede na najnovejšo shemo Kubernetes API. Vendar pa boste v večini primerov morda morali preveriti glede na določeno izdajo Kubernetes. To je mogoče storiti z uporabo zastavice --kubernetes-version:

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

Upoštevajte, da mora biti različica navedena v formatu Major.Minor.Patch.

Za seznam različic, za katere je podprto preverjanje, glejte Shema JSON na GitHubu, ki ga kubeval uporablja za validacijo. Če morate zagnati kubeval brez povezave, prenesite sheme in z zastavico določite njihovo lokalno lokacijo --schema-location.

Poleg posameznih datotek YAML lahko kubeval deluje tudi z imeniki in stdin.

Poleg tega se Kubeval enostavno integrira v CI cevovod. Tisti, ki želijo izvesti preizkuse, preden pošljejo manifeste v gručo, bodo veseli, da kubeval podpira tri izhodne formate:

1. Golo besedilo;
2. JSON;
3. Test Anything Protocol (TAP).

Kateri koli format se lahko uporabi za nadaljnje razčlenjevanje izhoda, da se ustvari povzetek rezultatov želene vrste.

Ena od pomanjkljivosti kubevala je, da trenutno ne more preveriti skladnosti z definicijami virov po meri (CRD). Vendar pa je mogoče konfigurirati kubeval ignoriraj jih.

Kubeval je odlično orodje za preverjanje in ocenjevanje virov; Vendar je treba poudariti, da opravljen preizkus ne zagotavlja, da je vir v skladu z najboljšimi praksami.

Na primer z uporabo oznake latest v zabojniku ne sledi najboljšim praksam. Vendar kubeval tega ne smatra za napako in je ne poroča. To pomeni, da se bo preverjanje takega YAML končalo brez opozoril.

Kaj pa, če želite oceniti YAML in prepoznati kršitve, kot je oznaka latest? Kako preverim datoteko YAML glede na najboljše prakse?

2. Kube-score

Kube rezultat razčleni manifeste YAML in jih ovrednoti glede na vgrajene teste. Ti testi so izbrani na podlagi varnostnih smernic in najboljših praks, kot so:

• Zagon vsebnika ne kot root.
• Razpoložljivost zdravstvenih pregledov strokov.
• Nastavitev zahtev in omejitev za vire.

Na podlagi rezultatov testa so podani trije rezultati: OK, OPOZORILO и KRITIČNO.

Kube-score lahko preizkusite na spletu ali pa ga namestite lokalno.

V času pisanja izvirnega članka je bila zadnja različica kube-score 1.7.0.

Preizkusimo to na našem manifestu 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 opravi teste kubeval, medtem ko kube-score opozarja na naslednje pomanjkljivosti:

• Preverjanja pripravljenosti niso konfigurirana.
• Za vire procesorja in pomnilnik ni nobenih zahtev ali omejitev.
• Proračuni motenj pod niso določeni.
• Ni pravil ločevanja (proti afiniteti) za čim večjo razpoložljivost.
• Vsebnik deluje kot root.

Vse to so veljavne točke o pomanjkljivostih, ki jih je treba odpraviti, da bo uvajanje učinkovitejše in zanesljivejše.

Ekipa kube-score prikaže informacije v človeku berljivi obliki, vključno z vsemi kršitvami vrste OPOZORILO и KRITIČNO, ki zelo pomaga pri razvoju.

Tisti, ki želijo uporabljati to orodje v cevovodu CI, lahko omogočijo bolj stisnjen izhod z uporabo zastavice --output-format ci (v tem primeru se izpišejo tudi testi z rezultatom 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

Podobno kot kubeval, kube-score vrne izhodno kodo, ki ni ničelna, ko je test neuspešen KRITIČNO. Podobno obdelavo lahko omogočite tudi za OPOZORILO.

Poleg tega je mogoče preveriti skladnost virov z različnimi različicami API (kot v kubevalu). Vendar so te informacije trdo kodirane v samem rezultatu kube: ne morete izbrati druge različice Kubernetesa. Ta omejitev je lahko velik problem, če nameravate nadgraditi svojo gručo ali če imate več gruč z različnimi različicami K8s.

Prosimo, upoštevajte, da se že obstaja vprašanje s predlogom za realizacijo te priložnosti.

Več informacij o kube-score lahko najdete na uradna spletna stran.

Testi Kube-score so odlično orodje za izvajanje najboljših praks, a kaj, če morate test spremeniti ali dodati svoja pravila? Žal, tega ni mogoče storiti.

Kube-score ni razširljiv: ne morete mu dodati politik ali jih prilagoditi.

Če morate napisati teste po meri za preverjanje skladnosti s politikami podjetja, lahko uporabite eno od naslednjih štirih orodij: config-lint, copper, conftest ali polaris.

3.Config-lint

Config-lint je orodje za preverjanje konfiguracijskih datotek YAML, JSON, Terraform, CSV in manifestov Kubernetes.

Namestite ga lahko z uporabo navodila na spletni strani projekta.

Trenutna izdaja v času pisanja izvirnega članka je 1.5.0.

Config-lint nima vgrajenih testov za preverjanje manifestov Kubernetes.

Za izvedbo kakršnih koli testov morate ustvariti ustrezna pravila. Zapisani so v datotekah YAML, imenovanih "nabori pravil" (nabori pravil)in imajo naslednjo strukturo:

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

(rule.yaml)

Preučimo ga podrobneje:

• Polje type določa, katero vrsto konfiguracije bo uporabil config-lint. Za manifeste K8s je to vedno Kubernetes.
• Na področju files Poleg samih datotek lahko določite imenik.
• Polje rules namenjen nastavitvi uporabniških testov.

Recimo, da se želite prepričati, da so slike v razdelku Deployment vedno prenesene iz zaupanja vrednega repozitorija, kot je my-company.com/myapp:1.0. Pravilo config-lint, ki izvede takšno preverjanje, bi bilo videti takole:

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

Vsako pravilo mora imeti naslednje atribute:

• id — enolični identifikator pravila;
• severity - Mogoče NAPAKA, OPOZORILO и NI SKLADEN;
• message — če je pravilo kršeno, se prikaže vsebina te vrstice;
• resource — vrsto vira, za katerega velja to pravilo;
• assertions — seznam pogojev, ki bodo ovrednoteni v zvezi s tem virom.

V zgornjem pravilu assertion z naslovom every preveri, ali so vsi vsebniki v razmestitvi (key: spec.templates.spec.containers) uporabite zaupanja vredne slike (tj. začenši z my-company.com/).

Celoten nabor pravil izgleda takole:

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)

Če želite preizkusiti test, ga shranimo kot check_image_repo.yaml. Preverimo datoteko 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"
  }
]

Preverjanje ni uspelo. Zdaj pa si oglejmo naslednji manifest s pravilnim repozitorijem slik:

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)

Enak test izvedemo z zgornjim manifestom. Ni najdenih težav:

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

Config-lint je obetavno ogrodje, ki vam omogoča ustvarjanje lastnih testov za preverjanje manifestov Kubernetes YAML z uporabo YAML DSL.

Kaj pa, če potrebujete bolj zapleteno logiko in teste? Ali ni YAML preveč omejen za to? Kaj pa, če bi lahko ustvarili teste v polnem programskem jeziku?

4. Baker

Baker V2 je ogrodje za preverjanje manifestov z uporabo preizkusov po meri (podobno kot config-lint).

Vendar se od slednjega razlikuje po tem, da za opis testov ne uporablja YAML. Namesto tega lahko teste napišete v JavaScriptu. Copper ponuja knjižnico z več osnovnimi orodji, ki vam pomagajo brati informacije o objektih Kubernetes in poročati o napakah.

Korake za namestitev Copper najdete v uradna dokumentacija.

2.0.1 je zadnja izdaja tega pripomočka v času pisanja izvirnega članka.

Tako kot config-lint tudi Copper nima vgrajenih testov. Napišimo enega. Naj preveri, ali uvedbe uporabljajo slike vsebnikov izključno iz zaupanja vrednih skladišč, kot je my-company.com.

Ustvarite datoteko check_image_repo.js z naslednjo vsebino:

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

Zdaj pa preizkusimo naš manifest base-valid.yaml, uporabite ukaz 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

Jasno je, da lahko s pomočjo bakra izvajate bolj zapletene teste - na primer preverjanje imen domen v manifestih Ingress ali zavračanje podov, ki se izvajajo v privilegiranem načinu.

Baker ima vgrajene različne uporabne funkcije:

• DockerImage prebere navedeno vhodno datoteko in ustvari objekt z naslednjimi atributi:
  • name - ime slike,
  • tag - slikovna oznaka,
  • registry - register slik,
  • registry_url - protokol (https://) in register slik,
  • fqin — polna lokacija slike.
• Funkcija findByName pomaga najti vir po dani vrsti (kind) in ime (name) iz vhodne datoteke.
• Funkcija findByLabels pomaga najti vir po določeni vrsti (kind) in nalepke (labels).

Ogledate si lahko vse razpoložljive storitvene funkcije tukaj.

Privzeto naloži celotno vhodno datoteko YAML v spremenljivko $$ in ga naredi na voljo za skriptiranje (znana tehnika za tiste z izkušnjami z jQuery).

Glavna prednost Copperja je očitna: ni vam treba obvladati specializiranega jezika in lahko uporabite različne funkcije JavaScript za ustvarjanje lastnih testov, kot so interpolacija nizov, funkcije itd.

Prav tako je treba opozoriti, da trenutna različica Copper deluje z različico ES5 motorja JavaScript, ne ES6.

Podrobnosti so na voljo na uradna spletna stran projekta.

Vendar, če vam JavaScript res ni všeč in imate raje jezik, posebej zasnovan za ustvarjanje poizvedb in opisovanje politik, bodite pozorni na confest.

5.Tekmovanje

Conftest je ogrodje za testiranje konfiguracijskih podatkov. Primerno tudi za testiranje/preverjanje manifestov Kubernetes. Testi so opisani z uporabo specializiranega poizvedovalnega jezika Rego.

Conftest lahko namestite z uporabo navodilanavedene na spletni strani projekta.

V času pisanja izvirnega članka je bila zadnja razpoložljiva različica 0.18.2.

Podobno kot config-lint in copper je tudi conftest brez vgrajenih testov. Preizkusimo in napišimo svojo politiko. Kot v prejšnjih primerih bomo preverili, ali so slike vsebnika vzete iz zanesljivega vira.

Ustvarite imenik conftest-checks, v njej pa je datoteka z imenom check_image_registry.rego z naslednjo vsebino:

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

Zdaj pa preizkusimo base-valid.yaml prek 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

Preizkus predvidljivo ni uspel, ker so slike prišle iz nezaupljivega vira.

V datoteki Rego definiramo blok deny. Njegova resnica se šteje za kršitev. Če bloki deny več, conftest jih preverja neodvisno drug od drugega, resničnost katerega koli od blokov pa se obravnava kot kršitev.

Poleg privzetega izhoda conftest podpira JSON, TAP in obliko tabele – izjemno uporabna funkcija, če morate vdelati poročila v obstoječ CI cevovod. Z zastavico lahko nastavite želeno obliko --output.

Za lažje odpravljanje napak v pravilnikih ima confest zastavico --trace. Izpiše sled, kako conftest razčleni podane datoteke pravilnika.

Politike natečajev je mogoče objaviti in deliti v registrih OCI (Open Container Initiative) kot artefakte.

Ekipe push и pull omogočajo objavo artefakta ali pridobivanje obstoječega artefakta iz oddaljenega registra. Poskusimo objaviti pravilnik, ki smo ga ustvarili, v lokalnem registru Docker z uporabo conftest push.

Zaženite lokalni register Docker:

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

V drugem terminalu pojdite v imenik, ki ste ga ustvarili prej conftest-checks in zaženite naslednji ukaz:

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

Če je bil ukaz uspešen, boste videli takšno sporočilo:

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

Zdaj ustvarite začasni imenik in v njem zaženite ukaz conftest pull. Prenesel bo paket, ustvarjen s prejšnjim ukazom:

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

V začasnem imeniku se bo pojavil podimenik policyki vsebuje našo politično datoteko:

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

Teste je mogoče izvajati neposredno iz repozitorija:

$ 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

Na žalost DockerHub še ni podprt. Zato se imejte za srečnega, če ga uporabljate Register vsebnikov Azure (ACR) ali svoj register.

Format artefakta je enak kot Odprite pakete Policy Agent (OPA), ki vam omogoča uporabo conftest za izvajanje testov iz obstoječih paketov OPA.

Več o skupni rabi pravilnikov in drugih funkcijah confest lahko izveste na uradna spletna stran projekta.

6. Polaris

Zadnje orodje, o katerem bomo razpravljali v tem članku, je Polaris. (Njegova lanska napoved smo že prevedeno - pribl. prevod)

Polaris je mogoče namestiti v gručo ali uporabiti v načinu ukazne vrstice. Kot ste morda uganili, vam omogoča statično analizo manifestov Kubernetes.

Pri izvajanju v načinu ukazne vrstice so na voljo vgrajeni testi, ki pokrivajo področja, kot so varnost in najboljše prakse (podobno kube-score). Poleg tega lahko ustvarite lastne teste (kot v config-lint, copper in conftest).

Z drugimi besedami, Polaris združuje prednosti obeh kategorij orodij: z vgrajenimi testi in testi po meri.

Če želite namestiti Polaris v načinu ukazne vrstice, uporabite navodila na spletni strani projekta.

V času pisanja izvirnega članka je na voljo različica 1.0.3.

Ko je namestitev končana, lahko polaris zaženete na manifestu base-valid.yaml z naslednjim ukazom:

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

Izpisal bo niz v formatu JSON s podrobnim opisom izvedenih testov in njihovih rezultatov. Izhod bo imel naslednjo strukturo:

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

Na voljo je celoten izhod tukaj.

Tako kot kube-score tudi Polaris identificira težave na področjih, kjer manifest ne ustreza najboljšim praksam:

• Za stroke ni zdravstvenih pregledov.
• Oznake za slike vsebnika niso določene.
• Vsebnik deluje kot root.
• Zahteve in omejitve za pomnilnik in procesor niso določene.

Vsakemu testu je glede na njegove rezultate dodeljena stopnja kritičnosti: opozorilo ali nevarnost. Če želite izvedeti več o razpoložljivih vgrajenih testih, glejte dokumentacijo.

Če podrobnosti niso potrebne, lahko določite zastavico --format score. V tem primeru bo Polaris izdal število v razponu od 1 do 100 − rezultat (tj. ocena):

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

Bližje kot je rezultat 100, večja je stopnja strinjanja. Če preverite izhodno kodo ukaza polaris audit, se izkaže, da je enako 0.

Sila polaris audit Delo z neničelno kodo lahko prekinete z uporabo dveh zastavic:

• Zastava --set-exit-code-below-score kot argument vzame vrednost praga v območju 1-100. V tem primeru se ukaz zaključi z izhodno kodo 4, če je rezultat pod pragom. To je zelo uporabno, ko imate določeno mejno vrednost (recimo 75) in morate prejeti opozorilo, če rezultat pade pod.
• Zastava --set-exit-code-on-danger povzroči neuspeh ukaza s kodo 3, če eden od preizkusov nevarnosti ne uspe.

Zdaj pa poskusimo ustvariti preizkus po meri, ki preveri, ali je slika vzeta iz zaupanja vrednega skladišča. Testi po meri so podani v formatu YAML, sam test pa je opisan s shemo JSON.

Naslednji delček kode YAML opisuje nov test, imenovan 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/.+$

Oglejmo si ga pobližje:

• successMessage — ta vrstica bo natisnjena, če se preizkus uspešno zaključi;
• failureMessage — to sporočilo bo prikazano v primeru napake;
• category — označuje eno od kategorij: Images, Health Checks, Security, Networking и Resources;
• target--- določa vrsto predmeta (spec) se uporabi preskus. Možne vrednosti: Container, Pod ali Controller;
• Sam test je določen v predmetu schema z uporabo sheme JSON. Ključna beseda v tem testu je pattern se uporablja za primerjavo vira slike z zahtevanim.

Če želite izvesti zgornji preizkus, morate ustvariti naslednjo konfiguracijo Polaris:

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)

Razčlenimo datoteko:

• Na področju checks predpisani so testi in njihova stopnja kritičnosti. Ker je zaželeno, da prejmete opozorilo, ko je slika posneta iz nezaupljivega vira, tukaj nastavimo raven danger.
• Sam test checkImageRepo nato registriran v objektu customChecks.

Shranite datoteko kot custom_check.yaml. Zdaj lahko tečeš polaris audit z manifestom YAML, ki zahteva preverjanje.

Preizkusimo naš manifest base-valid.yaml:

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

Ekipa polaris audit zagnal samo zgoraj navedeni uporabniški test, ki pa ni uspel.

Če popravite sliko na my-company.com/http-echo:1.0, se bo Polaris uspešno zaključil. Manifest s spremembami je že notri repozitorijetako da lahko preverite prejšnji ukaz v manifestu image-valid-mycompany.yaml.

Zdaj se postavlja vprašanje: kako zagnati vgrajene teste skupaj s tistimi po meri? Enostavno! V konfiguracijsko datoteko morate samo dodati vgrajene testne identifikatorje. Posledično bo imela naslednjo obliko:

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)

Na voljo je primer celotne konfiguracijske datoteke tukaj.

Preverite manifest base-valid.yamlz uporabo vgrajenih testov in testov po meri lahko uporabite ukaz:

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

Polaris dopolnjuje vgrajene teste s testi po meri in tako združuje najboljše iz obeh svetov.

Po drugi strani pa je lahko nezmožnost uporabe zmogljivejših jezikov, kot sta Rego ali JavaScript, omejevalni dejavnik, ki preprečuje ustvarjanje bolj sofisticiranih testov.

Več informacij o Polarisu je na voljo na stran projekta.

Povzetek

Čeprav je na voljo veliko orodij za pregledovanje in ocenjevanje datotek Kubernetes YAML, pomembno je jasno razumeti, kako bodo testi zasnovani in izvedeni.

Na primer, če vzamete manifeste Kubernetes, ki gredo skozi cevovod, bi lahko bil kubeval prvi korak v takem cevovodu. Spremljal bi, ali so definicije objektov v skladu s shemo Kubernetes API.

Ko je takšen pregled končan, lahko preidete na bolj izpopolnjene teste, kot je skladnost s standardnimi najboljšimi praksami in posebnimi politikami. Tukaj bi kube-score in Polaris prišla prav.

Za tiste, ki imajo zapletene zahteve in morajo podrobno prilagoditi teste, bi bili primerni copper, config-lint in conftest.

Conftest in config-lint uporabljata YAML za definiranje testov po meri, copper pa vam omogoča dostop do celotnega programskega jezika, zaradi česar je precej privlačna izbira.

Po drugi strani, ali se splača uporabiti eno od teh orodij in zato ročno ustvariti vse teste ali raje izbrati Polaris in mu dodati le tisto, kar je potrebno? Na to vprašanje ni jasnega odgovora.

V spodnji tabeli je kratek opis vsakega orodja:

Orodje
Namen
Omejitve
Uporabniški testi

kubeval
Preveri manifeste YAML glede na določeno različico sheme API
Ne more delovati s CRD
Št

rezultat kube
Analizira manifeste YAML glede na najboljše prakse
Ni mogoče izbrati vaše različice Kubernetes API za preverjanje virov
Št

baker
Splošni okvir za ustvarjanje preizkusov JavaScript po meri za manifeste YAML
Ni vgrajenih testov. Slaba dokumentacija
Da

config-lint
Splošni okvir za ustvarjanje testov v domensko specifičnem jeziku, vdelanem v YAML. Podpira različne formate konfiguracije (npr. Terraform)
Pripravljenih testov ni. Vgrajene trditve in funkcije morda ne bodo dovolj
Da

tekmovanje
Ogrodje za ustvarjanje lastnih testov z uporabo Rego (specializiranega poizvedovalnega jezika). Omogoča skupno rabo pravilnikov prek svežnjev OCI
Ni vgrajenih testov. Moram se naučiti Rego. Docker Hub ni podprt pri objavljanju pravilnikov
Da

Polaris
Pregleduje manifeste YAML glede na standardne najboljše prakse. Omogoča ustvarjanje lastnih testov z uporabo sheme JSON
Preizkusne zmogljivosti, ki temeljijo na shemi JSON, morda ne bodo zadostovale
Da

Ker ta orodja niso odvisna od dostopa do gruče Kubernetes, jih je enostavno namestiti. Omogočajo filtriranje izvornih datotek in zagotavljajo hitre povratne informacije avtorjem zahtev za vleko v projektih.

PS od prevajalca

Preberite tudi na našem blogu:

• «Polaris je bil uveden za ohranjanje zdravih gruč Kubernetes»;
• «Vim s podporo YAML za Kubernetes»;
• «7 najboljših praks za uporabo vsebnikov glede na Google".

Vir: www.habr.com