🥇Kubernetes YAML validálása a legjobb gyakorlatok és politikák szerint

Megjegyzés fordítás.: A YAML-konfigurációk számának növekedésével a K8s-környezetekben egyre aktuálisabbá válik az igény a sajátos ellenőrzésük automatizálására. A cikk szerzője nemcsak a meglévő megoldásokat gyűjtötte össze erre a feladatra, hanem egy Deployment példáján is bemutatta, hogyan működnek. Nagyon informatív lett azok számára, akiket ez a téma érdekel.

Röviden összefoglalva: A cikkben hat statikus eszköz összehasonlítása történik, amelyek a YAML-fájlok Kubernetes legjobb gyakorlataival és követelményeivel kapcsolatos ellenőrzését és értékelését végzik.

A Kubernetes munkaterheléseit általában YAML-dokumentumok formájában definiálják. Az egyik probléma a YAML-lal az, hogy nehéz korlátozásokat vagy kapcsolatokat meghatározni a manifest fájlok között.

Mi van, ha biztosak szeretnénk lenni abban, hogy az összes, a klaszterbe telepített kép egy megbízható tárolóból származik?

Hogyan akadályozzuk meg a Deploymentek klaszterbe történő küldését, ha a PodDisruptionBudgets nincsenek megadva?

A statikus tesztelés integrálása lehetővé teszi a hibák és a politikai megsértések azonosítását a fejlesztés korai szakaszában. Ezzel növeljük az erőforrások definíciójának helyességét és biztonságát, valamint a valós környezetben való legjobb gyakorlatok betartásának esélyeit.

A Kubernetes YAML-fájlok statikus ellenőrzésének ökoszisztémáját a következő kategóriákra bonthatjuk:

API-validátorok. Az ebbe a kategóriába tartozó eszközök ellenőrzik a YAML-manifestet, hogy megfelel-e a Kubernetes API-szerver követelményeinek.
Kész tesztelők. A ezen kategóriába tartozó eszközök kész tesztekkel érkeznek a biztonság, a legjobb gyakorlatok betartása stb. tekintetében.
Egyedi validátorok. E kategória képviselői lehetővé teszik egyedi tesztek létrehozását különböző nyelveken, például Regóban és Javascriptben.

Ebben a cikkben hat különböző eszközt fogunk bemutatni és összehasonlítani:

kubeval;
kube-score;
config-lint;
copper;
conftest;
Polaris.

Nos, kezdjük el!

Deploymentek ellenőrzése

Mielőtt elkezdenénk az eszközök összehasonlítását, létre kell hoznunk egy alapot, amelyen tesztelni fogjuk őket.

Az alábbi manifest számos hibát és a legjobb gyakorlatokhoz való eltérést tartalmaz: hányat tudtok találni közülük?

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)

Ezt a YAML-t fogjuk használni különböző eszközök összehasonlítására.

A fenti manifeszt base-valid.yaml és a cikkben szereplő egyéb manifesztok megtalálhatóak itt: Git-tárolóban..

A manifeszt egy webalkalmazást ír le, amelynek alapfeladata, hogy "Hello World" üzenetet válaszoljon az 5678-as porton. A következő parancs segítségével telepíthető:

kubectl apply -f hello-world.yaml

Most ellenőrizzük a működést:

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

Most látogasson el a következő címre http://localhost:8080 és erősítse meg, hogy az alkalmazás működik. De vajon a legjobb gyakorlatoknak megfelelően készült? Nézzük meg.

1. Kubeval

A kubeval alapja az az elképzelés, hogy a Kubernetes-szel való interakció a REST API-ján keresztül történik. Más szavakkal, az API séma használható a YAML ellenőrzésére, hogy az megfelel-e neki. Nézzük meg a példát. Telepítési utasítások a kubeval-hoz elérhetők a projekt honlapján. Az eredeti cikk írásakor már elérhető volt a 0.15.0 verzió.

A telepítés után etessük meg a fent említett manissztel: $ kubeval base-valid.yaml PASS - base-valid.yaml contains a valid Deployment (http-echo) PASS - base-valid.yaml contains a valid Service (http-echo)

Siker esetén a kubeval 0-ás kilépési kóddal fejezi be a működését. Ezt így ellenőrizhetjük:

$ echo $? 0

Most próbáljuk meg a kubeval-t egy másik manisszel:

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

Meg tudja határozni a problémát? Futtassuk:

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

# Ellenőrizzük a visszatérési kódot
$ echo $?
1

(Az erőforrás nem felelt meg az ellenőrzésnek.)

A Deploymentek, amelyek az API verziót használják

apps/v1

, tartalmazniuk kell egy szelektort, amely megfelel a pod címkéjének. A fenti manifeszt nem tartalmaz szelektort, ezért a kubeval hibát jelzett, és nem nulla kilépési kóddal lépett ki.

Kíváncsi vagyok, mi történik, ha futtatjuk ezt a manisst?Nos, próbáljuk ki:

Интересно, что произойдет, если выполнить kubectl apply -f с этим манифестом?

Что ж, давайте попробуем:

$ 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

Ez az a hiba, amire a kubeval figyelmeztetett. Kijavítható úgy, hogy megadja a szelektort:

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)

Az olyan eszközök, mint a kubeval, előnye, hogy az ilyen hibákat a telepítési ciklus korai szakaszában lehet észlelni.

Ezen kívül ezekhez az ellenőrzésekhez nincs szükség a klaszterhez való hozzáférésre: offline is elvégezhetők.

Alapértelmezés szerint a kubeval az erőforrásokat a Kubernetes API legfrissebb séma szerinti illeszkedés tesztelésére használja. Azonban a legtöbb esetben előfordulhat, hogy egy adott Kubernetes kiadással való összhang vizsgálatára van szüksége. Ezt a ---flag segítségével teheti meg. --kubernetes-version:

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

Ne feledje, hogy a verziót a következő formátumban kell megadni: Major.Minor.Patch.

A verziók listájának megtekintéséhez, amelyekhez támogatott az ellenőrzés, látogasson el a JSON séma a GitHubon, amelyet a kubeval használ az érvényesítéshez. Ha offline szeretné futtatni a kubeval-t, töltse le a sémákat, és adja meg a helyüket a ---flag segítségével. --schema-location.

A különálló YAML fájlok mellett a kubeval mappákkal és stdin-nel is képes dolgozni.

Ezen kívül a Kubeval könnyen integrálható a CI pipeline-ba. Akik a templátumok klaszterbe való küldése előtt tesztelni szeretnének, örömmel értesülhetnek arról, hogy a kubeval három kimeneti formátumot támogat:

Normál szöveg;
JSON;
Test Anything Protocol (TAP).

Bármelyik formátumot felhasználhatja a kimenet további feldolgozására, hogy a kívánt eredmény összefoglalását képezze.

A kubeval egyik hátránya, hogy jelenleg nem tudja ellenőrizni a Custom Resource Definitions (CRD) összhangját. Azonban a kubeval beállítható, hogy figyelmen kívül hagyja őket..

A Kubeval egy nagyszerű eszköz az erőforrások ellenőrzésére és értékelésére; azonban hangsúlyozni kell, hogy a teszten való sikeres átmenet nem garantálja, hogy az erőforrás a legjobb gyakorlatoknak megfelel.

Például a címke használata latest A konténer nem felel meg a legjobb gyakorlatoknak. Azonban a kubeval ezt nem tekinti hibának, és nem jelez róla. Tehát az ilyen YAML ellenőrzése figyelmeztetések nélkül zárul.

De mi van, ha szükség van a YAML értékelésére és a hibák, például a tagok azonosítására? latest? Как проверить YAML-файл на соответствие лучшим практикам?

2. Kube-score

Kube-score elemzi a YAML manifestumokat, és beépített tesztek alapján értékeli azokat. Ezek a tesztek a biztonsági ajánlások és a legjobb gyakorlatok szerint kerülnek kiválasztásra, például:

A konténer nem root felhasználóként fut.
A pod egészségi ellenőrzése megléte.
Erőforrások requestjeinek és limitjeinek beállítása.

A teszt eredményeként három kimenet jelenik meg: OK, FIGYELMEZTETÉS és KRITIKUS.

A Kube-score-t online is próbálhatjuk, vagy telepíthetjük helyben.

A cikk írásakor a kube-score legfrissebb verziója 1.7.0 volt.

Próbáljuk ki a manifestunkat. base-valid.yaml:

$ kube-score score base-valid.yaml

apps/v1/Deployment http-echo
[KRITIKUS] Konténer Kép Címke
  · http-echo -> Kép a legfrissebb címkével
      Ajánlott rögzített címkét használni a véletlen frissítések elkerülése érdekében.
[KRITIKUS] Pod Hálózati Szabály
  · A podnak nem található megfelelő hálózati szabálya.
      Hozzon létre egy Hálózati Szabályt, amely célozza meg ezt a podot.
[KRITIKUS] Pod Ellenőrzések
  · A konténerből hiányzik egy readinessProbe
      A readinessProbe használata javasolt, hogy jelezze, mikor készen áll a szolgáltatás a forgalom fogadására.
      Nélküle a pod kockázat egy forgalom fogadása, mielőtt elindult volna. Ez használatos a
      telepítéseknél is, és segíthet a leállás elkerülésében, ha az alkalmazás új verziója nem működik.
      További információ: https://github.com/zegl/kube-score/blob/master/README_PROBES.md
[KRITIKUS] Konténer Biztonsági Kontextus
  · http-echo -> A konténernek nincs konfigurált biztonsági kontextusa.
      Állítsa be a securityContext értéket, hogy a konténer egy biztonságosabb kontextusban fusson.
[KRITIKUS] Konténer Erőforrások
  · http-echo -> CPU limit nincs beállítva.
      Az erőforrás korlátok beállítása ajánlott az erőforrás DDOS elkerülése érdekében. Állítsa be a resources.limits.cpu-t.
  · http-echo -> Memória limit nincs beállítva.
      Az erőforrás korlátok beállítása ajánlott az erőforrás DDOS elkerülése érdekében. Állítsa be a resources.limits.memory-t.
  · http-echo -> CPU kérés nincs beállítva.
      Az erőforrás kérdések beállítása javasolt annak biztosítása érdekében, hogy az alkalmazás elindulhasson és futhasson anélkül, hogy összeomlana. Állítsa be a resources.requests.cpu-t.
  · http-echo -> Memória kérés nincs beállítva.
      Az erőforrás kérdések beállítása javasolt annak biztosítása érdekében, hogy az alkalmazás elindulhasson és futhasson anélkül, hogy összeomlana.
      Állítsa be a resources.requests.memory-t.
[KRITIKUS] Telepítés PodKárosedési Költségvetéssel rendelkezik
  · Nem található megfelelő PodKárosedési Költségvetés.
      Ajánlott definiálni egy PodKárosedési Költségvetést, hogy elkerüljük a váratlan leállásokat a Kubernetes
      karbantartási műveletei során, például amikor egy csomópont lemerül.
[FIGYELMEZTETÉS] Telepítésnek Splitt PodEllenséges Affinitása van
  · A telepítésnek nincs beállítva podAntiAffinity.
      Ajánlott beállítani a podAntiAffinity-t, amely megakadályozza, hogy egy telepítés több podja egy csomóponton legyen ütemezve. Ez növeli a rendelkezésre állást, ha a csomópont elérhetetlenné válik.

A YAML átmegy a kubeval ellenőrzésein, míg a kube-score a következő hátrányokra hívja fel a figyelmet:

Nincsenek beállítva a readiness ellenőrzések.
Hiányoznak a CPU és memória erőforrásokra vonatkozó kérdések és korlátok.
Nincsenek megadva Pod károsedési költségvetések.
Hiányoznak a különélő létezési szabályok (anti-affinity). (anti-affinity) az elérhetőség maximalizálásához.
A konténer root jogosultságokkal fut.

Mindez ésszerű megjegyzések a hiányosságokról, amelyeket érdemes kijavítani, hogy a Deployment hatékonyabb és megbízhatóbb legyen.

A parancs kube-score az összes típust sértő hiba részletezett, könnyen olvasható formában adja meg FIGYELMEZTETÉS és KRITIKUS, ami nagyon segít a fejlesztés során.

Azok, akik ezt az eszközt CI pipeline keretein belül használják, bekapcsolhatják az összesített kimenetet az --output-format ci (ebben az esetben a teszteket is megjeleníti az eredménnyel együtt OK):

$ kube-score score base-valid.yaml --output-format ci

[OK] http-echo apps/v1/Deployment
[OK] http-echo apps/v1/Deployment
[KRITIKUS] http-echo apps/v1/Deployment: (http-echo) CPU korlát nincs megadva
[KRITIKUS] http-echo apps/v1/Deployment: (http-echo) Memória korlát nincs megadva
[KRITIKUS] http-echo apps/v1/Deployment: (http-echo) CPU kérés nincs megadva
[KRITIKUS] http-echo apps/v1/Deployment: (http-echo) Memória kérés nincs megadva
[KRITIKUS] http-echo apps/v1/Deployment: (http-echo) Legújabb címkével rendelkező kép
[OK] http-echo apps/v1/Deployment
[KRITIKUS] http-echo apps/v1/Deployment: A pod nem rendelkezik megfelelő hálózati házirenddel
[KRITIKUS] http-echo apps/v1/Deployment: A konténer hiányzik egy readinessProbe-val
[KRITIKUS] http-echo apps/v1/Deployment: (http-echo) A konténerhez nincs beállítva biztonsági kontextus
[KRITIKUS] http-echo apps/v1/Deployment: Nincs megfelelő PodDisruptionBudget megadva
[FIGYELMEZTETÉS] http-echo apps/v1/Deployment: A Deployment nem rendelkezik host podAntiAffinity beállítással
[OK] http-echo v1/Szolgáltatás
[OK] http-echo v1/Szolgáltatás
[OK] http-echo v1/Szolgáltatás
[OK] http-echo v1/Szolgáltatás

A kubeval-hoz hasonlóan a kube-score is nem nullás kilépési kódot ad vissza, ha egy teszt hibával zárul. KRITIKUS. Hasonlóan analóg feldolgozást be lehet kapcsolni a FIGYELMEZTETÉS.

Ezen kívül lehetőség van az erőforrások ellenőrzésére a különböző API verzióknak megfelelően (ahogyan a kubeval esetében). Azonban ez az információ 'hardcode'-olva van a kube-score-ban: nem lehet másik Kubernetes verziót választani. Ez a korlátozás nagy problémát okozhat, ha frissíteni kívánja a klasztert, vagy ha több klasztere van különböző K8s verziókkal.

p(x) – már létezik egy probléma a funkció megvalósításának javaslatával.

További információt a kube-score-val kapcsolatban hivatalos oldalon.

A kube-score tesztek nagyszerű eszközök a legjobb gyakorlatok bevezetésére, de mi van, ha módosításokat kell végezni a teszten, vagy saját szabályokat kell hozzáadni? Sajnos, ezt nem lehet megtenni.

A kube-score nem bővíthető: nem lehet hozzáadni semmilyen politikát, vagy azokat testre szabni.

Ha testreszabott teszteket kell írni a vállalat által elfogadott politikák ellenőrzésére, az alábbi négy eszköz egyikét használhatja: config-lint, copper, conftest vagy polaris.

3. Config-lint

A Config-lint egy eszköz a YAML, JSON, Terraform, CSV formátumú konfigurációs fájlok és Kubernetes manifesztumok érvényesítésére.

Telepíthető a utasítások a projekt webhelyén.

A jelenlegi kiadás a cikk eredeti írásának időpontjában: 1.5.0.

A Config-lint nem tartalmaz beépített teszteket a Kubernetes manifesztumok ellenőrzésére.

Bármilyen teszt végzéséhez megfelelő szabályokat kell létrehozni. Ezek YAML fájlokban vannak rögzítve, amelyeket "szabálykészleteknek" (rulesets)neveznek, és a következő struktúrával rendelkeznek:

version: 1
description: Szabályok a Kubernetes specifikációs fájlokhoz
type: Kubernetes
files:
  - "*.yaml"
rules:
   # szabályok listája

(rule.yaml)

Nézzük meg közelebbről:

Mező type megmondja, hogy a config-lint milyen típusú konfigurációt fog használni. K8s manifesztumok esetén ez kíméletlenek voltak Kubernetes.
A mezőben files a fájlok mellett egy könyvtárat is megadhat.
Mező szabályok célja a felhasználói tesztek megadásának.

Tegyük fel, hogy biztosítani akarja, hogy a Deployment képek mindig megbízható adattárból legyenek letöltve, például my-company.com/myapp:1.0. A config-lint számára egy ilyen ellenőrzést végző szabály a következőképpen fog kinézni:

- id: MY_DEPLOYMENT_IMAGE_TAG
  severity: FAILURE
  message: A Deployment-nek érvényes képjelzőt kell használnia
  resource: Deployment
  assertions:
    - every:
        key: spec.template.spec.containers
        expressions:
          - key: image
            op: starts-with
            value: "my-company.com/"

(rule-trusted-repo.yaml)

Minden szabály számára az alábbi attribútumokat kell megadni:

id — a szabály egyedi azonosítója;
severity — lehet FAILURE, FIGYELMEZTETÉS és NON_COMPLIANT;
üzenet — a szabály megsértése esetén a sor tartalmát jeleníti meg;
resource — a szabályhoz tartozó erőforrás típusa;
assertions — a szabályhoz tartozó feltételek listája, amelyeket az adott erőforrásra fognak értékelni.

A fenti szabályban assertion Nornir néven hívtak every ellenőrzi, hogy a Deployment-ben lévő összes konténer (key: spec.templates.spec.containers) megbízható képeket használ (azaz, amelyek a következővel kezdődnek: my-company.com/).

A teljes szabálykészlet a következőképpen néz ki:

version: 1
description: Szabályok a Kubernetes specifikációs fájlokhoz
type: Kubernetes
files:
  - "*.yaml"
rules:

 - id: DEPLOYMENT_IMAGE_REPOSITORY # !!!
    severity: FAILURE
    message: A Deployment-nek érvényes kép adattárat kell használnia
    resource: Deployment
    assertions:
      - every:
          key: spec.template.spec.containers
          expressions:
            - key: image
              op: starts-with
              value: "my-company.com/"

(ruleset.yaml)

Teszteléshez mentsük el a következőt: check_image_repo.yaml. Futtassuk a fájltellenőrzést. base-valid.yaml:

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

[
  {
  "AssertionMessage": "Minden kifejezés hibát jelez: Az 'And' kifejezés hibát jelez: a kép nem a my-company.com/-ról indul",
  "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": "A telepítésnek érvényes kép-gyűjtőt kell használnia",
  "Status": "FAILURE"
  }
]

A vizsgálat sikertelenül zárult. Most nézzük meg a következő manifesztet az érvényes kép-gyűjtővel:

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)

Ugyanazt a tesztet futtatjuk a fent említett manifesztussal. Nincs probléma:

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

A Config-lint egy ígéretes keretrendszer, amely lehetővé teszi saját tesztek létrehozását a Kubernetes YAML-manifesztusok ellenőrzésére YAML DSL segítségével.

De mi a teendő, ha bonyolultabb logikára és tesztekre van szükség? Vajon a YAML lehetőségei nem túl korlátozottak ehhez? Mi lenne, ha teljes értékű programozási nyelven lehetne teszteket írni?

4. Copper

Copper V2 — egy keretrendszer, amely lehetővé teszi a manifesztusok validálását egyedi tesztekkel (a config-lint analógja).

Azonban abban különbözik az utóbbitól, hogy nem használ YAML-t a tesztek leírására. Ehelyett a teszteket JavaScript nyelven lehet létrehozni. A Copper biztosít egy könyvtárat, amely néhány alapvető eszközt tartalmaz, amelyek segítenek a Kubernetes objektumok információinak olvasásában és a hibák jelentésében.

A Copper telepítési lépéseit itt találja: hivatalos dokumentációban.

2.0.1 — a legfrissebb kiadása ennek az eszköznek az eredeti cikk írásának időpontjában.

A config-lintendhez hasonlóan a Coppernek sincs beépített tesztje. Írjunk egyet. Tegyük fel, hogy ellenőrizzük, hogy a telepítések csak megbízható gyűjtőkből származó konténerképeket használnak, mint például my-company.com.

Hozzon létre egy fájlt. check_image_repo.js a következő tartalommal:

$$.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',"A " + $.metadata.name + " nem a my-company.com gyűjtőből származik", 1)
            }
        });
    }
});

Most, hogy ellenőrizzük a manifesztünket base-valid.yaml, használja a parancsot copper validate:

$ copper validate --in=base-valid.yaml --validator=check_image_tag.js

A no_company_repo ellenőrzés 1-es súlyossággal megbukott, mert a http-echo nem a my-company.com gyűjtőből származik
A validálás sikertelen

Nyilvánvaló, hogy a copper segítségével bonyolultabb teszteket is végezhetünk, például ellenőrizhetjük a domain neveket az Ingress manifesztjeiben, vagy elutasíthatjuk a priviligált módban futó pod-okat.

A Copper különféle segédfunkciókat tartalmaz:

DockerImage felolvassa a megadott bemeneti fájlt, és létrehoz egy objektumot a következő attribútumokkal:
- name — képnév,
- tag — képjelző,
- registry — képtárhely,
- registry_url — protokoll (LETS_ENCRYPT_STAGING) és képtárhely,
- fqin — a kép teljes elérési útja.
Funkció findByName segít megtalálni az erőforrást a megadott típus szerint (kind) és név (name) a bemeneti fájlból.
Funkció findByLabels segít megtalálni az erőforrást a megadott típus (kind) és címkék (címkéket).

Az összes elérhető segédfunkciót megismerheti itt.

Alapértelmezés szerint az összes bemeneti YAML-fájlt betölti a változóba $$ és elérhetővé teszi azt a szkriptek számára (ez egy ismerős módszer az olyanok számára, akik tapasztalattal rendelkeznek a jQuery használatában).

A Copper legnagyobb előnye nyilvánvaló: nem kell egy speciális nyelvet elsajátítania, és a JavaScript különféle lehetőségeit használhatja saját tesztek létrehozásához, mint például a string interpoláció, funkciók stb.

Meg kell említeni, hogy a Copper jelenlegi verziója az ES5 JavaScript motorral működik, nem pedig az ES6-tal.

Részletek elérhetők itt: a projekt hivatalos weboldalán..

Ha viszont nem szereti a JavaScriptet, és inkább egy, a lekérdezések és politikák leírására kifejezetten kialakított nyelvet preferál, érdemes figyelmet fordítania a conftest-ra.

5. Conftest

A Conftest egy keretrendszer a konfigurációs adatok ellenőrzésére. Alkalmas Kubernetes manifesztumok tesztelésére/ellenőrzésére is. A tesztek egy speciális lekérdezési nyelven, Rego.

segítségével írhatók. utasításokA conftest telepítése a

projekthez kapcsolódó honlapon található utasításokat követve történik.

Az eredeti cikk írásakor a legfrissebb elérhető verzió 0.18.2 volt.

A config-linthez és a copperhez hasonlóan a conftest is beépített tesztek nélkül érkezik. Próbáljuk ki, és írjunk saját politikát. A korábbi példákhoz hasonlóan azt fogjuk ellenőrizni, hogy a tárolóképek megbízható forrásból származnak-e. Hozzon létre egy könyvtárat,conftest-checks , benne pedig egy fájlt a következő névvel: a következő tartalommal:

check_image_registry.rego

package maindeny[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]) } base-valid.yaml -kérések, Most teszteljük a:

conftest-tot

$ 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

A teszt várhatóan megbukott, mivel a képek megbízhatatlan forrásból származnak.

A Rego fájlban a blokkot állítjuk be tagadás. Igazságának vizsgálata megsértésnek számít. Ha több blokk van tagadás , a conftest függetlenül ellenőrzi azokat, és bármelyik blokk igazságát megsértésként kezeljük.

A default kimenet mellett a conftest támogatja a JSON, TAP és táblázatos formátumokat is - rendkívül hasznos lehetőség, ha a jelentéseket egy meglévő CI folyamatba kell beépíteni. A szükséges formátumot a következő kapcsolóval lehet megadni --output.

A politikák hibakeresésének megkönnyítése érdekében a conftest rendelkezik egy kapcsolóval --trace. Ez megjeleníti, hogy a conftest hogyan elemzi a megadott politikai fájlokat.

A conftest politikákat közzé lehet tenni és megosztani OCI-repositoriokban (Open Container Initiative) mint artefaktumokat.

Csapatok töltés és pull lehetővé teszi artefaktum közzétételét vagy meglévő artefaktum kinyerését egy távoli repósból. Próbáljuk meg közzétenni általunk létrehozott politikát a helyi Docker repóban a következővel conftest push.

Indítsa el a helyi Docker repót:

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

Egy másik terminálban lépjen a korábban létrehozott könyvtárba Hozzon létre egy könyvtárat, és futtassa a következő parancsot:

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

Ha a parancs sikeresen lefutott, a következő típusú üzenetet látja:

2020/06/10 14:25:43 feltöltve csomag digest-tel: sha256:e9765f201364c1a8a182ca637bc88201db3417bacc091e7ef8211f6c2fd2609c

Most hozzon létre egy ideiglenes könyvtárat, és hajtsa végre benne az alábbi parancsot conftest pull. Ez letölti a korábban létrehozott csomagot:

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

Az ideiglenes könyvtárban megjelenik egy alkönyvtár szabályzat, amely tartalmazza a politikai fájlunkat:

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

A teszteket közvetlenül a tárolóból is végrehajthatjuk:

$ conftest test --update 127.0.0.1:5000/amitsaha/opa-bundle-example:latest base-valid.yaml
..
FAIL - base-valid.yaml - az 'hashicorp/http-echo' kép nem a my-company.com tárolóból származik
2 teszt, 1 sikerült, 0 figyelmeztetés, 1 hiba

Sajnos a DockerHub jelenleg nem támogatott. Szóval feltételezze, hogy szerencséje van, ha az alábbiakat használja Azure Container Registry (ACR) vagy saját repóját.

Az artefaktumok formátuma ugyanaz, mint az Open Policy Agent csomagoké (OPA), ami lehetővé teszi a conftest számára, hogy teszteket futtasson meglévő OPA csomagokból.

További információk a politikák megosztásáról és a conftest egyéb funkcióiról a következő helyen találhatók: a projekt hivatalos weboldalán..

6. Polaris

Az utolsó eszköz, amelyről a cikkben szó lesz, az Polaris. (A tavalyi bejelentésünket már lefordítottuk — megjegyzés)

A Polaris telepíthető klaszterben vagy parancssori módban használható. Ahogy már sejtetted, lehetővé teszi a Kubernetes manifesztusok statikus elemzését.

Parancssori módban elérhetők az integrált tesztek, amelyek a biztonság és a legjobb gyakorlatok területeit fedik le (hasonlóan a kube-score-hoz). Ezen kívül saját teszteket is létrehozhatsz (mint a config-lint, copper és conftest).

Más szóval, a Polaris ötvözi mindkét kategória eszközeinek előnyeit: beépített és felhasználói tesztek.

A Polaris parancssori módjának telepítéséhez használd a projekt hivatalos webhelyén található útmutatót..

A cikk írásának időpontjában az 1.0.3-as verzió érhető el.

A telepítés befejezése után indíthatod a polaris-t egy manifesztumon base-valid.yaml a következő parancs segítségével:

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

Ez JSON formátumban egy sort fog kimenetként megjeleníteni, amely részletes leírást ad a végrehajtott tesztekről és azok eredményeiről. A kimenet a következő struktúrával rendelkezik:

{
  "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": [
    
     /* hosszú lista */
  ]
}

A teljes kimenet elérhető. itt.

A kube-score-hoz hasonlóan a Polaris is problémákat tár fel azokban a területekben, ahol a manifeszt nem felel meg a legjobb gyakorlatoknak:

Hiányoznak a pod-ok egészségi ellenőrzései.
Nincsenek címkék a konténer képekhez.
A konténer root jogosultságokkal fut.
Nincsenek megadva kérések és limitációk a memória és CPU számára.

Minden teszt a eredményei alapján egy kritikus szintet kap: figyelmeztetés vagy veszély. A beépített tesztekről többet az alábbiak szerint tudhatsz meg: dokumentáció.

Ha nincs szükség részletekre, megadhatod a --format scoreflag-et. Ekkor a Polaris egy 1 és 100 közötti számot fog kiadni — szám (azaz értékelés):

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

Minél közelebb van az értékelés a 100-hoz, annál magasabb a megfelelőség foka. Ha ellenőrzöd a polaris auditparancs kilépési kódját,

kiderül, hogy 0. polaris audit A parancsot nem nullával végződni lehet kényszeríteni két flag segítségével:

Zászló --set-exit-code-below-score amely egy 1-100 közötti küszöbértéket fogad el argumentumként. Ez esetben a parancs 4-es kilépési kóddal fejeződik be, ha az értékelés a küszöb alá esik. Ez hasznos, amikor van egy küszöbértéked (például 75), és értesítést kell kapnod, ha az értékelés alacsonyabbra süllyed.
Zászló --set-exit-code-on-danger Ez ahhoz vezet, hogy a csapat 3-as kóddal zárul, ha a danger-teszt közül bármelyik nem sikerül.

Most próbáljunk meg létrehozni egy egyedi tesztet, amely ellenőrzi, hogy a kép egy megbízható tárolóból származik-e. Az egyedi teszteket YAML formátumban határozzuk meg, magát a tesztet pedig JSON Schéma segítségével írjuk le.

A következő YAML-kód részlet egy új tesztet ír le, amelynek neve checkImageRepo:

checkImageRepo:
  successMessage: A képregiszter érvényes
  failureMessage: A képregiszter nem érvényes
  category: Képek
  target: Konténer
  schema:
    '$schema': http://json-schema.org/draft-07/schema
    type: object
    properties:
      image:
        type: string
        pattern: ^my-company.com/.+$

Nézzük meg közelebbről:

successMessage — ez a sor kerül kiírásra, ha a teszt sikeresen zárul;
failureMessage — ez az üzenet jelenik meg a hiba esetén;
category — egy kategóriát jelöl: Képek, Egészségügyi ellenőrzések, Biztonság, Hálózatkezelés és Erőforrások;
target— megadja, hogy mely típusú objektumra (spec) vonatkozik a teszt. Lehetséges értékek: Konténer, Pod vagy Controller;
A teszt maga egy objektumban van definiálva schema JSON schéma segítségével. Ebben a tesztben a pattern kulcsszó az image forrást hasonlítja össze a követelménnyel.

A fenti teszt futtatásához a következő Polaris konfigurációt kell elkészíteni:

checks:
  checkImageRepo: danger
customChecks:
  checkImageRepo:
    successMessage: A képregiszter érvényes
    failureMessage: A képregiszter nem érvényes
    category: Képek
    target: Konténer
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          pattern: ^my-company.com/.+$

(polaris-conf.yaml)

Nézzük meg a fájlt:

A mezőben checks a teszteket és azok kritikus szintjét tartalmazza. Mivel kívánatos figyelmeztetést kapni, amikor a kép megbízhatatlan forrásból származik, itt a szintet veszély.
A teszt magja checkImageRepo majd az objektumban van definiálva customChecks.

Mentse el a fájlt mint custom_check.yaml. Most már elindíthatjuk polaris audit a YAML-manifesztal, amely ellenőrzést igényel.

Teszteljük a manifesztünket base-valid.yaml:

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

A parancs polaris audit csak a fent megadott egyedi tesztet hajtotta végre, és az nem zárult sikerrel.

Ha a képet javítjuk my-company.com/http-echo:1.0, a Polaris sikeresen befejeződik. A módosításokkal rendelkező manifeszt már megtalálható a tárhelyen, így a korábbi parancsot a manifeszt ellenőrzésére használhatja. image-valid-mycompany.yaml.

Most felmerül a kérdés: hogyan futtathatjuk az beépített teszteket együtt az egyedi tesztekkel? Egyszerű! Csak hozzá kell adni a beépített tesztek azonosítóit a konfigurációs fájlhoz. Ennek eredményeként a következőképpen fog kinézni:

ellenőrzések:
  cpuRequestsMissing: figyelmeztetés
  cpuLimitsMissing: figyelmeztetés
  # Egyéb beépített ellenőrzések..
  # ..
  # egyéni ellenőrzések
  checkImageRepo: veszély # !!!
egyéniEllenőrzések:
  checkImageRepo:        # !!!
    successMessage: A képtár hiteles
    failureMessage: A képtár érvénytelen
    category: Képek
    target: Konténer
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          pattern: ^my-company.com/.+$

(config_with_custom_check.yaml)

Példa a teljes konfigurációs fájlra elérhető itt.

Manifest ellenőrzése base-valid.yaml, beépített és egyéni tesztek használatával a következő parancs segítségével:

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

A Polaris a beépített teszteket egyéni tesztekkel egészíti ki, így kombinálva a két világ legjobbjait.

Másrészt a fejlettebb tesztek létrehozásának megakadályozására korlátozó tényezőt jelenthet az, hogy nem lehet erősebb nyelveket, például Regot vagy JavaScriptet használni.

További információ a Polarisról elérhető itt a projekt weboldalán.

Összefoglaló

Bár számos eszköz létezik a Kubernetes YAML-fájlok ellenőrzésére és értékelésére, fontos, hogy világos képet kapjunk arról, hogyan tervezik és hajtják végre a teszteket.

Például, ha a Kubernetes manifestek a pipeline-on keresztül mennek, a kubeval lehetne az első lépés egy ilyen pipeline-ban. Ez figyelemmel kísérné, hogy az objektumok definíciói megfelelnek-e a Kubernetes API sémának.

A hasonló ellenőrzés befejezése után áttérhetünk a fejlettebb tesztekre, például a legjobb gyakorlatoknak és a speciális irányelveknek való megfelelésre. Ehhez a kube-score és a Polaris lenne hasznos.

Akiknek bonyolult követelményeik vannak, és szükségük van a tesztek részletes testreszabására, azoknak a copper, config-lint és conftest lenne megfelelő..

A Conftest és a config-lint YAML-t használnak egyéni tesztek megadására, míg a copper teljes értékű programozási nyelvet kínál, ami elég vonzó választássá teszi.

Másrészt érdemes-e egy ilyen eszközt használni, és ettől kézzel létrehozni minden tesztet, vagy inkább a Polaris-t választani, és csak azt kiegészíteni, ami szükséges? Erre a kérdésre nincs egyértelmű válasz.

Az alábbi táblázat rövid leírást tartalmaz minden eszközről:

Eszköz
Cél
Hátrányok
Egyéni tesztek

Telepítési utasítások a kubeval-hoz elérhetők a projekt honlapján.
Ellenőrzi a YAML-manifesztumokat, hogy megfelelnek-e a Kubernetes API egy adott verziójának
Nem tud CRD-kel dolgozni
Nem

kube-score
Elemzi a YAML-manifesztumokat a legjobb gyakorlatoknak való megfelelés szempontjából
Nem lehet kiválasztani a Kubernetes API verzióját az erőforrások ellenőrzéséhez
Nem

copper
Általános keretrendszer saját JavaScript tesztek létrehozásához YAML-manifesztumokhoz
Nincsenek beépített tesztek. Szegényes dokumentáció
Igen

config-lint
Általános keretrendszer tesztek létrehozásához egy tárgyorientált nyelven, amely beágyazva van a YAML-be. Támogatja a különböző konfigurációs formátumokat (pl. Terraform)
Nincsenek kész tesztek. A beépített kijelentések és funkciók esetleg nem elegendőek
Igen

Most teszteljük a
Keretrendszer saját tesztek létrehozásához Rego nyelven (speciális lekérdezési nyelv). Lehetővé teszi a politikák megosztását OCI csomagokon keresztül
Nincsenek beépített tesztek. Meg kell tanulni Regót. A Docker Hub nem támogatja a politikák közzétételét
Igen

Polaris
Elemzi a YAML-manifesztumokat a szabványos legjobb gyakorlatokkal való megfelelés érdekében. Lehetővé teszi a saját tesztek létrehozását JSON séma segítségével
A JSON sémán alapuló tesztelési lehetőségek esetleg nem elegendőek
Igen

Mivel ezek az eszközök nem függnek a Kubernetes klaszterhez való hozzáféréstől, könnyen telepíthetők. Lehetővé teszik a forrásfájlok szűrését és gyors visszajelzést biztosítanak a pull requestek szerzői számára a projektekben.

Fejlesztési eszközök, amelyek Kubernetesben futnak

Olvasson további információkat a blogunkban:

Forrás: habr.com