Overte Kubernetes YAML podľa osvedčených postupov a zásad

Poznámka. preklad.: S rastúcim počtom konfigurácií YAML pre prostredia K8 je potreba ich automatizovaného overovania čoraz naliehavejšia. Autor tejto recenzie nielen vybral existujúce riešenia pre túto úlohu, ale ako príklad použil aj nasadenie, aby videl, ako fungujú. Ukázalo sa, že je to veľmi poučné pre tých, ktorí sa o túto tému zaujímajú.

TL; DR: Tento článok porovnáva šesť statických nástrojov na overenie a vyhodnotenie súborov Kubernetes YAML v porovnaní s osvedčenými postupmi a požiadavkami.

Pracovné zaťaženia Kubernetes sú zvyčajne definované vo forme dokumentov YAML. Jedným z problémov YAML sú ťažkosti so špecifikovaním obmedzení alebo vzťahov medzi súbormi manifestu.

Čo ak sa potrebujeme uistiť, že všetky obrázky nasadené do klastra pochádzajú z dôveryhodného registra?

Ako môžem zabrániť odoslaniu nasadení, ktoré nemajú PodDisruptionBudgets, do klastra?

Integrácia statického testovania vám umožňuje identifikovať chyby a porušenia pravidiel vo fáze vývoja. Tým sa zvyšuje záruka, že definície zdrojov sú správne a bezpečné, a zvyšuje sa pravdepodobnosť, že produkčné úlohy sa budú riadiť osvedčenými postupmi.

Ekosystém kontroly statických súborov YAML Kubernetes možno rozdeliť do nasledujúcich kategórií:

• API validátory. Nástroje v tejto kategórii kontrolujú manifest YAML v porovnaní s požiadavkami servera Kubernetes API.
• Pripravení testeri. Nástroje z tejto kategórie sa dodávajú s hotovými testami na bezpečnosť, súlad s osvedčenými postupmi atď.
• Vlastné validátory. Zástupcovia tejto kategórie vám umožňujú vytvárať vlastné testy v rôznych jazykoch, napríklad Rego a Javascript.

V tomto článku popíšeme a porovnáme šesť rôznych nástrojov:

1. kubeval;
2. kube-score;
3. config-lint;
4. meď;
5. zápasiť;
6. polaris.

Nuž, začnime!

Kontrola nasadení

Skôr než začneme porovnávať nástroje, vytvorme si pozadie, na ktorom ich otestujeme.

Manifest nižšie obsahuje množstvo chýb a nedodržiavanie osvedčených postupov: koľko z nich môžete nájsť?

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)

Tento YAML použijeme na porovnanie rôznych nástrojov.

Vyššie uvedený manifest base-valid.yaml a ďalšie manifesty z tohto článku nájdete v Repozitáre Git.

Manifest popisuje webovú aplikáciu, ktorej hlavnou úlohou je odpovedať správou „Hello World“ na port 5678. Možno ju nasadiť pomocou nasledujúceho príkazu:

kubectl apply -f hello-world.yaml

A tak - skontrolujte prácu:

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

Teraz choďte na http://localhost:8080 a potvrďte, že aplikácia funguje. Dodržiava však osvedčené postupy? Skontrolujme to.

1. Kubeval

V srdci kubeval Myšlienka je, že akákoľvek interakcia s Kubernetes prebieha prostredníctvom jeho REST API. Inými slovami, pomocou schémy API môžete skontrolovať, či je daný YAML v súlade s ňou. Pozrime sa na príklad.

Návod na inštaláciu kubeval sú dostupné na webovej stránke projektu.

V čase písania pôvodného článku bola dostupná verzia 0.15.0.

Po nainštalovaní ho nakŕmime vyššie uvedeným 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)

Ak bude úspešný, kubeval sa ukončí s kódom ukončenia 0. Môžete to skontrolovať takto:

$ echo $?
0

Skúsme teraz kubeval s iným 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)

Dokážete rozpoznať problém očami? Poďme spustiť:

$ 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

Zdroj sa neoveruje.

Nasadenie pomocou verzie API apps/v1, musí obsahovať selektor, ktorý zodpovedá štítku modulu. Manifest vyššie neobsahuje selektor, takže kubeval nahlásil chybu a skončil s nenulovým kódom.

Zaujímalo by ma, čo sa stane, ak to urobím kubectl apply -f s týmto manifestom?

No, skúsme:

$ 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

Presne na túto chybu upozornil kubeval. Môžete to opraviť pridaním 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)

Výhodou nástrojov, ako je kubeval, je, že takéto chyby je možné zachytiť na začiatku cyklu nasadenia.

Tieto kontroly navyše nevyžadujú prístup do klastra, možno ich vykonávať offline.

V predvolenom nastavení kubeval kontroluje zdroje podľa najnovšej schémy Kubernetes API. Vo väčšine prípadov však možno budete musieť skontrolovať konkrétne vydanie Kubernetes. To sa dá urobiť pomocou vlajky --kubernetes-version:

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

Upozorňujeme, že verzia musí byť uvedená vo formáte Major.Minor.Patch.

Zoznam verzií, pre ktoré je podporované overenie, nájdete na Schéma JSON na GitHub, ktorý kubeval používa na validáciu. Ak potrebujete spustiť kubeval offline, stiahnite si schémy a zadajte ich lokálne umiestnenie pomocou príznaku --schema-location.

Okrem jednotlivých YAML súborov vie kubeval pracovať aj s adresármi a stdin.

Okrem toho sa Kubeval ľahko integruje do potrubia CI. Tých, ktorí chcú spustiť testy pred odoslaním manifestov do klastra, poteší, že kubeval podporuje tri výstupné formáty:

1. Obyčajný text;
2. JSON;
3. Testovať protokol čokoľvek (TAP).

A ktorýkoľvek z formátov je možné použiť na ďalšiu analýzu výstupu na generovanie súhrnu výsledkov požadovaného typu.

Jednou z nevýhod kubevalu je, že v súčasnosti nemôže kontrolovať súlad s definíciami vlastných zdrojov (CRD). Je však možné nakonfigurovať kubeval ignoruj ​​ich.

Kubeval je skvelý nástroj na kontrolu a hodnotenie zdrojov; Treba však zdôrazniť, že absolvovanie testu nezaručuje, že zdroj je v súlade s osvedčenými postupmi.

Napríklad pomocou značky latest v kontajneri nedodržiava osvedčené postupy. To však kubeval nepovažuje za chybu a nehlási. To znamená, že overenie takéhoto YAML sa dokončí bez varovania.

Ale čo ak chcete vyhodnotiť YAML a identifikovať porušenia, ako je značka latest? Ako skontrolujem súbor YAML v porovnaní s osvedčenými postupmi?

2. Kube-skóre

Kube-skóre analyzuje YAML manifesty a vyhodnocuje ich oproti vstavaným testom. Tieto testy sa vyberajú na základe bezpečnostných pokynov a osvedčených postupov, ako napríklad:

• Spustenie kontajnera nie ako root.
• Dostupnosť zdravotných kontrol pod.
• Nastavenie požiadaviek a limitov na zdroje.

Na základe výsledkov testu sú uvedené tri výsledky: OK, VAROVANIE и CRITICAL.

Kube-score môžete vyskúšať online alebo si ho nainštalovať lokálne.

V čase písania pôvodného článku bola najnovšia verzia kube-score 1.7.0.

Skúsme to na našom manifeste 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 prechádza testami kubeval, zatiaľ čo kube-score poukazuje na nasledujúce nedostatky:

• Kontroly pripravenosti nie sú nakonfigurované.
• Neexistujú žiadne požiadavky ani obmedzenia týkajúce sa zdrojov CPU a pamäte.
• Rozpočty prerušenia podu nie sú špecifikované.
• Neexistujú žiadne pravidlá separácie (anti-afinita) maximalizovať dostupnosť.
• Kontajner beží ako root.

Toto všetko sú platné body o nedostatkoch, ktoré je potrebné riešiť, aby bolo nasadenie efektívnejšie a spoľahlivejšie.

Tím kube-score zobrazuje informácie v čitateľnej forme vrátane všetkých typov porušení VAROVANIE и CRITICAL, čo veľmi pomáha pri vývoji.

Tí, ktorí chcú použiť tento nástroj v rámci kanála CI, môžu povoliť viac komprimovaný výstup pomocou príznaku --output-format ci (v tomto prípade sa zobrazia aj testy s výsledkom 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

Podobne ako kubeval, kube-score vracia nenulový výstupný kód, keď sa vyskytne test, ktorý zlyhá CRITICAL. Podobné spracovanie môžete povoliť aj pre VAROVANIE.

Okrem toho je možné kontrolovať súlad zdrojov s rôznymi verziami API (ako v kubeval). Tieto informácie sú však pevne zakódované v samotnom kube-score: nemôžete vybrať inú verziu Kubernetes. Toto obmedzenie môže byť veľkým problémom, ak máte v úmysle upgradovať svoj klaster alebo ak máte viacero klastrov s rôznymi verziami K8.

Vezmite prosím na vedomie, že už je tu problém s návrhom na realizáciu tejto príležitosti.

Viac informácií o kube-score nájdete na oficiálne internetové stránky.

Testy Kube-score sú skvelým nástrojom na implementáciu osvedčených postupov, ale čo ak potrebujete v teste vykonať zmeny alebo pridať vlastné pravidlá? Bohužiaľ, to sa nedá.

Kube-score nie je rozšíriteľné: nemôžete k nemu pridávať politiky ani ich upravovať.

Ak potrebujete napísať vlastné testy na overenie súladu s firemnými politikami, môžete použiť jeden z nasledujúcich štyroch nástrojov: config-lint, medi, conftest alebo polaris.

3.Config-lint

Config-lint je nástroj na overovanie konfiguračných súborov YAML, JSON, Terraform, CSV a manifestov Kubernetes.

Môžete ho nainštalovať pomocou inštrukcie na webovej stránke projektu.

Aktuálne vydanie v čase písania pôvodného článku je 1.5.0.

Config-lint nemá vstavané testy na overenie manifestov Kubernetes.

Ak chcete vykonať akékoľvek testy, musíte vytvoriť príslušné pravidlá. Sú napísané v súboroch YAML nazývaných „sady pravidiel“ (sady pravidiel)a majú nasledujúcu štruktúru:

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

(rule.yaml)

Poďme si to naštudovať bližšie:

• Pole type určuje, aký typ konfigurácie použije config-lint. Pre K8 sa prejavuje toto vždy Kubernetes.
• V poli files Okrem samotných súborov môžete zadať aj adresár.
• Pole rules určené na nastavenie užívateľských testov.

Povedzme, že sa chcete uistiť, že obrázky v Nasadení sa vždy sťahujú z dôveryhodného úložiska, ako je my-company.com/myapp:1.0. Pravidlo config-lint, ktoré vykonáva takúto kontrolu, by vyzeralo takto:

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

Každé pravidlo musí mať nasledujúce atribúty:

• id — jedinečný identifikátor pravidla;
• severity - Možno ZLYHANIE, VAROVANIE и NON_COMPLIANT;
• message — ak dôjde k porušeniu pravidla, zobrazí sa obsah tohto riadku;
• resource — typ zdroja, na ktorý sa toto pravidlo vzťahuje;
• assertions — zoznam podmienok, ktoré sa budú hodnotiť v súvislosti s týmto zdrojom.

Vo vyššie uvedenom pravidle assertion oprávnený every skontroluje, či sú všetky kontajnery v nasadení (key: spec.templates.spec.containers) používať dôveryhodné obrázky (t. j. počnúc my-company.com/).

Kompletná sada pravidiel vyzerá takto:

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)

Ak chcete test vyskúšať, uložte ho ako check_image_repo.yaml. Spustíme kontrolu súboru 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"
  }
]

Kontrola zlyhala. Teraz sa pozrime na nasledujúci manifest so správnym úložiskom obrázkov:

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)

Spustíme rovnaký test s vyššie uvedeným manifestom. Nenašli sa žiadne problémy:

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

Config-lint je sľubný rámec, ktorý vám umožňuje vytvárať vlastné testy na overenie manifestov Kubernetes YAML pomocou YAML DSL.

Ale čo ak potrebujete zložitejšiu logiku a testy? Nie je na to YAML príliš obmedzený? Čo keby ste mohli vytvoriť testy v plnom programovacom jazyku?

4. Meď

Meď V2 je rámec na overovanie manifestov pomocou vlastných testov (podobne ako config-lint).

Od posledného sa však líši tým, že na popis testov nepoužíva YAML. Namiesto toho je možné písať testy v JavaScripte. Meď poskytuje knižnicu s niekoľkými základnými nástrojmi, ktoré vám pomôžu čítať informácie o objektoch Kubernetes a hlásiť chyby.

Kroky na inštaláciu medi nájdete v oficiálna dokumentácia.

2.0.1 je najnovšie vydanie tohto nástroja v čase písania pôvodného článku.

Rovnako ako config-lint, ani Copper nemá vstavané testy. Napíšeme jeden. Nechajte ho skontrolovať, či nasadenia používajú obrázky kontajnerov výlučne z dôveryhodných úložísk, ako napr my-company.com.

Vytvorte súbor check_image_repo.js s nasledujúcim obsahom:

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

Teraz otestujte náš manifest base-valid.yaml, použite príkaz 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

Je jasné, že pomocou medi môžete vykonávať zložitejšie testy – napríklad kontrolu doménových mien v Ingress manifestoch alebo odmietanie podov spustených v privilegovanom režime.

Meď má v sebe zabudované rôzne úžitkové funkcie:

• DockerImage prečíta zadaný vstupný súbor a vytvorí objekt s nasledujúcimi atribútmi:
  • name - názov obrázku,
  • tag - obrázková značka,
  • registry - register obrázkov,
  • registry_url - protokol (https://) a register obrázkov,
  • fqin — úplné umiestnenie obrázka.
• Funkcia findByName pomáha nájsť zdroj podľa daného typu (kind) a meno (name) zo vstupného súboru.
• Funkcia findByLabels pomáha nájsť zdroj podľa zadaného typu (kind) a štítky (labels).

Môžete zobraziť všetky dostupné servisné funkcie tu.

V predvolenom nastavení načíta celý vstupný súbor YAML do premennej $$ a sprístupňuje ho na skriptovanie (známa technika pre tých, ktorí majú skúsenosti s jQuery).

Hlavná výhoda Copper je zrejmá: nepotrebujete ovládať špecializovaný jazyk a môžete použiť rôzne funkcie JavaScriptu na vytváranie vlastných testov, ako je interpolácia reťazcov, funkcie atď.

Treba tiež poznamenať, že aktuálna verzia Copper pracuje s verziou ES5 JavaScript motora, nie ES6.

Podrobnosti sú dostupné na oficiálna stránka projektu.

Ak však nemáte veľmi radi JavaScript a preferujete jazyk špeciálne navrhnutý na vytváranie dopytov a popis politík, mali by ste venovať pozornosť conftestu.

5.Conftest

Conftest je rámec na testovanie konfiguračných údajov. Vhodné aj na testovanie/overovanie Kubernetes manifestov. Testy sú opísané pomocou špecializovaného dotazovacieho jazyka Rego.

Contest môžete nainštalovať pomocou inštrukcieuvedené na webovej stránke projektu.

V čase písania pôvodného článku bola najnovšia dostupná verzia 0.18.2.

Podobne ako config-lint a medi, conftest prichádza bez akýchkoľvek vstavaných testov. Vyskúšajme si to a napíšme si vlastnú politiku. Rovnako ako v predchádzajúcich príkladoch skontrolujeme, či sú obrázky kontajnerov prevzaté zo spoľahlivého zdroja.

Vytvorte adresár conftest-checksa v ňom je súbor s názvom check_image_registry.rego s nasledujúcim obsahom:

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

Teraz poďme testovať base-valid.yaml cez 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 podľa očakávania zlyhal, pretože obrázky pochádzajú z nedôveryhodného zdroja.

V súbore Rego definujeme blok deny. Jeho pravdivosť sa považuje za porušenie. Ak bloky deny niekoľko, confest ich kontroluje nezávisle od seba a pravdivosť ktoréhokoľvek z blokov sa považuje za porušenie.

Okrem predvoleného výstupu podporuje conftest formát JSON, TAP a tabuľky – mimoriadne užitočná funkcia, ak potrebujete vložiť zostavy do existujúceho kanála CI. Pomocou príznaku môžete nastaviť požadovaný formát --output.

Na uľahčenie ladenia politík má conftest príznak --trace. Výstupom je stopa o tom, ako confest analyzuje špecifikované súbory politiky.

Pravidlá súťaže môžu byť publikované a zdieľané v registroch OCI (Open Container Initiative) ako artefakty.

príkazy push и pull vám umožní publikovať artefakt alebo získať existujúci artefakt zo vzdialeného registra. Skúsme publikovať politiku, ktorú sme vytvorili, do lokálneho registra Docker pomocou conftest push.

Spustite lokálny register Docker:

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

V inom termináli prejdite do adresára, ktorý ste vytvorili predtým conftest-checks a spustite nasledujúci príkaz:

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

Ak bol príkaz úspešný, zobrazí sa správa podobná tejto:

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

Teraz vytvorte dočasný adresár a spustite príkaz v ňom conftest pull. Stiahne balík vytvorený predchádzajúcim príkazom:

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

V dočasnom adresári sa zobrazí podadresár policyobsahujúci náš súbor zásad:

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

Testy je možné spustiť priamo z úložiska:

$ 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

Bohužiaľ, DockerHub zatiaľ nie je podporovaný. Ak teda použijete, považujte sa za šťastného Register kontajnerov Azure (ACR) alebo vlastný register.

Formát artefaktu je rovnaký ako Otvorte balíky agenta politiky (OPA), ktorý vám umožňuje použiť conftest na spustenie testov z existujúcich balíkov OPA.

Viac o zdieľaní pravidiel a ďalších funkciách contestu sa dozviete na oficiálna stránka projektu.

6. Polaris

Posledným nástrojom, o ktorom sa bude diskutovať v tomto článku, je Polaris. (Jeho minuloročné vyhlásenie my už preložené - približne. preklad)

Polaris je možné nainštalovať v klastri alebo použiť v režime príkazového riadka. Ako ste možno uhádli, umožňuje vám staticky analyzovať manifesty Kubernetes.

Pri spustení v režime príkazového riadka sú k dispozícii vstavané testy pokrývajúce oblasti, ako je bezpečnosť a osvedčené postupy (podobne ako kube-score). Okrem toho si môžete vytvoriť svoje vlastné testy (ako v config-lint, medi a conftest).

Inými slovami, Polaris kombinuje výhody oboch kategórií nástrojov: so vstavanými a vlastnými testami.

Ak chcete nainštalovať Polaris v režime príkazového riadka, použite pokyny na webovej stránke projektu.

V čase písania pôvodného článku je dostupná verzia 1.0.3.

Po dokončení inštalácie môžete spustiť polaris na manifeste base-valid.yaml s nasledujúcim príkazom:

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

Vypíše reťazec vo formáte JSON s podrobným popisom vykonaných testov a ich výsledkov. Výstup bude mať nasledujúcu štruktúru:

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

Plný výstup k dispozícii tu.

Podobne ako kube-score, Polaris identifikuje problémy v oblastiach, kde manifest nespĺňa osvedčené postupy:

• Neexistujú žiadne zdravotné kontroly strukov.
• Značky pre obrázky kontajnerov nie sú zadané.
• Kontajner beží ako root.
• Požiadavky a limity pre pamäť a CPU nie sú špecifikované.

Každému testu je v závislosti od jeho výsledkov priradený stupeň kritickosti: varovanie alebo nebezpečenstvo. Ak sa chcete dozvedieť viac o dostupných vstavaných testoch, pozrite si dokumentáciu.

Ak nie sú potrebné podrobnosti, môžete zadať príznak --format score. V tomto prípade Polaris vydá číslo v rozsahu od 1 do 100 − skóre (t. j. hodnotenie):

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

Čím je skóre bližšie k 100, tým vyšší je stupeň zhody. Ak skontrolujete výstupný kód príkazu polaris audit, ukáže sa, že sa rovná 0.

sila polaris audit Prácu s nenulovým kódom môžete ukončiť pomocou dvoch príznakov:

• vlajka --set-exit-code-below-score berie ako argument prahovú hodnotu v rozsahu 1-100. V tomto prípade sa príkaz ukončí s kódom ukončenia 4, ak je skóre pod prahovou hodnotou. To je veľmi užitočné, keď máte určitú prahovú hodnotu (povedzme 75) a potrebujete dostať upozornenie, ak skóre klesne.
• vlajka --set-exit-code-on-danger spôsobí zlyhanie príkazu s kódom 3, ak jeden z testov nebezpečenstva zlyhá.

Teraz sa pokúsme vytvoriť vlastný test, ktorý skontroluje, či je obrázok prevzatý z dôveryhodného úložiska. Vlastné testy sú špecifikované vo formáte YAML a samotný test je popísaný pomocou schémy JSON.

Nasledujúci útržok kódu YAML popisuje nový test s názvom 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/.+$

Poďme sa na to pozrieť bližšie:

• successMessage — tento riadok sa vytlačí, ak sa test dokončí úspešne;
• failureMessage — táto správa sa zobrazí v prípade zlyhania;
• category — označuje jednu z kategórií: Images, Health Checks, Security, Networking и Resources;
• target--- určuje, aký typ objektu (spec) sa použije test. Možné hodnoty: Container, Pod alebo Controller;
• Samotný test je špecifikovaný v objekte schema pomocou schémy JSON. Kľúčové slovo v tomto teste je pattern slúži na porovnanie zdroja obrazu s požadovaným.

Ak chcete spustiť vyššie uvedený test, musíte vytvoriť nasledujúcu konfiguráciu 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)

Poďme analyzovať súbor:

• V poli checks testy a ich úroveň kritickosti sú predpísané. Keďže je žiaduce dostávať varovanie, keď je obrázok nasnímaný z nedôveryhodného zdroja, nastavíme úroveň tu danger.
• Samotný test checkImageRepo potom zaregistrovaný v objekte customChecks.

Uložte súbor ako custom_check.yaml. Teraz môžete bežať polaris audit s manifestom YAML, ktorý vyžaduje overenie.

Otestujme náš manifest base-valid.yaml:

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

Tím polaris audit spustil iba používateľský test špecifikovaný vyššie a zlyhal.

Ak upravíte obrázok na my-company.com/http-echo:1.0, Polaris úspešne dokončí. Manifest so zmenami je už pripravený úložiskátakže môžete skontrolovať predchádzajúci príkaz v manifeste image-valid-mycompany.yaml.

Teraz vyvstáva otázka: ako spustiť vstavané testy spolu s vlastnými? Jednoducho! Stačí pridať vstavané testovacie identifikátory do konfiguračného súboru. V dôsledku toho bude mať nasledujúcu formu:

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)

K dispozícii je príklad úplného konfiguračného súboru tu.

Skontrolujte manifest base-valid.yamlpomocou vstavaných a vlastných testov môžete použiť príkaz:

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

Polaris dopĺňa vstavané testy vlastnými testami, čím spája to najlepšie z oboch svetov.

Na druhej strane nemožnosť používať výkonnejšie jazyky ako Rego či JavaScript môže byť limitujúcim faktorom, ktorý bráni vytváraniu sofistikovanejších testov.

Viac informácií o Polaris je k dispozícii na webová stránka projektu.

Zhrnutie

Aj keď je k dispozícii veľa nástrojov na kontrolu a vyhodnotenie súborov Kubernetes YAML, je dôležité mať jasnú predstavu o tom, ako budú testy navrhnuté a vykonané.

Napríklad, ak vezmete manifesty Kubernetes cez potrubie, kubeval by mohol byť prvým krokom v takomto potrubí. Monitoroval by, či definície objektov zodpovedajú schéme Kubernetes API.

Po dokončení takéhoto preskúmania je možné prejsť k sofistikovanejším testom, ako je dodržiavanie štandardných osvedčených postupov a špecifických zásad. Tu by sa hodili kube-score a Polaris.

Pre tých, ktorí majú zložité požiadavky a potrebujú si testy detailne prispôsobiť, by boli vhodné medi, config-lint a conftest.

Conftest a config-lint používajú YAML na definovanie vlastných testov a med vám poskytuje prístup k úplnému programovaciemu jazyku, čo z neho robí celkom atraktívnu voľbu.

Na druhej strane, oplatí sa použiť niektorý z týchto nástrojov a teda vytvárať všetky testy ručne, alebo uprednostniť Polaris a pridať doň len to, čo je potrebné? Na túto otázku neexistuje jednoznačná odpoveď.

V tabuľke nižšie nájdete stručný popis každého nástroja:

Nástroj
osud
Obmedzenie
Užívateľské testy

kubeval
Overí manifesty YAML voči konkrétnej verzii schémy API
Nedá sa pracovať s CRD
Nie

kube-skóre
Analyzuje prejavy YAML proti osvedčeným postupom
Nie je možné vybrať verziu rozhrania Kubernetes API na kontrolu zdrojov
Nie

meď
Všeobecný rámec na vytváranie vlastných testov JavaScript pre manifesty YAML
Žiadne vstavané testy. Slabá dokumentácia
Да

config-lint
Všeobecný rámec na vytváranie testov v jazyku špecifickom pre doménu, ktorý je súčasťou YAML. Podporuje rôzne konfiguračné formáty (napr. Terraform)
Neexistujú žiadne hotové testy. Vstavané tvrdenia a funkcie nemusia stačiť
Да

súperiť
Rámec na vytváranie vlastných testov pomocou Rego (špecializovaný dotazovací jazyk). Umožňuje zdieľanie politík prostredníctvom balíkov OCI
Žiadne vstavané testy. Musím sa naučiť Rego. Docker Hub nie je podporovaný pri zverejňovaní zásad
Да

Polaris
Recenzie YAML sa prejavujú proti štandardným osvedčeným postupom. Umožňuje vám vytvárať vlastné testy pomocou schémy JSON
Testovacie možnosti založené na schéme JSON nemusia byť dostatočné
Да

Keďže tieto nástroje nie sú závislé od prístupu ku klastru Kubernetes, ich inštalácia je jednoduchá. Umožňujú filtrovať zdrojové súbory a poskytujú rýchlu spätnú väzbu autorom žiadostí o stiahnutie v projektoch.

PS od prekladateľa

Prečítajte si aj na našom blogu:

• «Polaris bol predstavený s cieľom udržať zdravé klastre Kubernetes»;
• «Vim s podporou YAML pre Kubernetes»;
• «7 osvedčených postupov na používanie kontajnerov podľa Googlu".

Zdroj: hab.com