Kubernetes YAML-bekragtiging teen beste praktyke en beleide

Let wel. vertaal.: Met die groei in die aantal YAML-konfigurasies vir K8s-omgewings, word die behoefte aan outomatiese verifikasie daarvan meer en meer dringend. Die skrywer van hierdie resensie het nie net bestaande oplossings vir hierdie taak gekies nie, maar het ook gekyk na hoe dit werk deur die voorbeeld van Ontplooiing te gebruik. Dit blyk baie insiggewend te wees vir diegene wat in hierdie onderwerp belangstel.

TL; DR: Hierdie artikel vergelyk ses statiese gereedskap vir die validering en evaluering van Kubernetes YAML-lêers teen beste praktyke en vereistes.

Kubernetes-werkladings word tipies gedefinieer in die vorm van YAML-dokumente. Een van die probleme met YAML is die moeilikheid om perke of verhoudings tussen manifeslêers te stel.

Wat as ons moet seker maak dat alle beelde wat na die groepering ontplooi is, van 'n betroubare register kom?

Hoe om te verhoed dat ontplooiings na die groep gestuur word wat nie PodDisruptionBudgets gestel het nie?

Statiese toetsintegrasie laat jou toe om foute en beleidsoortredings in die ontwikkelingstadium op te spoor. Dit verhoog die versekering dat hulpbrondefinisies korrek en veilig is, en verhoog die waarskynlikheid dat produksiewerkladings beste praktyke sal volg.

Die Kubernetes YAML statiese validering-ekosisteem kan in die volgende kategorieë verdeel word:

• API Valideerders. Die gereedskap in hierdie kategorie bekragtig die YAML-manifes teen die vereistes van die Kubernetes API-bediener.
• Klaar toetsers. Gereedskap uit hierdie kategorie kom met klaargemaakte toetse vir sekuriteit, voldoening aan beste praktyke, ens.
• Pasgemaakte valideerders. Lede van hierdie kategorie laat jou toe om pasgemaakte toetse in verskeie tale te skep, soos Rego en Javascript.

In hierdie artikel sal ons ses verskillende instrumente beskryf en vergelyk:

1. kubeval;
2. kube-telling;
3. config-lint;
4. koper;
5. stryd;
6. polaris.

Wel, kom ons begin!

Gaan ontplooiings na

Voordat ons nutsmiddels begin vergelyk, kom ons skep 'n basis waarop ons dit kan toets.

Die manifes hieronder bevat 'n aantal foute en teenstrydighede met beste praktyke: hoeveel kan jy vind?

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)

Ons sal hierdie YAML gebruik om verskillende instrumente te vergelyk.

Bogenoemde manifesteer base-valid.yaml en ander manifestasies uit hierdie artikel kan gevind word in Git-bewaarplekke.

Die manifes beskryf 'n webtoepassing wie se hooftaak is om te reageer met 'n "Hello World"-boodskap op poort 5678. Dit kan met die volgende opdrag ontplooi word:

kubectl apply -f hello-world.yaml

En so - om die werk na te gaan:

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

Gaan nou na http://localhost:8080 en bevestig dat die toepassing loop. Maar volg dit beste praktyke? Kom ons kyk.

1. Kubeval

Die kern van kubeval lê die idee dat enige interaksie met Kubernetes plaasvind deur sy REST API. Met ander woorde, jy kan 'n API-skema gebruik om te kyk of 'n gegewe YAML daaraan voldoen. Kom ons kyk na 'n voorbeeld.

Instalasie instruksies kubeval is beskikbaar op die projekwebwerf.

Ten tyde van die skryf van die oorspronklike artikel was weergawe 0.15.0 beskikbaar.

Sodra dit geïnstalleer is, laat ons dit die manifes hierbo voer:

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

Indien suksesvol, sal kubeval uitgaan met 'n uitgangkode van 0. Jy kan dit soos volg nagaan:

$ echo $?
0

Kom ons probeer nou kubeval met 'n ander manifes:

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 jy die probleem raaksien? Ons begin:

$ 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

Die hulpbron is nie bekragtig nie.

Ontplooiings met behulp van die API-weergawe apps/v1, moet 'n kieser insluit wat by die peul se etiket pas. Die manifes hierbo sluit nie 'n kieser in nie, so kubeval het 'n fout aangemeld en met 'n nie-nul-kode verlaat.

Ek wonder wat gebeur as jy hardloop kubectl apply -f met hierdie manifes?

Wel, kom ons probeer:

$ 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

Presies die fout waaroor kubeval gewaarsku het. Jy kan dit regmaak deur 'n kieser by te voeg:

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)

Die voordeel van gereedskap soos kubeval is dat hierdie foute vroeg in die ontplooiingsiklus opgespoor kan word.

Daarbenewens vereis hierdie kontroles nie toegang tot die groepering nie: dit kan vanlyn uitgevoer word.

By verstek kontroleer kubeval hulpbronne teen die nuutste Kubernetes API-skema. In die meeste gevalle moet u egter teen 'n spesifieke Kubernetes-vrystelling bekragtig. Jy kan dit met die vlag doen --kubernetes-version:

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

Let daarop dat die weergawe in die formaat moet wees Major.Minor.Patch.

Vir 'n lys weergawes waarvoor verifikasie ondersteun word, verwys na JSON-skema op GitHub, wat kubeval vir validering gebruik. As jy kubeval vanlyn wil laat loop, laai die skemas af en spesifiseer hul plaaslike ligging met behulp van die vlag --schema-location.

Benewens individuele YAML-lêers, kan kubeval ook met gidse en stdin werk.

Daarbenewens integreer Kubeval maklik in die CI-pyplyn. Diegene wat toetse wil uitvoer voordat manifeste na die groep gedruk word, sal bly wees om te weet dat kubeval drie uitvoerformate ondersteun:

1. Gewone teks;
2. JSON;
3. Toets enigiets-protokol (TAP).

En enige van die formate kan gebruik word om die uitvoer verder te ontleed om 'n opsomming van die resultate van die verlangde soort te vorm.

Een van die nadele van kubeval is dat dit nie tans kyk vir Custom Resource Definitions (CRD's) nie. Kubeval kan egter gekonfigureer word ignoreer hulle.

Kubeval is 'n wonderlike hulpmiddel vir validering en evaluering van hulpbronne; dit moet egter beklemtoon word dat die slaag van die toets nie waarborg dat die hulpbron aan beste praktyke voldoen nie.

Gebruik byvoorbeeld die merker latest in 'n houer voldoen nie aan beste praktyke nie. Kubeval beskou dit egter nie as 'n fout nie en rapporteer dit nie. Dit wil sê, validering van so YAML sal sonder waarskuwing voltooi word.

Maar wat as jy YAML moet evalueer en oortredings soos die etiket moet opspoor latest? Hoe om 'n YAML-lêer te bekragtig teen beste praktyke?

2. Kube-telling

Kube-telling ontleed YAML-manifeste en evalueer dit teen ingeboude toetse. Hierdie toetse word gekies op grond van sekuriteitsaanbevelings en beste praktyke, soos:

• Begin 'n houer nie as wortel nie.
• Beskikbaarheid van peulgesondheidsondersoeke.
• Stel versoeke en limiete vir hulpbronne.

Die toets lei tot drie resultate: OK, WAARSKUWING и KRITIESE.

Kube-telling kan aanlyn probeer word of plaaslik geïnstalleer word.

Ten tyde van die skryf van die oorspronklike artikel is die nuutste weergawe van kube-score 1.7.0.

Kom ons toets dit op ons manifes 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 slaag kubeval-tjeks, terwyl kube-telling dui op die volgende tekortkominge:

• Gereedheidskontroles is nie opgestel nie.
• Daar is geen versoeke en limiete vir SVE en geheue hulpbronne nie.
• Peulontwrigtingbegrotings nie gestel nie.
• Daar is geen reëls vir afsonderlike bestaan ​​nie (anti-affiniteit) om beskikbaarheid te maksimeer.
• Die houer loop as wortel.

Al hierdie is redelike opmerkings oor tekortkominge wat aangespreek moet word sodat Ontplooiing meer doeltreffend en betroubaar kan word.

Span kube-score voer inligting uit in 'n mens-leesbare vorm, insluitend alle oortredings van die tipe WAARSKUWING и KRITIESEwat baie help tydens ontwikkeling.

Diegene wat hierdie instrument as deel van 'n CI-pyplyn wil gebruik, kan meer saamgeperste uitset met behulp van die vlag aktiveer --output-format ci (in hierdie geval word toetse met die resultaat ook vertoon 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

Soortgelyk aan kubeval, gee kube-telling 'n nie-nul uittreekode terug wanneer daar 'n toets is wat misluk. KRITIESE. Jy kan ook soortgelyke verwerking aktiveer vir WAARSKUWING.

Daarbenewens is dit moontlik om hulpbronne teen verskillende API-weergawes na te gaan (soortgelyk aan kubeval). Hierdie inligting is egter 'hardkodeer' in die kube-telling self: jy kan nie 'n ander weergawe van Kubernetes kies nie. Hierdie beperking kan 'n groot probleem word as jy van plan is om jou cluster op te gradeer of as jy verskeie clusters met verskillende weergawes van K8's het.

Let asseblief daarop dat het reeds 'n probleem met 'n voorstel om hierdie geleentheid te implementeer.

Meer inligting oor kube-telling kan gevind word by amptelike webwerf.

Kube-telling-toetse is 'n wonderlike hulpmiddel vir die implementering van beste praktyke, maar wat as jy veranderinge aan die toets moet maak of pasgemaakte reëls moet byvoeg? Helaas, dit kan nie gedoen word nie.

Kube-telling is nie uitbreibaar nie: jy kan nie beleide daarby voeg of dit aanpas nie.

As jy pasgemaakte toetse wil skryf om te kyk na maatskappybeleide, kan jy een van die volgende vier instrumente gebruik: config-lint, koper, confest of polaris.

3.Config-lint

Config-lint is 'n instrument vir die validering van YAML, JSON, Terraform, CSV-konfigurasielêers en Kubernetes-manifeste.

Jy kan dit installeer met behulp van instruksies op die projekwebwerf.

Die huidige vrystelling teen die tyd van die skryf van die oorspronklike artikel is 1.5.0.

Config-lint sluit nie ingeboude toetse in om Kubernetes-manifeste te valideer nie.

Om enige toetse uit te voer, moet jy die toepaslike reëls skep. Hulle is geskryf in YAML-lêers genaamd "reëlstelle" (reëls), en het die volgende struktuur:

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

(rule.yaml)

Kom ons bestudeer dit van naderby:

• Veld type spesifiseer watter tipe konfigurasie config-lint sal gebruik. Vir K8s manifesteer dit is altyd Kubernetes.
• In die veld files bykomend tot die lêers self, kan jy 'n gids spesifiseer.
• Veld rules is bedoel vir die opstel van gebruikerstoetse.

Kom ons sê jy wil seker maak dat beelde in 'n ontplooiing altyd afgelaai word vanaf 'n betroubare bewaarplek soos my-company.com/myapp:1.0. 'n Config-lint-reël wat hierdie kontrole doen, sal soos volg lyk:

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

Die volgende eienskappe moet vir elke reël gespesifiseer word:

• id - unieke identifiseerder van die reël;
• severity - Kan wees VERSUIM, WAARSKUWING и ONVOLDOENDE;
• message - as die reël oortree word, word die inhoud van hierdie reël vertoon;
• resource — die tipe hulpbron waarop hierdie reël van toepassing is;
• assertions - 'n lys van toestande wat met betrekking tot hierdie hulpbron geëvalueer sal word.

In die reël hierbo assertion genoem every kontroleer dat alle houers in Deployment'e (key: spec.templates.spec.containers) gebruik vertroude beelde (d.w.s. dié wat begin met my-company.com/).

Die volledige reëlstel lyk soos volg:

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)

Om die toets uit te probeer, kom ons stoor dit as check_image_repo.yaml. Kom ons kyk na die lêer 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"
  }
]

Die tjek het misluk. Kom ons kyk nou na die volgende manifes met die korrekte beeldbewaarplek:

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)

Ons doen dieselfde toets met die bogenoemde manifes. Geen probleme gevind nie:

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

Config-lint is 'n vooruitskouende raamwerk wat jou toelaat om pasgemaakte toetse te skep om Kubernetes YAML-manifeste met YAML DSL te valideer.

Maar wat as meer komplekse logika en toetse vereis word? Is YAML-vermoëns nie te klein daarvoor nie? Wat as jy toetse in 'n volwaardige programmeertaal kan skep?

4. Koper

Koper V2 is 'n raamwerk vir die validering van manifeste deur gebruik te maak van pasgemaakte toetse (soortgelyk aan config-lint).

Dit verskil egter van laasgenoemde deurdat dit nie YAML gebruik om toetse te beskryf nie. In plaas daarvan kan toetse in JavaScript geskryf word. Koper verskaf 'n biblioteek met verskeie basiese gereedskapom inligting oor Kubernetes-voorwerpe te help lees en foute aan te meld.

Die volgorde van stappe om Copper te installeer kan gevind word in amptelike dokumentasie.

2.0.1 is die nuutste weergawe van hierdie hulpprogram ten tyde van die skryf van die oorspronklike artikel.

Soos config-lint, het Copper geen ingeboude toetse nie. Kom ons skryf een. Laat hom seker maak dat implementerings houerbeelde uitsluitlik van betroubare bewaarplekke soos my-company.com.

Skep 'n lêer check_image_repo.js met die volgende inhoud:

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

Nou om ons manifes te toets base-valid.yaml, gebruik die opdrag 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

Dit is duidelik dat meer komplekse toetse met koper uitgevoer kan word - byvoorbeeld die kontrolering van domeinname in Ingress-manifeste of die verwerping van peule wat in bevoorregte modus loop.

Verskeie nutsfunksies is in Copper ingebou:

• DockerImage lees die gespesifiseerde invoerlêer en skep 'n voorwerp met die volgende eienskappe:
  • name - naam van die beeld,
  • tag - beeld tag,
  • registry - beeld register
  • registry_url - protokol (https://) en 'n beeldregister,
  • fqin — die volledige ligging van die prent.
• Funksie findByName help om 'n hulpbron volgens 'n gegewe tipe te vind (kind) en naam (name) vanaf die invoerlêer.
• Funksie findByLabels help om 'n hulpbron volgens die gespesifiseerde tipe te vind (kind) en etikette (labels).

Alle beskikbare nutsfunksies kan gevind word hier.

By verstek laai dit die hele YAML-invoerlêer in 'n veranderlike $$ en maak dit beskikbaar vir skrifte ('n bekende tegniek vir diegene met jQuery-ervaring).

Die grootste voordeel van Copper is voor die hand liggend: jy hoef nie 'n gespesialiseerde taal aan te leer nie en jy kan verskeie JavaScript-kenmerke gebruik om jou eie toetse te skep, soos stringinterpolasie, funksies, ens.

Daar moet ook op gelet word dat die huidige weergawe van Copper met die ES5-weergawe van die JavaScript-enjin werk, nie ES6 nie.

Besonderhede is beskikbaar by amptelike webwerf van die projek.

As jy egter nie 'n groot aanhanger van JavaScript is nie en 'n taal verkies wat spesifiek vir navrae en beleide beskryf word, moet jy die stryd ondersoek.

5. Wedstryd

Confetest is 'n raamwerk om konfigurasiedata na te gaan. Ook geskik om Kubernetes-manifeste te toets/verifieer. Toetse word beskryf deur 'n gespesialiseerde navraagtaal te gebruik Rego.

Jy kan conftest installeer met instruksiesop die projekwebwerf gelys.

Ten tyde van die skryf van die oorspronklike artikel is die nuutste weergawe beskikbaar 0.18.2.

Soortgelyk aan config-lint en koper, kom confetest sonder enige ingeboude toetse. Kom ons probeer dit en skryf ons eie beleid. Soos in die vorige voorbeelde, sal ons kyk of die houerbeelde van 'n betroubare bron geneem is.

Skep 'n gids conftest-checks, en daarin - 'n lêer met die naam check_image_registry.rego met die volgende inhoud:

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

Kom ons toets nou base-valid.yaml deur 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

Die toets het soos verwag misluk omdat die beelde van 'n onbetroubare bron afkomstig is.

In die Rego-lêer definieer ons 'n blok deny. Die waarheid daarvan word as 'n oortreding beskou. As blokke deny veelvuldige, confetest kontroleer hulle onafhanklik, en die waarheid van enige van die blokke word as 'n oortreding hanteer.

Benewens die verstekafvoer, ondersteun conftest JSON-, TAP- en tabelformaat - 'n baie nuttige kenmerk as jy verslae in 'n bestaande CI-pyplyn moet insluit. Jy kan die verlangde formaat met die vlag instel --output.

Om beleidontfouting te vergemaklik, het confetest 'n vlag --trace. Dit druk 'n spoor van hoe conftest die gespesifiseerde beleidlêers ontleed.

strydbeleide kan gepubliseer en gedeel word in OCI (Open Container Initiative) registers as artefakte.

Команды push и pull laat jou toe om 'n artefak te publiseer of 'n bestaande artefak uit 'n afgeleë register te haal. Kom ons probeer om die beleid wat ons geskep het na die plaaslike Docker-register te publiseer conftest push.

Begin plaaslike Docker-register:

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

In 'n ander terminale, gaan na die gids wat jy vroeër geskep het conftest-checks en voer die volgende opdrag uit:

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

As die opdrag suksesvol was, sal jy 'n boodskap soos hierdie sien:

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

Skep nou 'n tydelike gids en voer die opdrag daarin uit conftest pull. Dit sal die pakket wat deur die vorige opdrag geskep is, daarin aflaai:

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

'n Subgids sal in die tydelike gids verskyn policy, wat ons beleidlêer bevat:

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

Toetse kan direk vanaf die bewaarplek uitgevoer word:

$ 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

Ongelukkig word DockerHub nog nie ondersteun nie. So ag jouself gelukkig as jy gebruik Azure Container Registry (ACR) of jou eie register.

Artefakformaat is dieselfde as Maak Polisagent-pakkette oop (OPA), wat jou toelaat om confetest te gebruik om toetse uit bestaande OPA-pakkette uit te voer.

Jy kan meer te wete kom oor beleidsdeling en ander kompetisiekenmerke by amptelike webwerf van die projek.

6 Polaris

Die laaste hulpmiddel wat in hierdie artikel bespreek sal word, is Polaris. (Sy verlede jaar se aankondiging het ons reeds vertaal - ongeveer. vertaal.)

Polaris kan in 'n groep geïnstalleer word of in opdragreëlmodus gebruik word. Soos jy dalk geraai het, laat dit jou toe om Kubernetes-manifeste staties te ontleed.

Wanneer in die opdragreëlmodus uitgevoer word, is ingeboude toetse beskikbaar wat gebiede soos sekuriteit en beste praktyke dek (soortgelyk aan kube-telling). Daarbenewens kan jy jou eie toetse skep (soos in config-lint, koper en confest).

Met ander woorde, Polaris kombineer die voordele van beide kategorieë gereedskap: met ingeboude en pasgemaakte toetse.

Om Polaris in opdragreëlmodus te installeer, gebruik instruksies op die projekwebwerf.

Ten tyde van die skryf van die oorspronklike artikel is weergawe 1.0.3 beskikbaar.

Nadat die installasie voltooi is, kan jy polaris op die manifes laat loop base-valid.yaml met die volgende opdrag:

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

Dit sal 'n JSON-string uitvoer wat die toetse wat uitgevoer is en hul resultate uiteensit. Die uitset sal die volgende struktuur hê:

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

Volledige onttrekking beskikbaar hier.

Soos kube-telling, identifiseer Polaris kwessies waar die manifes nie beste praktyke volg nie:

• Peulgesondheidsondersoeke ontbreek.
• Geen merkers gespesifiseer vir houerprente nie.
• Die houer loop as wortel.
• Request'y en limit'y vir geheue en SVE word nie gespesifiseer nie.

Elke toets, afhangende van sy resultate, word 'n mate van kritiek toegeken: waarskuwing of gevaar. Om meer te wete te kom oor die beskikbare ingeboude toetse, verwys na dokumentasie.

As besonderhede nie nodig is nie, kan jy 'n vlag spesifiseer --format score. In hierdie geval sal Polaris 'n getal in die reeks van 1 tot 100 - uitvoer telling (d.w.s. evaluering):

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

Hoe nader die telling aan 100 is, hoe hoër is die mate van voldoening. As jy die uitgangkode van die opdrag nagaan polaris audit, dit blyk dat dit gelyk is aan 0.

krag polaris audit Jy kan verlaat met 'n nie-nul kode deur twee vlae te gebruik:

• vlag --set-exit-code-below-score neem as 'n argument 'n drempelwaarde in die reeks 1-100. In hierdie geval sal die opdrag eindig met 'n uittreekode van 4 as die telling onder die drempel is. Dit is baie handig wanneer jy 'n sekere drempelwaarde het (sê 75) en jy wil gewaarsku word as die telling onder daal.
• vlag --set-exit-code-on-danger sal veroorsaak dat die opdrag met kode 3 uitgaan as een van die gevaartoetse misluk.

Kom ons probeer nou om 'n pasgemaakte toets te skep wat kyk of die prent uit 'n betroubare bewaarplek geneem is. Gebruikerstoetse word in YAML-formaat gespesifiseer, en die toets self word beskryf met behulp van JSON-skema.

Die volgende YAML-brokkie beskryf 'n nuwe toets genaamd 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/.+$

Kom ons kyk nader daarna:

• successMessage - hierdie reël sal vertoon word as die toets suksesvol voltooi is;
• failureMessage - hierdie boodskap sal gewys word in geval van mislukking;
• category - dui een van die kategorieë aan: Images, Health Checks, Security, Networking и Resources;
• target--- definieer watter tipe voorwerp (spec) word die toets toegepas. Moontlike waardes: Container, Pod of Controller;
• Die toets self word in die voorwerp gespesifiseer schema met behulp van JSON-skema. In hierdie toets word die sleutelwoord pattern gebruik om die beeldbron met die gewenste een te vergelyk.

Om die bogenoemde toets uit te voer, moet jy die volgende Polaris-konfigurasie skep:

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)

Kom ons ontleed die lêer:

• In die veld checks toetse en hul vlak van kritiek word voorgeskryf. Aangesien dit wenslik is om gewaarsku te word wanneer 'n beeld van 'n onbetroubare bron geneem word, stel ons die vlak hier danger.
• Die toets self checkImageRepo dan aan die voorwerp toegewys customChecks.

Stoor die lêer as custom_check.yaml. Nou kan jy hardloop polaris audit met 'n YAML-manifes wat bekragtiging vereis.

Toets ons manifes base-valid.yaml:

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

Span polaris audit het net die pasgemaakte toets hierbo gegee en dit het misluk.

As jy die beeld regmaak na my-company.com/http-echo:1.0, sal Polaris suksesvol voltooi. Manifes met veranderinge is reeds in bewaarplekkesodat jy die vorige opdrag op die manifes kan nagaan image-valid-mycompany.yaml.

Nou ontstaan ​​die vraag: hoe om ingeboude toetse saam met pasgemaakte toetse uit te voer? Maklik! U hoef net die ingeboude toets-ID's by die konfigurasielêer te voeg. As gevolg hiervan sal dit die volgende vorm aanneem:

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)

'n Voorbeeld van 'n volledige konfigurasielêer is beskikbaar hier.

Gaan Manifes na base-valid.yaml, met behulp van ingeboude en pasgemaakte toetse, kan jy die opdrag gebruik:

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

Polaris vul die ingeboude toetse aan met pasgemaakte toetse en kombineer sodoende die beste van albei wêrelde.

Aan die ander kant kan die onvermoë om kragtiger tale soos Rego of JavaScript te gebruik 'n beperkende faktor wees wat jou verhoed om meer gesofistikeerde toetse te skep.

Meer inligting oor Polaris is beskikbaar by projek webwerf.

Opsomming

Alhoewel daar baie instrumente is om Kubernetes YAML-lêers te valideer en te evalueer, dit is belangrik om 'n duidelike begrip te hê van hoe toetse ontwerp en uitgevoer sal word.

Byvoorbeeld, as jy Kubernetes-manifeste neem wat deur 'n pyplyn gaan, kan kubeval die eerste stap in so 'n pyplyn wees. Dit sal seker maak dat die objekdefinisies ooreenstem met die Kubernetes API-skema.

Sodra so 'n hersiening voltooi is, kan meer gesofistikeerde toetse voortgesit word, soos voldoening aan standaard beste praktyke en spesifieke beleide. Dit is waar kube-score en Polaris handig te pas sal kom.

Vir diegene wat komplekse vereistes het en hul toetse moet verfyn, sal koper, config-lint en confetest wonderlik wees..

Conftest en config-lint gebruik YAML om pasgemaakte toetse te definieer, terwyl koper jou toegang gee tot 'n volledige programmeertaal, wat dit 'n redelik aantreklike keuse maak.

Aan die ander kant, moet jy een van hierdie instrumente gebruik en dus al die toetse met die hand skep, of Polaris verkies, en net wat nodig is daarby voeg? Daar is geen enkele antwoord op hierdie vraag nie.

Die tabel hieronder bevat 'n kort beskrywing van elke instrument:

Tool
lot
Beperkings
Gebruikerstoetse

kubeval
Valideer YAML-manifeste teen 'n spesifieke API-skemaweergawe
Weet nie hoe om met CRD te werk nie
Geen

kube telling
Ontleed YAML manifesteer teen beste praktyke
Jy kan nie jou weergawe van die Kubernetes API vir hulpbronvalidering kies nie
Geen

koper
Generiese raamwerk vir die skep van pasgemaakte JavaScript-toetse vir YAML-manifeste
Daar is geen ingeboude toetse nie. Skaars dokumentasie
Ja

config-lint
Algemene raamwerk vir die skep van toetse in 'n domeinspesifieke taal wat in YAML ingebed is. Ondersteun verskeie konfigurasieformate (bv. Terraform)
Daar is geen klaargemaakte toetse nie. Ingeboude bewerings en funksies is dalk nie genoeg nie
Ja

stryd
'n Raamwerk vir die skep van jou eie toetse in Rego ('n gespesialiseerde navraagtaal). Laat beleiddeling via OCI-bundels toe
Daar is geen ingeboude toetse nie. Jy moet Rego leer. Docker Hub word nie ondersteun wanneer beleide gepubliseer word nie
Ja

Polaris
Ontleed YAML manifesteer teen standaard beste praktyke. Laat jou toe om jou eie toetse te skep deur JSON-skema te gebruik
JSON Skema-gebaseerde toetsvermoëns is dalk nie genoeg nie
Ja

Aangesien hierdie gereedskap nie afhanklik is van toegang tot die Kubernetes-kluster nie, is dit maklik om te installeer. Hulle laat jou toe om bronlêers te filtreer en gee vinnige terugvoer om versoekouteurs op projekte te trek.

PS van vertaler

Lees ook op ons blog:

• «Polaris bekendgestel om Kubernetes-trosse gesond te hou»;
• «Vim met YAML-ondersteuning vir Kubernetes»;
• «Google se 7 Container Beste Praktyke".

Bron: will.com