Provjerite Kubernetes YAML prema najboljim praksama i pravilima

Bilješka. prev.: Uz sve veći broj YAML konfiguracija za K8s okruženja, potreba za njihovom automatiziranom provjerom postaje sve hitnija. Autor ove recenzije nije samo odabrao postojeća rješenja za ovaj zadatak, već je upotrijebio i Deployment kao primjer da vidi kako funkcioniraju. Pokazalo se vrlo informativnim za one koje ova tema zanima.

TL; DR: Ovaj članak uspoređuje šest statičkih alata za provjeru valjanosti i procjenu Kubernetes YAML datoteka u odnosu na najbolju praksu i zahtjeve.

Radna opterećenja Kubernetesa obično su definirana u obliku YAML dokumenata. Jedan od problema s YAML-om je teškoća određivanja ograničenja ili odnosa između datoteka manifesta.

Što ako trebamo osigurati da sve slike raspoređene u klaster dolaze iz pouzdanog registra?

Kako mogu spriječiti slanje implementacija koje nemaju PodDisruptionBudgets u klaster?

Integracija statičkog testiranja omogućuje vam prepoznavanje pogrešaka i kršenja pravila u fazi razvoja. To povećava jamstvo da su definicije resursa ispravne i sigurne te povećava vjerojatnost da će proizvodna radna opterećenja slijediti najbolje prakse.

Ekosustav Kubernetes statičke inspekcije YAML datoteka može se podijeliti u sljedeće kategorije:

• API validatori. Alati u ovoj kategoriji provjeravaju YAML manifest prema zahtjevima Kubernetes API poslužitelja.
• Spremni testeri. Alati iz ove kategorije dolaze s gotovim testovima za sigurnost, usklađenost s najboljim praksama itd.
• Prilagođeni validatori. Predstavnici ove kategorije omogućuju vam stvaranje prilagođenih testova na različitim jezicima, na primjer, Rego i Javascript.

U ovom ćemo članku opisati i usporediti šest različitih alata:

1. kubeval;
2. kube-rezultat;
3. config-lint;
4. bakar;
5. confest;
6. polaris.

Pa, počnimo!

Provjera implementacija

Prije nego počnemo uspoređivati ​​alate, stvorimo pozadinu na kojoj ćemo ih testirati.

Manifest u nastavku sadrži brojne pogreške i nepoštivanje najboljih praksi: koliko ih možete pronaći?

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)

Koristit ćemo ovaj YAML za usporedbu različitih alata.

Gornji manifest base-valid.yaml i druge manifeste iz ovog članka možete pronaći u Git spremišta.

Manifest opisuje web aplikaciju čiji je glavni zadatak odgovoriti porukom "Hello World" na port 5678. Može se implementirati sljedećom naredbom:

kubectl apply -f hello-world.yaml

I tako - provjerite rad:

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

Sada idite na http://localhost:8080 i potvrdite da aplikacija radi. Ali slijedi li najbolju praksu? Provjerimo.

1. Kubeval

U srcu kubeval Ideja je da se svaka interakcija s Kubernetesom odvija kroz njegov REST API. Drugim riječima, možete koristiti API shemu da provjerite je li dati YAML u skladu s njom. Pogledajmo primjer.

Upute za instalaciju kubeval dostupni su na web stranici projekta.

U vrijeme pisanja izvornog članka bila je dostupna verzija 0.15.0.

Nakon instalacije, dodajmo mu gornji manifest:

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

Ako bude uspješan, kubeval će izaći s izlaznim kodom 0. To možete provjeriti na sljedeći način:

$ echo $?
0

Pokušajmo sada kubeval s drugim 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)

Možete li okom uočiti problem? Pokrenimo:

$ 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

Izvor se ne provjerava.

Implementacije pomoću API verzije apps/v1, mora sadržavati selektor koji odgovara oznaci bloka. Gornji manifest ne uključuje selektor, pa je kubeval prijavio pogrešku i izašao s kodom koji nije nula.

Pitam se što će se dogoditi ako to učinim kubectl apply -f s ovim manifestom?

Pa, pokušajmo:

$ 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

Upravo je to greška na koju je upozoravao kubeval. To možete popraviti dodavanjem selektora:

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 alata kao što je kubeval je u tome što se greške poput ovih mogu uočiti rano u ciklusu implementacije.

Osim toga, ove provjere ne zahtijevaju pristup klasteru; mogu se izvršiti izvan mreže.

Prema zadanim postavkama kubeval provjerava resurse prema najnovijoj Kubernetes API shemi. Međutim, u većini slučajeva možda ćete morati provjeriti određeno izdanje Kubernetesa. To se može učiniti pomoću zastavice --kubernetes-version:

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

Imajte na umu da verzija mora biti navedena u formatu Major.Minor.Patch.

Za popis verzija za koje je podržana provjera, pogledajte JSON shema na GitHubu, koji kubeval koristi za provjeru valjanosti. Ako trebate pokrenuti kubeval izvan mreže, preuzmite sheme i navedite njihovu lokalnu lokaciju pomoću oznake --schema-location.

Osim pojedinačnih YAML datoteka, kubeval također može raditi s direktorijima i stdin-om.

Osim toga, Kubeval se lako integrira u CI cjevovod. Oni koji žele pokrenuti testove prije slanja manifesta u klaster bit će sretni da znaju da kubeval podržava tri izlazna formata:

1. Običan tekst;
2. JSON;
3. Protokol Test Anything (TAP).

A bilo koji od formata može se koristiti za daljnje analiziranje izlaza za generiranje sažetka rezultata željene vrste.

Jedan od nedostataka kubevala je taj što trenutačno ne može provjeriti usklađenost s prilagođenim definicijama resursa (CRD). Međutim, moguće je konfigurirati kubeval ignoriraj ih.

Kubeval je izvrstan alat za provjeru i procjenu resursa; Međutim, treba naglasiti da prolazak testa ne jamči da je resurs u skladu s najboljom praksom.

Na primjer, pomoću oznake latest u spremniku ne slijedi najbolju praksu. Međutim, kubeval to ne smatra pogreškom i ne prijavljuje je. Odnosno, provjera takvog YAML-a završit će bez upozorenja.

Ali što ako želite procijeniti YAML i identificirati kršenja poput oznake latest? Kako mogu provjeriti YAML datoteku u odnosu na najbolju praksu?

2. Kube-rezultat

Kube-rezultat analizira YAML manifeste i procjenjuje ih u odnosu na ugrađene testove. Ovi testovi odabrani su na temelju sigurnosnih smjernica i najboljih praksi, kao što su:

• Pokretanje spremnika ne kao root.
• Dostupnost zdravstvenih provjera mahuna.
• Postavljanje zahtjeva i ograničenja za resurse.

Na temelju rezultata ispitivanja data su tri rezultata: OK, UPOZORENJE и KRITIČNO.

Kube-score možete isprobati online ili ga instalirati lokalno.

U vrijeme pisanja izvornog članka, najnovija verzija kube-score bila je 1.7.0.

Isprobajmo 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 prolazi kubeval testove, dok kube-score ukazuje na sljedeće nedostatke:

• Provjere spremnosti nisu konfigurirane.
• Ne postoje zahtjevi niti ograničenja za CPU resurse i memoriju.
• Proračuni za ometanje kapsula nisu navedeni.
• Nema pravila odvajanja (anti-afinitet) kako bi se povećala dostupnost.
• Spremnik radi kao root.

Sve su to valjane točke o nedostacima koje je potrebno riješiti kako bi implementacija bila učinkovitija i pouzdanija.

Momčad kube-score prikazuje informacije u obliku čitljivom za čovjeka, uključujući sva kršenja tipa UPOZORENJE и KRITIČNO, što puno pomaže tijekom razvoja.

Oni koji žele koristiti ovaj alat unutar CI cjevovoda mogu omogućiti komprimiraniji izlaz pomoću oznake --output-format ci (u ovom slučaju se prikazuju i testovi s 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

Slično kubevalu, kube-score vraća izlazni kod različit od nule kada postoji test koji ne uspije KRITIČNO. Također možete omogućiti sličnu obradu za UPOZORENJE.

Osim toga, moguće je provjeriti usklađenost resursa s različitim verzijama API-ja (kao u kubevalu). Međutim, ove su informacije tvrdo kodirane u samom kube rezultatu: ne možete odabrati drugu verziju Kubernetesa. Ovo ograničenje može biti veliki problem ako namjeravate nadograditi svoj klaster ili ako imate više klastera s različitim verzijama K8s.

Imajte na umu da već postoji problem s prijedlogom za realizaciju ove mogućnosti.

Više informacija o kube-scoreu možete pronaći na službene web stranice.

Kube-score testovi izvrstan su alat za implementaciju najboljih praksi, ali što ako morate unijeti izmjene u test ili dodati vlastita pravila? Nažalost, to se ne može učiniti.

Kube-score nije proširiv: ne možete mu dodati pravila niti ih prilagoditi.

Ako trebate napisati prilagođene testove za provjeru usklađenosti s pravilima tvrtke, možete koristiti jedan od sljedeća četiri alata: config-lint, copper, conftest ili polaris.

3.Config-lint

Config-lint je alat za provjeru YAML, JSON, Terraform, CSV konfiguracijskih datoteka i Kubernetes manifesta.

Možete ga instalirati pomoću upute na web stranici projekta.

Trenutno izdanje u vrijeme pisanja izvornog članka je 1.5.0.

Config-lint nema ugrađene testove za provjeru Kubernetes manifesta.

Da biste proveli bilo kakve testove, morate stvoriti odgovarajuća pravila. Zapisani su u YAML datotekama koje se nazivaju "setovi pravila" (set pravila), i imaju sljedeću strukturu:

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

(rule.yaml)

Proučimo to pobliže:

• Polje type specificira koju će vrstu konfiguracije config-lint koristiti. Za manifeste K8s ovo je uvijek Kubernetes.
• U polju files Osim samih datoteka, možete odrediti i direktorij.
• Polje rules namijenjen za postavljanje korisničkih testova.

Recimo da želite biti sigurni da se slike u Deploymentu uvijek preuzimaju iz pouzdanog repozitorija kao što je my-company.com/myapp:1.0. Config-lint pravilo koje izvodi takvu provjeru izgledalo bi ovako:

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

Svako pravilo mora imati sljedeće atribute:

• id — jedinstveni identifikator pravila;
• severity - može biti NEUSPJEH, UPOZORENJE и NEUSKLADNO;
• message — ako je pravilo prekršeno, prikazuje se sadržaj ovog retka;
• resource — vrstu izvora na koji se ovo pravilo primjenjuje;
• assertions — popis uvjeta koji će se ocjenjivati ​​u odnosu na ovaj resurs.

U gornjem pravilu assertion pravo every provjerava jesu li svi spremnici u rasporedu (key: spec.templates.spec.containers) koristite pouzdane slike (tj. počevši od my-company.com/).

Kompletan skup pravila izgleda ovako:

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)

Da bismo isprobali test, spremimo ga kao check_image_repo.yaml. Provjerimo datoteku 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"
  }
]

Provjera nije uspjela. Sada provjerimo sljedeći manifest s ispravnim spremištem slika:

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)

Izvodimo isti test s gornjim manifestom. Nema pronađenih problema:

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

Config-lint je obećavajući okvir koji vam omogućuje stvaranje vlastitih testova za provjeru Kubernetes YAML manifesta pomoću YAML DSL-a.

Ali što ako trebate složeniju logiku i testove? Nije li YAML previše ograničen za ovo? Što ako biste mogli izraditi testove u potpunom programskom jeziku?

4. Bakar

Bakar V2 je okvir za provjeru valjanosti manifesta pomoću prilagođenih testova (slično config-lintu).

Međutim, razlikuje se od potonjeg po tome što ne koristi YAML za opisivanje testova. Testovi se umjesto toga mogu pisati u JavaScriptu. Copper nudi biblioteku s nekoliko osnovnih alata, koji vam pomažu čitati informacije o Kubernetes objektima i prijavljivati ​​pogreške.

Koraci za instaliranje Coppera mogu se pronaći u službena dokumentacija.

2.0.1 je najnovije izdanje ovog uslužnog programa u vrijeme pisanja izvornog članka.

Kao i config-lint, Copper nema ugrađene testove. Napišimo jednu. Neka provjeri koriste li implementacije slike spremnika isključivo iz pouzdanih repozitorija kao što su my-company.com.

Stvorite datoteku check_image_repo.js sa sljedećim sadržajem:

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

Sada da testiramo naš manifest base-valid.yaml, koristite naredbu 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 uz pomoć bakra možete izvoditi složenije testove - na primjer, provjeravati nazive domena u Ingressovim manifestima ili odbijati podove koji se izvode u privilegiranom načinu rada.

Bakar ima različite uporabne funkcije ugrađene u njega:

• DockerImage čita navedenu ulaznu datoteku i stvara objekt sa sljedećim atributima:
  • name - naziv slike,
  • tag - oznaka slike,
  • registry - registar slika,
  • registry_url - protokol (https://) i registar slika,
  • fqin — puni položaj slike.
• Funkcija findByName pomaže u pronalaženju izvora prema danoj vrsti (kind) i ime (name) iz ulazne datoteke.
• Funkcija findByLabels pomaže pronaći resurs prema određenoj vrsti (kind) i oznake (labels).

Možete vidjeti sve dostupne servisne funkcije здесь.

Prema zadanim postavkama učitava cijelu ulaznu YAML datoteku u varijablu $$ i čini ga dostupnim za skriptiranje (poznata tehnika za one s jQuery iskustvom).

Glavna prednost Coppera je očigledna: ne morate svladati specijalizirani jezik i možete koristiti različite značajke JavaScripta za izradu vlastitih testova, poput interpolacije nizova, funkcija itd.

Također treba napomenuti da trenutna verzija Coppera radi s ES5 verzijom JavaScript motora, a ne ES6.

Pojedinosti dostupne na službenoj web stranici projekta.

Međutim, ako baš ne volite JavaScript i preferirate jezik posebno dizajniran za kreiranje upita i opisivanje pravila, trebali biste obratiti pozornost na confest.

5.Natjecanje

Conftest je okvir za testiranje konfiguracijskih podataka. Prikladno i za testiranje/provjeru Kubernetes manifesta. Testovi su opisani pomoću specijaliziranog upitnog jezika Rego.

Conftest možete instalirati pomoću uputenavedeni na web stranici projekta.

U vrijeme pisanja izvornog članka, posljednja dostupna verzija bila je 0.18.2.

Slično config-lint i copper, conftest dolazi bez ikakvih ugrađenih testova. Isprobajmo to i napišimo vlastitu politiku. Kao i u prethodnim primjerima, provjerit ćemo jesu li slike spremnika preuzete iz pouzdanog izvora.

Napravite imenik conftest-checks, au njemu se nalazi datoteka pod nazivom check_image_registry.rego sa sljedećim sadržajem:

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

Sada idemo testirati base-valid.yaml kroz 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 je očekivano pao jer su slike došle iz nepouzdanog izvora.

U Rego datoteci definiramo blok deny. Njegova se istina smatra kršenjem. Ako blokovi deny nekoliko, conftest ih provjerava neovisno jedan o drugom, a istinitost bilo kojeg od blokova tretira se kao kršenje.

Uz zadani izlaz, conftest podržava JSON, TAP i format tablice - izuzetno korisna značajka ako trebate ugraditi izvješća u postojeći CI cjevovod. Pomoću zastavice možete postaviti željeni format --output.

Kako bi se olakšalo ispravljanje pogrešaka u pravilima, confest ima oznaku --trace. Ispisuje trag kako conftest analizira navedene datoteke pravila.

Pravila natjecanja mogu se objaviti i dijeliti u registrima OCI (Open Container Initiative) kao artefakti.

naredbe push и pull omogućuju vam da objavite artefakt ili dohvatite postojeći artefakt iz udaljenog registra. Pokušajmo objaviti pravilo koje smo stvorili u lokalnom Docker registru pomoću conftest push.

Pokrenite svoj lokalni Docker registar:

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

U drugom terminalu idite na direktorij koji ste prethodno stvorili conftest-checks i pokrenite sljedeću naredbu:

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

Ako je naredba bila uspješna, vidjet ćete poruku poput ove:

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

Sada stvorite privremeni direktorij i pokrenite naredbu u njemu conftest pull. Preuzet će paket kreiran prethodnom naredbom:

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

Poddirektorij će se pojaviti u privremenom direktoriju policykoji sadrži našu datoteku pravila:

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

Testovi se mogu pokrenuti izravno 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 još nije podržan. Stoga se smatrajte sretnim ako ga koristite Registar Azure spremnika (ACR) ili vlastiti registar.

Format artefakta je isti kao Otvorite pakete agenta politike (OPA), koji vam omogućuje korištenje conftesta za izvođenje testova iz postojećih OPA paketa.

Možete saznati više o dijeljenju pravila i drugim značajkama conftesta na službenoj web stranici projekta.

6. Polaris

Posljednji alat o kojem će biti riječi u ovom članku je Polaris. (Njegova prošlogodišnja najava mi već prevedeno - cca. prijevod)

Polaris se može instalirati u klaster ili koristiti u načinu naredbenog retka. Kao što ste možda pogodili, omogućuje vam statičku analizu Kubernetes manifesta.

Kada se izvodi u načinu naredbenog retka, dostupni su ugrađeni testovi koji pokrivaju područja kao što su sigurnost i najbolja praksa (slično kube-score). Osim toga, možete kreirati vlastite testove (kao u config-lint, copper i conftest).

Drugim riječima, Polaris kombinira prednosti obiju kategorija alata: s ugrađenim i prilagođenim testovima.

Da biste instalirali Polaris u načinu naredbenog retka, koristite upute na web stranici projekta.

U vrijeme pisanja izvornog članka, dostupna je verzija 1.0.3.

Nakon dovršetka instalacije možete pokrenuti polaris na manifestu base-valid.yaml sa sljedećom naredbom:

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

Ispis će dati niz u JSON formatu s detaljnim opisom provedenih testova i njihovim rezultatima. Izlaz će imati sljedeću strukturu:

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

Puni izlaz dostupan здесь.

Kao i kube-score, Polaris identificira probleme u područjima gdje manifest ne zadovoljava najbolje prakse:

• Ne postoje zdravstveni pregledi mahuna.
• Oznake za slike spremnika nisu navedene.
• Spremnik radi kao root.
• Zahtjevi i ograničenja za memoriju i CPU nisu navedeni.

Svakom testu, ovisno o njegovim rezultatima, dodjeljuje se stupanj kritičnosti: upozorenje ili opasnost. Da biste saznali više o dostupnim ugrađenim testovima, pogledajte dokumentacija.

Ako detalji nisu potrebni, možete navesti oznaku --format score. U ovom slučaju, Polaris će ispisati broj u rasponu od 1 do 100 − postići (tj. procjena):

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

Što je rezultat bliži 100, to je veći stupanj slaganja. Ako provjerite izlazni kod naredbe polaris audit, ispada da je jednak 0.

Sila polaris audit Možete prekinuti rad s kodom koji nije nula koristeći dvije zastavice:

• zastava --set-exit-code-below-score uzima kao argument vrijednost praga u rasponu 1-100. U ovom slučaju, naredba će izaći s izlaznim kodom 4 ako je rezultat ispod praga. Ovo je vrlo korisno kada imate određenu graničnu vrijednost (recimo 75) i trebate primiti upozorenje ako rezultat padne ispod.
• zastava --set-exit-code-on-danger uzrokovat će neuspjeh naredbe s kodom 3 ako jedan od testova opasnosti ne uspije.

Pokušajmo sada stvoriti prilagođeni test koji provjerava je li slika preuzeta iz pouzdanog repozitorija. Prilagođeni testovi navedeni su u YAML formatu, a sam test opisan je pomoću JSON sheme.

Sljedeći YAML isječak koda opisuje novi test pod nazivom 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/.+$

Pogledajmo ga pobliže:

• successMessage — ovaj će se redak ispisati ako se test uspješno završi;
• failureMessage — ova će se poruka prikazati u slučaju kvara;
• category — označava jednu od kategorija: Images, Health Checks, Security, Networking и Resources;
• target--- određuje koju vrstu objekta (spec) primjenjuje se test. Moguće vrijednosti: Container, Pod ili Controller;
• Sam test je naveden u objektu schema pomoću JSON sheme. Ključna riječ u ovom testu je pattern koristi se za usporedbu izvora slike s traženim.

Za izvođenje gornjeg testa morate izraditi sljedeću Polaris konfiguraciju:

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)

Analizirajmo datoteku:

• U polju checks propisani su testovi i njihov stupanj kritičnosti. Budući da je poželjno primiti upozorenje kada je slika preuzeta iz nepouzdanog izvora, ovdje postavljamo razinu danger.
• Sam test checkImageRepo zatim upisana u objekt customChecks.

Spremi datoteku kao custom_check.yaml. Sada možete trčati polaris audit s YAML manifestom koji zahtijeva provjeru.

Testirajmo naš manifest base-valid.yaml:

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

Momčad polaris audit pokrenuo je samo gore navedeni korisnički test i nije uspio.

Ako popravite sliku na my-company.com/http-echo:1.0, Polaris će uspješno završiti. Manifest s promjenama je već tu spremištatako da možete provjeriti prethodnu naredbu na manifestu image-valid-mycompany.yaml.

Sada se postavlja pitanje: kako pokrenuti ugrađene testove zajedno s prilagođenim? Lako! Samo trebate dodati ugrađene identifikatore testa u konfiguracijsku datoteku. Kao rezultat toga, poprimit će sljedeći oblik:

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)

Dostupan je primjer potpune konfiguracijske datoteke здесь.

Provjerite manifest base-valid.yamlkoristeći ugrađene i prilagođene testove, možete koristiti naredbu:

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

Polaris nadopunjuje ugrađene testove s prilagođenim, kombinirajući tako najbolje od oba svijeta.

S druge strane, nemogućnost korištenja moćnijih jezika kao što su Rego ili JavaScript može biti ograničavajući faktor koji sprječava stvaranje sofisticiranijih testova.

Više informacija o Polarisu dostupno je na web mjesto projekta.

Rezime

Iako postoji mnogo dostupnih alata za pregled i procjenu Kubernetes YAML datoteka, važno je jasno razumjeti kako će testovi biti dizajnirani i izvedeni.

Na primjer, ako uzmete Kubernetesove manifeste koji prolaze kroz cjevovod, kubeval bi mogao biti prvi korak u takvom cjevovodu. Nadzirao bi jesu li definicije objekata u skladu s Kubernetes API shemom.

Nakon što se takav pregled dovrši, može se prijeći na sofisticiranije testove, kao što je usklađenost sa standardnim najboljim praksama i posebnim politikama. Tu bi nam kube-score i Polaris dobro došli.

Za one koji imaju složene zahtjeve i trebaju detaljno prilagoditi testove, prikladni bi bili copper, config-lint i conftest.

Conftest i config-lint koriste YAML za definiranje prilagođenih testova, a copper vam daje pristup potpunom programskom jeziku, što ga čini prilično atraktivnim izborom.

S druge strane, isplati li se koristiti jedan od ovih alata i stoga ručno izraditi sve testove ili preferirati Polaris i dodati mu samo ono što je potrebno? Ne postoji jasan odgovor na ovo pitanje.

Donja tablica daje kratak opis svakog alata:

Oruđe
sudbina
Ograničenja
Korisnički testovi

kubeval
Provjerava YAML manifeste u odnosu na određenu verziju API sheme
Ne može raditi s CRD-om
Ne

kube-rezultat
Analizira YAML manifeste u odnosu na najbolju praksu
Ne mogu odabrati vašu verziju Kubernetes API-ja za provjeru resursa
Ne

bakar
Opći okvir za stvaranje prilagođenih JavaScript testova za YAML manifeste
Nema ugrađenih testova. Loša dokumentacija
Da

config-lint
Opći okvir za izradu testova u jeziku specifičnom za domenu ugrađenom u YAML. Podržava različite konfiguracijske formate (npr. Terraform)
Nema gotovih testova. Ugrađene tvrdnje i funkcije možda neće biti dovoljne
Da

natjecanje
Okvir za izradu vlastitih testova koristeći Rego (specijalizirani upitni jezik). Omogućuje dijeljenje pravila putem OCI paketa
Nema ugrađenih testova. Moram naučiti Rego. Docker Hub nije podržan prilikom objavljivanja pravila
Da

Polaris
Recenzira YAML manifeste u odnosu na standardne najbolje prakse. Omogućuje vam izradu vlastitih testova pomoću JSON sheme
Mogućnosti testiranja temeljene na JSON shemi možda neće biti dovoljne
Da

Budući da se ovi alati ne oslanjaju na pristup Kubernetes klasteru, lako ih je instalirati. Omogućuju filtriranje izvornih datoteka i pružaju brzu povratnu informaciju autorima zahtjeva za povlačenje u projektima.

PS od prevoditelja

Pročitajte i na našem blogu:

• «Polaris predstavljen kako bi Kubernetes klasteri bili zdravi»;
• «Vim s YAML podrškom za Kubernetes»;
• «7 najboljih praksi za korištenje spremnika prema Googleu".

Izvor: www.habr.com