Validering av Kubernetes YAML för att uppfylla bästa praxis och policyer

Obs. övers.: Med den ökande mängden YAML-konfigurationer för K8s-miljöer blir behovet av automatiserad verifiering allt mer aktuellt. Författaren av denna översyn har inte bara valt ut befintliga lösningar för detta problem, utan har också tittat på hur de fungerar med hjälp av ett exempel på Deployment. Det blev ganska informativt för dem som är intresserade av detta ämne.

TL;DR: Artikeln jämför sex statiska verktyg för verifiering och utvärdering av YAML-filer i Kubernetes för att säkerställa överensstämmelse med bästa praxis och krav.

Kubernetes-arbetsbelastningar definieras vanligtvis i form av YAML-dokument. Ett av problemen med YAML är svårigheten att ange begränsningar eller relationer mellan manifestfiler.

Vad händer om vi måste säkerställa att alla bilder som distribueras i klustret hämtas från ett betrott register?

Hur förhindrar vi att Deployment skickas till klustret utan att PodDisruptionBudgets har angetts?

Integrering av statisk testning gör det möjligt att upptäcka fel och policyöverträdelser redan i utvecklingsstadiet. Detta ökar säkerheten och korrektheten i resursdefinitionerna och ökar sannolikheten för att produktionsbelastningar följer bästa praxis.

Ecosystemet för statisk verifiering av YAML-filer i Kubernetes kan delas in i följande kategorier:

• API-validatorer. Verktyg i denna kategori kontrollerar YAML-manifest mot krav från Kubernetes API-servern.
• Färdiga testare. Verktyg i denna kategori kommer med färdiga tester för säkerhet, överensstämmelse med bästa praxis, osv.
• Anpassade validatorer. Representanter för denna kategori gör det möjligt att skapa användarspecifika tester på olika språk, till exempel Rego och Javascript.

I denna artikel kommer vi att beskriva och jämföra sex olika verktyg:

1. kubeval;
2. kube-score;
3. config-lint;
4. copper;
5. conftest;
6. Polaris.

Nåväl, låt oss börja!

Verifiering av Deployment

Innan vi börjar jämföra verktygen, låt oss skapa en bas för att testa dem.

Manifestet nedan innehåller en rad fel och överträdelser av bästa praxis: hur många av dem kan du hitta?

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)

Vi kommer att använda denna YAML för att jämföra olika verktyg.

Manifestet ovan base-valid.yaml och andra manifest från denna artikel finns i Git-repository.

Manifestet beskriver en webbapplikation vars huvuduppgift är att svara med meddelandet "Hello World" på port 5678. Det kan deployeras med följande kommando:

kubectl apply -f hello-world.yaml

Och så här testar vi att det fungerar:

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

Gå nu till http://localhost:8080 och bekräfta att applikationen fungerar. Men följer det bästa praxis? Låt oss kontrollera.

1. Kubeval

Grunden för kubeval är idén att varje interaktion med Kubernetes sker via dess REST API. Med andra ord kan API-schema användas för att kontrollera om den angivna YAML överensstämmer med det. Låt oss titta på ett exempel.

Installationsanvisningar kubeval finns på projektets webbplats.

Vid tidpunkten för skrivandet av den ursprungliga artikeln var version 0.15.0 tillgänglig.

När installationen är klar, låt oss "mata" den med manifestet ovan:

$ kubeval base-valid.yaml
PASS - base-valid.yaml innehåller en giltig Deployment (http-echo)
PASS - base-valid.yaml innehåller en giltig Service (http-echo)

Vid framgång kommer kubeval att avslutas med exit-kod 0. Detta kan kontrolleras så här:

$ echo $?
0

Låt oss nu prova kubeval med ett annat manifest:

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)

Kan du se problemet vid en snabb blick? Låt oss köra:

$ kubeval kubeval-invalid.yaml
WARN - kubeval-invalid.yaml innehåller en ogiltig Deployment (http-echo) - selector: selector krävs
PASS - kubeval-invalid.yaml innehåller en giltig Service (http-echo)

# låt oss kontrollera exit-koden
$ echo $?
1

Resursen klarar inte kontrollen.

Deployment:er som använder API-version apps/v1, måste inkludera en selektor som matchar pod:ens etikett. Manifestet ovan inkluderar inte en selektor, så kubeval rapporterade ett fel och avslutades med en icke-noll exit-kod.

Det är intressant att se vad som händer om man kör kubectl apply -f med detta manifest?

Låt oss försöka:

$ 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

Det är precis det fel som kubeval varnade för. Du kan åtgärda det genom att lägga till en selector:

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)

Fördelen med verktyg som kubeval är att sådana fel kan fångas tidigt i distributionscykeln.

Dessutom kräver dessa kontroller ingen åtkomst till klustret: de kan utföras offline.

Som standard kontrollerar kubeval resurser för att säkerställa att de följer den senaste schemat från Kubernetes API. Men i de flesta fall kanske du vill utföra en kontroll mot en specifik version av Kubernetes. Detta kan göras med flaggan --kubernetes-version:

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

Observera att versionen måste anges i formatet Major.Minor.Patch.

För att se en lista över versioner som stöds för kontroll, se JSON-schemat på GitHub, som kubeval använder för validering. Om du behöver köra kubeval offline, ladda ner scheman och ange deras lokala plats med flaggan --schema-location.

Utöver enskilda YAML-filer kan kubeval också fungera med kataloger och stdin.

Dessutom integreras Kubeval enkelt i CI-pipelines. De som vill testa innan de skickar manifest till klustret kommer att bli glada att veta att kubeval stöder tre utdataformat:

1. Vanlig text;
2. JSON;
3. Test Anything Protocol (TAP).

Och vilket av formaten kan användas för att vidarebearbeta utskriften för att skapa en sammanfattning av resultaten i önskat format.

En av nackdelarna med kubeval är att den för närvarande inte kan kontrollera mot Custom Resource Definitions (CRDs). Men kubeval kan konfigureras för att ignorera dem..

Kubeval är ett utmärkt verktyg för att kontrollera och utvärdera resurser; det bör dock understrykas att ett godkänt test inte garanterar att resursen följer bästa praxis.

Till exempel, användningen av taggen latest i containern överensstämmer inte med bästa praxis. Men kubeval anser inte att detta är ett fel och rapporterar det inte. Det vill säga att kontrollen av en sådan YAML avslutas utan varningar.

Men vad händer om du behöver utvärdera YAML och identifiera överträdelser som taggar? latest? Как проверить YAML-файл на соответствие лучшим практикам?

2. Kube-score

Kube-score analyserar YAML-manifest och utvärderar dem med inbyggda tester. Dessa tester väljs baserat på säkerhetsrekommendationer och bästa praxis, till exempel:

• Körning av containrar utan root-rättigheter.
• Närvaro av hälso kontroll av poddar.
• Ange requestar och begränsningar för resurser.

Efter testet ges tre resultat: OK, VARNING och KRITISK.

Kube-score kan testas online eller installeras lokalt.

Vid tidpunkten för skrivandet av den ursprungliga artikeln var den senaste versionen av kube-score 1.7.0.

Låt oss testa det på vårt manifest base-valid.yaml:

$ kube-score score base-valid.yaml

apps/v1/Deployment http-echo
[KRITISK] Container Image Tag
  · http-echo -> Bild med senaste taggen
      Det rekommenderas att använda en fast tagg för att undvika oavsiktliga uppgraderingar
[KRITISK] Pod NetworkPolicy
  · Podden har ingen matchande nätverkspolicy
      Skapa en NetworkPolicy som riktar sig till denna podd
[KRITISK] Pod Probes
  · Containern saknar en readinessProbe
      En readinessProbe bör användas för att indikera när tjänsten är redo att ta emot trafik.
      Utan den riskerar podden att ta emot trafik innan den har startat. Den används också under
      uppgraderingar och kan förhindra driftstopp om en ny version av applikationen misslyckas.
      Mer information: https://github.com/zegl/kube-score/blob/master/README_PROBES.md
[KRITISK] Container Security Context
  · http-echo -> Containern har inget konfigurerat säkerhetskontext
      Ange securityContext för att köra containern i en mer säker kontext.
[KRITISK] Container Resources
  · http-echo -> CPU-begränsning är inte angiven
      Resursbegränsningar rekommenderas för att undvika resurs-DDoS. Ange resources.limits.cpu
  · http-echo -> Minnebegränsning är inte angiven
      Resursbegränsningar rekommenderas för att undvika resurs-DDoS. Ange resources.limits.memory
  · http-echo -> CPU-request är inte angiven
      Resursförfrågningar rekommenderas för att säkerställa att applikationen kan starta och köra utan
      krasch. Ange resources.requests.cpu
  · http-echo -> Minne-request är inte angiven
      Resursförfrågningar rekommenderas för att säkerställa att applikationen kan starta och köra utan krasch.
      Ange resources.requests.memory
[KRITISK] Deployment har PodDisruptionBudget
  · Ingen matchande PodDisruptionBudget hittades
      Det rekommenderas att definiera en PodDisruptionBudget för att undvika oväntad driftstopp under Kubernetes
      underhållsåtgärder, såsom när en nod urladdas.
[VARNING] Deployment har host PodAntiAffinity
  · Deployment har inte en host podAntiAffinity angiven
      Det rekommenderas att ange en podAntiAffinity som förhindrar att flera poddar från en deployment
      schemaläggs på samma nod. Detta ökar tillgängligheten om noden blir otillgänglig.

YAML passerar kubeval-kontroller, medan kube-score påpekar följande brister:

• Inga ready checks är konfigurerade.
• Det saknas förfrågningar och begränsningar för CPU- och minnesresurser.
• Det finns inga definierade Pod disruption budgets.
• Det finns inga regler för separat existens. (anti-affinity) för att maximera tillgängligheten.
• Containern körs som root.

Detta är rimliga kommentarer om brister som bör åtgärdas för att göra Deployment mer effektiv och pålitlig.

Team kube-score visar information på ett läsbart sätt med alla typer av överträdelser inkluderade VARNING och KRITISK, vilket är mycket hjälpsamt under utvecklingen.

De som vill använda detta verktyg i CI-pipelinen kan aktivera en mer komprimerad utdata med hjälp av flaggan --output-format ci (i det här fallet visas också tester med resultat 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-gräns är inte angiven
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Minnegräns är inte angiven
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) CPU-begäran är inte angiven
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Minnebegäran är inte angiven
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Bild med senaste taggen
[OK] http-echo apps/v1/Deployment
[CRITICAL] http-echo apps/v1/Deployment: Podden har ingen matchande nätverkspolicy
[CRITICAL] http-echo apps/v1/Deployment: Containern saknar en readinessProbe
[CRITICAL] http-echo apps/v1/Deployment: (http-echo) Containern har ingen konfigurerad säkerhetskontext
[CRITICAL] http-echo apps/v1/Deployment: Ingen matchande PodDisruptionBudget hittades
[WARNING] http-echo apps/v1/Deployment: Deployment har inte en host podAntiAffinity inställd
[OK] http-echo v1/Service
[OK] http-echo v1/Service
[OK] http-echo v1/Service
[OK] http-echo v1/Service

I likhet med kubeval returnerar kube-score en icke-noll exitkod när det finns ett test som misslyckas KRITISK. Liknande behandling kan också aktiveras för VARNING.

Dessutom finns det möjlighet att kontrollera resurser mot olika versioner av API (precis som i kubeval). Men denna information är 'hardcode' i kube-score: det går inte att välja en annan version av Kubernetes. En sådan begränsning kan bli ett stort problem om du planerar att uppgradera klustret eller om du har flera kluster med olika versioner av K8s.

Observera att det finns redan en issue med förslaget att implementera denna funktion.

Mer information om kube-score kan fås på den officiella webbplatsen.

Kube-scores tester är ett utmärkt verktyg för att införa bästa praxis, men vad händer om du behöver göra ändringar i testet eller lägga till egna regler? Tyvärr går inte det.

Kube-score är inte utbyggbart: det går inte att lägga till eller anpassa policies.

Om det behövs att skriva egna tester för att kontrollera överensstämmelse med företagets antagna policies kan du använda något av följande fyra verktyg: config-lint, copper, conftest eller polaris.

3. Config-lint

Config-lint är ett verktyg för validering av konfigurationsfiler i YAML-, JSON-, Terraform-, CSV-format och Kubernetes-manifest.

Det kan installeras genom instruktionerna på projektets webbplats.

Den aktuella versionen vid tidpunkten för skrivandet av den ursprungliga artikeln är 1.5.0.

Config-lint innehåller inte inbyggda tester för att kontrollera Kubernetes-manifest.

För att utföra några tester behövs specifika regler. Dessa skrivs i YAML-filer, kallade "regelset" (rulesets), och har följande struktur:

version: 1
description: Regler för Kubernetes-specfiler
type: Kubernetes
files:
  - "*.yaml"
rules:
   # lista över regler

(rule.yaml)

Låt oss titta närmare på den:

• Fältet typ anger vilken typ av konfiguration som config-lint kommer att använda. För K8s-manifest är det alltid Kubernetes.
• I fältet filer förutom själva filerna kan en katalog anges.
• Fältet rules är avsett för att ange användartester.

Anta att du vill försäkra dig om att bilderna i deployment alltid laddas ner från ett betrodat register som my-company.com/myapp:1.0. Reglen för config-lint som utför en sådan kontroll skulle se ut som följer:

- id: MY_DEPLOYMENT_IMAGE_TAG
  severity: FAILURE
  message: Deployment måste använda en giltig bildtagg
  resource: Deployment
  assertions:
    - every:
        key: spec.template.spec.containers
        expressions:
          - key: image
            op: starts-with
            value: "my-company.com/"

(rule-trusted-repo.yaml)

För varje regel måste följande attribut anges:

• id — en unik identifierare för regeln;
• severity — kan vara FAILURE, VARNING och NON_COMPLIANT;
• meddelande — vid regelfel visas innehållet i denna rad;
• resource — typen av resurs som regeln tillämpas på;
• assertions — en lista över villkor som ska utvärderas för denna resurs.

I regeln ovan assertion som kallas every kontrollerar att alla containrar i deployment (key: spec.templates.spec.containers) använder betrodda bilder (d.v.s. som börjar med my-company.com/).

Det fullständiga regelsetet ser ut så här:

version: 1
description: Regler för Kubernetes-specfiler
type: Kubernetes
files:
  - "*.yaml"
rules:

 - id: DEPLOYMENT_IMAGE_REPOSITORY # !!!
    severity: FAILURE
    message: Deployment måste använda ett giltigt bildregister
    resource: Deployment
    assertions:
      - every:
          key: spec.template.spec.containers
          expressions:
            - key: image
              op: starts-with
              value: "my-company.com/"

(ruleset.yaml)

För att testa regeln, låt oss spara den som check_image_repo.yaml. Låt oss köra kontrollen på filen. base-valid.yaml:

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

[
  {
  "AssertionMessage": "Varje uttryck misslyckas: Och uttrycket misslyckas: bilden börjar inte med 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 måste använda ett giltigt bildförråd",
  "Status": "FAILURE"
  }
]

Kontrollen misslyckades. Låt oss nu kontrollera nästa manifest med ett korrekt bildförråd:

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)

Vi kör samma test med det ovanstående manifestet. Inga problem upptäckta:

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

Config-lint är ett lovande ramverk som gör det möjligt att skapa egna tester för att validera YAML-manifester i Kubernetes med YAML DSL.

Men vad gör man om mer komplex logik och tester behövs? Är inte YAML:s möjligheter för begränsade för detta? Tänk om man kunde skapa tester på ett fullt programmeringsspråk?

4. Copper

Copper V2 är ett ramverk för validering av manifester med hjälp av användardefinierade tester (liknande config-lint).

Dock skiljer det sig från det senaste genom att det inte använder YAML för att beskriva tester. Istället kan tester skapas i JavaScript. Copper tillhandahåller ett bibliotek med flera grundläggande verktyg, som hjälper till att läsa information om Kubernetes-objekt och rapportera fel.

Stegen för att installera Copper kan hittas i den officiella dokumentationen.

2.0.1 — den senaste versionen av detta verktyg vid tidpunkten för skrivandet av den ursprungliga artikeln.

Precis som config-lint har Copper inga inbyggda tester. Låt oss skriva ett. Låt det kontrollera att deployment använder containermagasin endast från betrodda förråd såsom my-company.com.

Skapa en fil check_image_repo.js med följande innehåll:

$$.forEach(function($){
    if ($.kind === 'Deployment') {
        $.spec.template.spec.containers.forEach(function(container) {
            var image = new DockerImage(container.image);
            if (image.registry.lastIndexOf('my-company.com/') != 0) {
                errors.add_error('no_company_repo',"Bild " + $.metadata.name + " är inte från my-company.com förråd", 1)
            }
        });
    }
});

Nu, för att kontrollera vårt manifest base-valid.yaml, använd kommandot copper validate:

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

Kontroll av no_company_repo misslyckades med allvarlighetsgrad 1 eftersom bilden http-echo inte kommer från my-company.com förråd
Valideringen misslyckades

Det är klart att man med Copper kan genomföra mer komplexa tester – till exempel kontrollera domännamn i Ingress-mani-fester eller avvisa pods som körs i privilegierat läge.

Copper har inbyggda olika tjänstefunktioner:

• DockerImage läser den angivna ingångsfilen och skapar ett objekt med följande attribut:
  • name — bildnamn,
  • tag — bildtagg,
  • registry — bildregister,
  • registry_url — protokoll (https://) och bildregister,
  • fqin — fullständig plats för bilden.
• Funktionen findByName hjälper till att hitta en resurs efter angiven typ (typ) och namn (name) från ingångsfilen.
• Funktionen findByLabels hjälper till att hitta en resurs efter angiven typ (typ) och etiketter (labels).

Alla tillgängliga tjänstefunktioner kan ses här.

Som standard laddar den hela den ingångna YAML-filen till en variabel $$ och gör den tillgänglig för skript (en bekant metod för dem som har erfarenhet av jQuery).

Den stora fördelen med Copper är uppenbar: du behöver inte lära dig ett specialiserat språk och kan använda olika JavaScript-möjligheter för att skapa egna tester, såsom stränginterpolation, funktioner osv.

Det bör också noteras att den nuvarande versionen av Copper arbetar med version ES5 av JavaScript-motorn, inte med ES6.

Detaljer finns tillgängliga på det officiella projektets webbplats.

Men om du inte är särskilt förtjust i JavaScript och föredrar ett språk speciellt utformat för att skapa förfrågningar och beskriva policyer, bör du titta på conftest.

5. Conftest

Conftest är ett ramverk för att kontrollera konfigurationsdata. Det passar även för testning/verifiering av Kubernetes-manifest. Tester beskriver med ett specialiserat frågespråk Rego.

Du kan installera conftest med hjälp av instruktionerna, som anges på projektets webbplats.

Vid skrivandet av den ursprungliga artikeln var den senaste tillgängliga versionen 0.18.2.

På samma sätt som config-lint och copper, kommer conftest utan några inbyggda tester. Låt oss prova det och skriva vår egen policy. Som i de tidigare exemplen kommer vi att kontrollera om containerbilder tas från en pålitlig källa.

Skapa en katalog conftest-checks, och i den – en fil med namnet check_image_registry.rego med följande innehåll:

package main

deny[msg] {

  input.kind == "Deployment"
  image := input.spec.template.spec.containers[_].image
  not startswith(image, "my-company.com/")
  msg := sprintf("image '%v' doesn't come from my-company.com repository", [image])
}

Nu låt oss testa base-valid.yaml via 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

Testet misslyckades som förväntat eftersom bilderna kommer från en osäker källa.

I Rego-filen definierar vi blocket deny. Dess giltighet betraktas som ett brott. Om det finns flera block så kontrollerar conftest dem oberoende av varandra, och giltigheten av vilket block som helst tolkas som ett brott. deny Förutom standardutdata stöder conftest JSON, TAP och tabellformat — en oerhört användbar funktion om du behöver integrera rapporter i en befintlig CI-pipeline. Den önskade formatet kan anges med flaggan

--output För att underlätta felsökning av policyer erbjuder conftest en flagga.

--trace . Den visar en spårning av hur conftest tolkar de angivna policyfilerna.Conftest-policys kan publiceras och delas i OCI-register (Open Container Initiative) som artefakter.

tillåter att publicera en artefakt eller hämta en befintlig artefakt från ett fjärrregister. Låt oss försöka publicera den policy vi skapade till ett lokalt Docker-register med hjälp av

Kommandon push och pull conftest push Kör ett lokalt Docker-register:.

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

I en annan terminal, gå till den tidigare skapade katalogen

$ conftest push 127.0.0.1:5000/amitsaha/opa-bundle-example:latest conftest-checks och kör följande kommando:

Om kommandot lyckades kommer du att se ett meddelande av följande typ:

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

Skapa nu en temporär katalog och kör kommandot

conftest pull . Det kommer att ladda ner paketet som skapades av föregående kommando:$ cd $(mktemp -d) $ conftest pull 127.0.0.1:5000/amitsaha/opa-bundle-example:latest

I den temporära katalogen kommer det att finnas en undermapp

, som innehåller vår policyfil: policy$ tree . └── policy └── check_image_registry.rego

Tester kan köras direkt från lagret:

$ conftest test --update 127.0.0.1:5000/amitsaha/opa-bundle-example:latest base-valid.yaml .. FAIL - base-valid.yaml - image 'hashicorp/http-echo' kommer inte från my-company.com-repository 2 tester, 1 godkänd, 0 varningar, 1 misslyckande

Tyvärr stöds DockerHub för tillfället inte. Så betrakta det som tur om du använder

Azure Container Registry (ACR) eller din egen register. Artefakternas format är detsamma som för

paket av Open Policy Agent (OPA), vilket gör att conftest kan användas för att köra tester från befintliga OPA-paket. Mer om delning av policyer och andra funktioner i conftest kan du läsa på

6. Polaris det officiella projektets webbplats.

Det sista verktyget som kommer att tas upp i den här artikeln är

(Vi har redan översatt dess tillkännagivande från förra året. Polaris. (Его прошлогодний анонс мы уже переводили — anm. övers.)

Polaris kan installeras i en kluster eller användas i kommandoradsläge. Som du säkert redan gissat, låter den dig statiskt analysera Kubernetes-manifest.

När du arbetar i kommandoradsläge finns det inbyggda tester som täcker områden som säkerhet och bästa praxis (på samma sätt som kube-score). Dessutom kan du skapa egna tester (som config-lint, copper och conftest).

Med andra ord kombinerar Polaris fördelarna med båda kategorier av verktyg: med inbyggda och användarspecifika tester.

För att installera Polaris i kommandoradsläge, använd anvisningarna på projektets webbplats..

Vid tidpunkten för skrivandet av den ursprungliga artikeln finns version 1.0.3 tillgänglig.

När installationen är klar kan du köra polaris på manifestet base-valid.yaml med följande kommando:

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

Det kommer att ge en rad i JSON-format med en detaljerad beskrivning av de testsom genomförts och deras resultat. Utdata kommer att ha följande struktur:

{
  "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": [
    /* lång lista */
  ]
}

Den fullständiga utdata är tillgänglig. här.

Precis som kube-score identifierar Polaris problem där manifestet inte uppfyller bästa praxis:

• Det saknas hälsokontroller för pods.
• Inga taggar angivna för containerbilder.
• Containern körs som root.
• Inga begärningar och begränsningar angivna för minne och CPU.

Varje test tilldelas en kritikalitetsgrad beroende på dess resultat: warning eller danger. För att veta mer om de tillgängliga inbyggda testerna, hänvisa till dokumentationen.

Om detaljerna inte behövs kan du ange flaggan --format score. I så fall kommer Polaris att ge ett nummer i intervallet 1 till 100 — score (d.v.s. betyg):

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

Ju närmare betyget är 100, desto högre överensstämmelse. Om du kontrollerar exit-koden för kommandot polaris audit, kommer det att visa att den är 0.

För att få polaris audit att avsluta med en icke-nollkod kan du använda två flaggor:

• Flagga --set-exit-code-below-score tar ett tröskelvärde mellan 1-100 som argument. I så fall avslutas kommandot med exit-kod 4 om betyget är under tröskeln. Detta är mycket praktiskt när du har ett tröskelvärde (säg 75) och behöver få en alert om betyget sjunker under detta.
• Flagga --set-exit-code-on-danger det kommer att leda till att teamet avslutas med kod 3 om något av danger-testen misslyckas.

Låt oss nu försöka skapa ett användartest som kontrollerar om bilden hämtas från ett betrott förråd. Användartest definieras i YAML-format och själva testet beskrivs med JSON Schema.

Följande YAML-kod beskriver ett nytt test som kallas checkImageRepo:

checkImageRepo:
  successMessage: Bildförrådet är giltigt
  failureMessage: Bildförrådet är inte giltigt
  category: Bilder
  target: Container
  schema:
    '$schema': http://json-schema.org/draft-07/schema
    type: object
    properties:
      image:
        type: string
        pattern: ^my-company.com/.+$

Låt oss ta en närmare titt på det:

• successMessage — denna rad kommer att visas om testet lyckas;
• failureMessage — detta meddelande kommer att visas i händelse av ett misslyckande;
• category — anger en av kategorierna: Bilder, Hälsokontroller, Säkerhet, Nätverkande och Resurser;
• target—- anger vilken typ av objekt (spec) testet tillämpas på. Möjliga värden: Container, Pod eller Controller;
• Själva testet definieras i objektet schema med hjälp av JSON-schema. I detta test används nyckelordet mönster för att jämföra bildkällan med det som krävs.

För att köra testet ovan måste följande konfiguration av Polaris skapas:

checks:
  checkImageRepo: danger
customChecks:
  checkImageRepo:
    successMessage: Bildförrådet är giltigt
    failureMessage: Bildförrådet är inte giltigt
    category: Bilder
    target: Container
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          pattern: ^my-company.com/.+$

(polaris-conf.yaml)

Låt oss gå igenom filen:

• I fältet checks anger tester och deras kritikalitetsnivå. Eftersom det är önskvärt att få en varning när bilden hämtas från en osäker källa, sätter vi här nivån danger.
• Själva testet checkImageRepo anges sedan i objektet customChecks.

Spara filen som custom_check.yaml. Nu kan vi köra polaris audit med YAML-manifestet som kräver kontroll.

Låt oss testa vårt manifest base-valid.yaml:

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

Team polaris audit har endast genomfört det ovan nämnda användartestet, och det misslyckades.

Om bilden korrigeras till my-company.com/http-echo:1.0, kommer Polaris att avslutas framgångsrikt. Manifestet med ändringarna finns redan i förrådet, så att du kan kontrollera den föregående kommandon med manifestet. image-valid-mycompany.yaml.

Nu uppstår frågan: hur kör man inbyggda tester tillsammans med användartester? Lätt! Du behöver bara lägga till identiteterna för de inbyggda testen i konfigurationsfilen. Resultatet kommer att se ut som följande:

kontroller:
  cpuRequestsMissing: varning
  cpuLimitsMissing: varning
  # Andra inbyggda kontroller..
  # ..
  # anpassade kontroller
  checkImageRepo: fara # !!!
anpassadeKontroller:
  checkImageRepo:        # !!!
    successMessage: Bildregister är giltigt
    failureMessage: Bildregister är inte giltigt
    category: Bilder
    target: Behållare
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          pattern: ^my-company.com/.+$

(config_with_custom_check.yaml)

Exempel på en fullständig konfigurationsfil är tillgänglig här.

Kontrollera manifestet base-valid.yaml, med hjälp av inbyggda och anpassade tester kan göras med kommandot:

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

Polaris kompletterar inbyggda tester med anpassade tester och kombinerar därmed det bästa av två världar.

Å andra sidan kan avsaknaden av mer kraftfulla språk som Rego eller JavaScript bli en begränsande faktor som hindrar skapandet av mer avancerade tester.

Ytterligare information om Polaris finns tillgänglig på projektets webbplats.

Sammanfattning

Även om det finns många verktyg för att kontrollera och bedöma YAML-filer för Kubernetes, är det viktigt att ha en tydlig uppfattning om hur testerna kommer att utformas och genomföras.

Till exempel, om man tar Kubernetes-manifest som går genom pipelinen, kan kubeval bli det första steget i en sådan pipeline. Det skulle övervaka om objektd definitioner överensstämmer med Kubernetes API:s schema.

Efter att en sådan kontroll har genomförts kan man gå vidare till mer avancerade tester, såsom överensstämmelse med standardbästa praxis och specifika policyer. Här skulle kube-score och Polaris vara till nytta.

För dem med komplexa krav och behov av att finjustera tester skulle copper, config-lint och conftest vara lämpliga.

Conftest och config-lint använder YAML för att definiera anpassade tester, medan copper ger tillgång till ett fullständigt programspråk, vilket gör det till ett ganska attraktivt val.

Å andra sidan, ska man använda något av dessa verktyg och därmed skapa alla tester manuellt, eller föredra Polaris och bara skriva in vad som behövs? Det finns inget entydigt svar på denna fråga.

Tabellen nedan innehåller en kort beskrivning av varje verktyg:

Verktyget
Syftet
Nackdelar
Anpassade tester

kubeval
Kontrollerar YAML-manifesten för överensstämmelse med en viss version av API-schemat
Kan inte hantera CRD
Ingen

kube-score
Analys av YAML-manifest för överensstämmelse med bästa praxis
Det går inte att välja sin egen version av Kubernetes API att kontrollera resurser mot
Ingen

copper
Ett allmänt ramverk för att skapa egna JavaScript-tester för YAML-manifest
Inga inbyggda tester. Sparsam dokumentation
Ja

config-lint
Ett allmänt ramverk för att skapa tester i ett domänspecifikt språk som är inbyggt i YAML. Stöder olika konfigurationsformat (t.ex. Terraform)
Inga färdiga tester. Inbyggda assertions och funktioner kan vara otillräckliga
Ja

conftest
Ett ramverk för att skapa egna tester med Rego (ett specialiserat frågespråk). Möjliggör delning av policyer via OCI-bundlar
Inga inbyggda tester. Man måste lära sig Rego. Docker Hub stöds inte vid publicering av policyer
Ja

Polaris
Analyserar YAML-manifest för att säkerställa att de följer standardens bästa praxis. Möjliggör skapande av egna tester med hjälp av JSON Schema
Möjligheterna för tester baserade på JSON Schema kan vara otillräckliga
Ja

Eftersom dessa verktyg inte är beroende av åtkomst till Kubernetes-klustret, är de lätta att installera. De kan filtrera källfiler och ger snabb feedback till författare av pull requests i projekten.

P.S. från översättaren

Läs även i vår blogg:

• «Polaris har presenterats för att hålla Kubernetes-kluster i gott skick»;
• «Vim med YAML-support för Kubernetes»;
• «7 bästa praxis för containerhantering enligt Google».

Källa: habr.com