Staðfestu Kubernetes YAML gegn bestu starfsvenjum og stefnum

Athugið. þýð.: Með vaxandi fjölda YAML stillinga fyrir K8s umhverfi, verður þörfin fyrir sjálfvirka sannprófun þeirra meira og meira aðkallandi. Höfundur þessarar yfirferðar valdi ekki aðeins núverandi lausnir fyrir þetta verkefni heldur notaði dreifingu sem dæmi til að sjá hvernig þær virka. Það reyndist mjög fróðlegt fyrir þá sem hafa áhuga á þessu efni.

TL; DR: Þessi grein ber saman sex kyrrstæð verkfæri til að sannreyna og meta Kubernetes YAML skrár miðað við bestu starfsvenjur og kröfur.

Kubernetes vinnuálag er venjulega skilgreint í formi YAML skjala. Eitt af vandamálunum við YAML er erfiðleikarnir við að tilgreina takmarkanir eða tengsl milli upplýsingaskráa.

Hvað ef við þurfum að ganga úr skugga um að allar myndir sem sendar eru til þyrpingarinnar komi frá traustri skráningu?

Hvernig get ég komið í veg fyrir að dreifingar sem ekki eru með PodDisruptionBudgets séu sendar í þyrpinguna?

Samþætting kyrrstöðuprófa gerir þér kleift að bera kennsl á villur og stefnubrot á þróunarstigi. Þetta eykur trygginguna fyrir því að auðlindaskilgreiningar séu réttar og öruggar og gerir það líklegra að framleiðsluvinnuálag fylgi bestu starfsvenjum.

Kubernetes kyrrstöðu YAML skráarskoðunarvistkerfi má skipta í eftirfarandi flokka:

• API staðfestingaraðilar. Verkfæri í þessum flokki athuga YAML upplýsingaskrána í samræmi við kröfur Kubernetes API netþjónsins.
• Tilbúnir prófunaraðilar. Verkfæri úr þessum flokki koma með tilbúnum prófum fyrir öryggi, samræmi við bestu starfsvenjur o.fl.
• Sérsniðnir sannprófunaraðilar. Fulltrúar þessa flokks leyfa þér að búa til sérsniðin próf á ýmsum tungumálum, til dæmis Rego og Javascript.

Í þessari grein munum við lýsa og bera saman sex mismunandi verkfæri:

1. kubeval;
2. kúbe-stig;
3. config-lint;
4. kopar;
5. keppni;
6. polaris.

Jæja, við skulum byrja!

Athugar dreifingar

Áður en við byrjum að bera saman verkfæri skulum við búa til bakgrunn til að prófa þau á.

Í stefnuskránni hér að neðan eru nokkrar villur og ekki farið eftir bestu starfsvenjum: hversu margar þeirra geturðu fundið?

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ð munum nota þetta YAML til að bera saman mismunandi verkfæri.

Ofangreind stefnuskrá base-valid.yaml og önnur stefnuskrá úr þessari grein er að finna í Git geymslur.

Upplýsingaskráin lýsir vefforriti sem hefur það að meginverkefni að svara með „Halló heimur“ skilaboðum á port 5678. Það er hægt að nota með eftirfarandi skipun:

kubectl apply -f hello-world.yaml

Og svo - athugaðu verkið:

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

Farðu nú til http://localhost:8080 og staðfesta að forritið virki. En fylgir það bestu starfsvenjum? Við skulum athuga.

1. Kubeval

Í hjarta kubeval Hugmyndin er sú að öll samskipti við Kubernetes eigi sér stað í gegnum REST API þess. Með öðrum orðum, þú getur notað API skema til að athuga hvort tiltekið YAML samræmist því. Við skulum skoða dæmi.

Uppsetningarleiðbeiningar kubeval eru aðgengileg á heimasíðu verkefnisins.

Þegar upphaflega greinin var skrifuð var útgáfa 0.15.0 tiltæk.

Þegar það hefur verið sett upp, skulum við gefa því upplýsingarnar hér að ofan:

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

Ef vel tekst til mun kubeval hætta með útgöngukóða 0. Þú getur athugað það á eftirfarandi hátt:

$ echo $?
0

Við skulum nú reyna kubeval með annarri upplýsingaskrá:

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)

Geturðu séð vandamálið með auga? Við skulum ræsa:

$ 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

Ekki er verið að sannreyna auðlindina.

Dreifing með API útgáfu apps/v1, verður að innihalda val sem passar við merki belgsins. Upplýsingaskráin hér að ofan inniheldur ekki val, svo kubeval tilkynnti um villu og hætti með kóða sem ekki er núll.

Ég velti því fyrir mér hvað gerist ef ég geri það kubectl apply -f með þessari stefnuskrá?

Jæja, við skulum reyna:

$ 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

Þetta er einmitt villa sem kubeval varaði við. Þú getur lagað það með því að bæta við vali:

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)

Ávinningurinn af verkfærum eins og kubeval er að villur eins og þessar geta gripist snemma í dreifingarferlinu.

Að auki krefjast þessar athuganir ekki aðgang að þyrpingunni; þær geta verið framkvæmdar án nettengingar.

Sjálfgefið er að kubeval athugar tilföng í samræmi við nýjasta Kubernetes API skema. Hins vegar gætir þú í flestum tilfellum þurft að athuga með tiltekna Kubernetes útgáfu. Þetta er hægt að gera með því að nota fána --kubernetes-version:

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

Vinsamlegast athugið að útgáfan verður að vera tilgreind í sniðinu Major.Minor.Patch.

Fyrir lista yfir útgáfur sem staðfesting er studd fyrir, vinsamlegast vísa til JSON skema á GitHub, sem kubeval notar til staðfestingar. Ef þú þarft að keyra kubeval án nettengingar skaltu hlaða niður skemanum og tilgreina staðbundna staðsetningu þeirra með því að nota fánann --schema-location.

Auk einstakra YAML skráa getur kubeval einnig unnið með möppur og stdin.

Að auki fellur Kubeval auðveldlega inn í CI leiðsluna. Þeir sem vilja keyra próf áður en þeir senda upplýsingaskrá í þyrpinguna munu vera ánægðir að vita að kubeval styður þrjú úttakssnið:

1. Einfaldur texti;
2. JSON;
3. Test Anything Protocol (TAP).

Og hvaða snið sem er er hægt að nota til frekari þáttunar á úttakinu til að búa til samantekt á niðurstöðum viðkomandi tegundar.

Einn af göllunum við kubeval er að það getur nú ekki athugað hvort farið sé að sérsniðnum auðlindaskilgreiningum (CRD). Hins vegar er hægt að stilla kubeval hunsa þá.

Kubeval er frábært tæki til að athuga og meta auðlindir; Hins vegar skal áréttað að það að standast prófið tryggir ekki að auðlindin uppfylli bestu starfsvenjur.

Til dæmis með því að nota merkið latest í gámi fylgir ekki bestu starfsvenjum. Kubeval telur þetta þó ekki villu og tilkynnir það ekki. Það er, sannprófun slíkrar YAML mun ljúka án viðvarana.

En hvað ef þú vilt meta YAML og bera kennsl á brot eins og merkið latest? Hvernig athuga ég YAML skrá með bestu starfsvenjum?

2. Kube-stig

Kube-stig greinir YAML birtingarmyndir og metur þær gegn innbyggðum prófum. Þessi próf eru valin út frá öryggisleiðbeiningum og bestu starfsvenjum, svo sem:

• Að keyra ílátið ekki sem rót.
• Framboð á heilsuprófum á belg.
• Að setja beiðnir og takmarkanir fyrir tilföng.

Byggt á niðurstöðum prófsins eru þrjár niðurstöður gefnar: OK, VIÐVÖRUN и Gagnrýnin.

Þú getur prófað Kube-score á netinu eða sett það upp á staðnum.

Þegar upphaflega greinin var skrifuð var nýjasta útgáfan af kube-score 1.7.0.

Við skulum prófa það á stefnuskránni okkar 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 stenst kubeval próf, en kube-skor bendir á eftirfarandi galla:

• Viðbúnaðarathuganir eru ekki stilltar.
• Það eru engar beiðnir eða takmarkanir fyrir CPU auðlindir og minni.
• Fjárhagsáætlanir fyrir truflun á belg eru ekki tilgreindar.
• Það eru engar reglur um aðskilnað (andstæðingur) til að hámarka framboð.
• Ílátið rekur sem rót.

Þetta eru allt gild atriði um galla sem þarf að taka á til að gera uppsetningu skilvirkari og áreiðanlegri.

Team kube-score sýnir upplýsingar í læsilegu formi, þar með talið öll tegundarbrot VIÐVÖRUN и Gagnrýnin, sem hjálpar mikið við þróun.

Þeir sem vilja nota þetta tól innan CI leiðslunnar geta virkjað meira þjappað úttak með því að nota fánann --output-format ci (í þessu tilviki birtast einnig próf með niðurstöðunni 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

Svipað og kubeval, kube-score skilar útgöngukóða sem er ekki núll þegar það er próf sem mistakast Gagnrýnin. Þú getur líka virkjað svipaða vinnslu fyrir VIÐVÖRUN.

Að auki er hægt að athuga auðlindir fyrir samræmi við mismunandi API útgáfur (eins og í kubeval). Hins vegar eru þessar upplýsingar harðkóðaðar í kube-skorinu sjálfu: þú getur ekki valið aðra útgáfu af Kubernetes. Þessi takmörkun getur verið mikið vandamál ef þú ætlar að uppfæra klasann þinn eða ef þú ert með marga klasa með mismunandi útgáfum af K8s.

takið eftir því það er nú þegar mál með tillögu um að nýta þetta tækifæri.

Frekari upplýsingar um kube-score má finna á opinber vefsíða.

Kube-stigapróf eru frábært tæki til að innleiða bestu starfsvenjur, en hvað ef þú þarft að gera breytingar á prófinu eða bæta við þínum eigin reglum? Því miður, þetta er ekki hægt að gera.

Kube-stig er ekki hægt að stækka: þú getur ekki bætt stefnum við það eða breytt þeim.

Ef þú þarft að skrifa sérsniðin próf til að sannreyna samræmi við reglur fyrirtækisins geturðu notað eitt af eftirfarandi fjórum verkfærum: config-lint, kopar, conftest eða polaris.

3.Config-lint

Config-lint er tól til að staðfesta YAML, JSON, Terraform, CSV stillingarskrár og Kubernetes upplýsingaskrár.

Þú getur sett það upp með því að nota leiðbeiningar á heimasíðu verkefnisins.

Núverandi útgáfa þegar upphaflega greinin er skrifuð er 1.5.0.

Config-lint er ekki með innbyggð próf til að staðfesta Kubernetes upplýsingaskrá.

Til að framkvæma allar prófanir er nauðsynlegt að búa til viðeigandi reglur. Þau eru skrifuð í YAML skrár sem kallast „reglusett“ (reglusett), og hafa eftirfarandi uppbyggingu:

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

(rule.yaml)

Við skulum rannsaka það nánar:

• Field type tilgreinir hvaða gerð stillingar config-lint mun nota. Fyrir K8s birtir þetta er alltaf Kubernetes.
• Á sviði files Til viðbótar við skrárnar sjálfar geturðu tilgreint möppu.
• Field rules ætlað til að setja notendapróf.

Segjum að þú viljir ganga úr skugga um að myndir í Deployment séu alltaf sóttar frá traustri geymslu eins og my-company.com/myapp:1.0. Config-lint regla sem framkvæmir slíka athugun myndi líta svona út:

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

Hver regla verður að hafa eftirfarandi eiginleika:

• id — einstakt auðkenni reglunnar;
• severity - Kannski BILUN, VIÐVÖRUN и NON_COMPLIANT;
• message — ef regla er brotin birtist innihald þessarar línu;
• resource — hvers konar auðlind þessi regla gildir um;
• assertions — listi yfir aðstæður sem verða metnar í tengslum við þessa auðlind.

Í reglunni hér að ofan assertion kallað every athugar að allir gámar séu í dreifingu (key: spec.templates.spec.containers) notaðu traustar myndir (þ.e.a.s. byrja á my-company.com/).

Heildar reglusettið lítur svona út:

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)

Til að prófa prófið skulum við vista það sem check_image_repo.yaml. Við skulum athuga skrána 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"
  }
]

Athugunin mistókst. Nú skulum við kíkja á eftirfarandi upplýsingaskrá með réttri myndgeymslu:

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ð keyrum sama prófið með ofangreindri upplýsingaskrá. Engin vandamál fundust:

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

Config-lint er efnilegur rammi sem gerir þér kleift að búa til þín eigin próf til að staðfesta Kubernetes YAML upplýsingaskrá með YAML DSL.

En hvað ef þú þarft flóknari rökfræði og próf? Er YAML ekki of takmarkað fyrir þetta? Hvað ef þú gætir búið til próf á fullu forritunarmáli?

4. Kopar

Kopar V2 er rammi til að staðfesta upplýsingaskrá með sérsniðnum prófum (svipað og config-lint).

Hins vegar er það frábrugðið hinu síðarnefnda að því leyti að það notar ekki YAML til að lýsa prófum. Próf er hægt að skrifa í JavaScript í staðinn. Copper býður upp á bókasafn með nokkrum grunnverkfærum, sem hjálpa þér að lesa upplýsingar um Kubernetes hluti og tilkynna villur.

Skrefin til að setja upp Copper má finna í opinber skjöl.

2.0.1 er nýjasta útgáfan af þessu tóli þegar upphaflega greinin er skrifuð.

Eins og config-lint er Copper ekki með innbyggð próf. Við skulum skrifa eina. Láttu það athuga að dreifingar noti gámamyndir eingöngu frá traustum geymslum eins og my-company.com.

Búðu til skrá check_image_repo.js með eftirfarandi innihaldi:

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

Nú á að prófa upplýsingaskrá okkar base-valid.yaml, notaðu skipunina 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

Það er ljóst að með hjálp kopar er hægt að framkvæma flóknari próf - til dæmis að athuga lén í Ingress upplýsingaskrá eða hafna belg sem keyra í forréttindaham.

Kopar hefur ýmsar gagnsemisaðgerðir innbyggðar í það:

• DockerImage les tilgreinda inntaksskrá og býr til hlut með eftirfarandi eiginleikum:
  • name - nafn myndarinnar,
  • tag - myndmerki,
  • registry - myndaskrá,
  • registry_url - siðareglur (https://) og myndaskrá,
  • fqin — full staðsetning myndarinnar.
• Virka findByName hjálpar til við að finna auðlind eftir tiltekinni gerð (kind) og nafn (name) úr inntaksskránni.
• Virka findByLabels hjálpar til við að finna auðlind eftir tiltekinni gerð (kind) og merki (labels).

Þú getur skoðað allar tiltækar þjónustuaðgerðir hér.

Sjálfgefið er að það hleður allri YAML skránni inn í breytu $$ og gerir það aðgengilegt fyrir forskriftir (kunnugleg tækni fyrir þá sem hafa jQuery reynslu).

Helsti kosturinn við Copper er augljós: þú þarft ekki að ná tökum á sérhæfðu tungumáli og þú getur notað ýmsa JavaScript eiginleika til að búa til þín eigin próf, eins og strengjaskil, aðgerðir o.s.frv.

Það skal líka tekið fram að núverandi útgáfa af Copper vinnur með ES5 útgáfu af JavaScript vélinni, ekki ES6.

Upplýsingar fást á opinber vefsíða verkefnisins.

Hins vegar, ef þér líkar ekki við JavaScript og vilt frekar tungumál sem er sérstaklega hannað til að búa til fyrirspurnir og lýsa stefnum, ættir þú að borga eftirtekt til keppni.

5.Samkeppni

Conftest er rammi til að prófa stillingargögn. Hentar einnig til að prófa/staðfesta Kubernetes birtingaskrár. Prófum er lýst með sérhæfðu fyrirspurnarmáli Rego.

Þú getur sett upp conftest með því að nota leiðbeiningarskráð á heimasíðu verkefnisins.

Þegar upphaflega greinin var skrifuð var nýjasta útgáfan tiltæk 0.18.2.

Líkt og config-lint og kopar kemur conftest án innbyggðra prófa. Við skulum prófa það og skrifa okkar eigin stefnu. Eins og í fyrri dæmum munum við athuga hvort gámamyndirnar séu teknar frá áreiðanlegum uppruna.

Búðu til möppu conftest-checks, og í henni er skrá sem heitir check_image_registry.rego með eftirfarandi innihaldi:

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

Nú skulum við prófa base-valid.yaml gegnum 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

Fyrirsjáanlega mistókst prófið vegna þess að myndirnar komu frá ótraustum aðilum.

Í Rego skránni skilgreinum við blokkina deny. Sannleikur þess er talinn brot. Ef blokkir deny nokkrir, conftest athugar þá óháð hver öðrum, og sannleikur einhvers af blokkunum er meðhöndlaður sem brot.

Til viðbótar við sjálfgefna úttakið styður conftest JSON, TAP og töflusnið - afar gagnlegur eiginleiki ef þú þarft að fella skýrslur inn í núverandi CI leiðslu. Þú getur stillt æskilegt snið með því að nota fánann --output.

Til að gera það auðveldara að kemba stefnur er conftest með fána --trace. Það gefur út ummerki um hvernig conftest greinir tilgreindar stefnuskrár.

Hægt er að birta keppnisreglur og deila þeim í OCI (Open Container Initiative) skrám sem gripir.

Lið push и pull leyfa þér að birta grip eða sækja grip sem fyrir er úr fjarlægri skráningu. Við skulum reyna að birta stefnuna sem við bjuggum til í Docker-skránni á staðnum með því að nota conftest push.

Byrjaðu Docker skrána þína á staðnum:

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

Í annarri flugstöð, farðu í möppuna sem þú bjóst til áðan conftest-checks og keyrðu eftirfarandi skipun:

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

Ef skipunin tókst, muntu sjá skilaboð eins og þessi:

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

Búðu til tímabundna möppu og keyrðu skipunina í henni conftest pull. Það mun hlaða niður pakkanum sem búið var til með fyrri skipuninni:

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

Undirskrá mun birtast í bráðabirgðaskránni policysem inniheldur stefnuskrá okkar:

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

Hægt er að keyra próf beint úr geymslunni:

$ 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

Því miður er DockerHub ekki enn stutt. Svo teldu þig heppinn ef þú notar Azure gámaskrá (ACR) eða þinn eigin skrásetning.

Artifact snið er það sama og Opnaðu Policy Agent pakka (OPA), sem gerir þér kleift að nota conftest til að keyra próf úr núverandi OPA pakka.

Þú getur lært meira um stefnumiðlun og aðra eiginleika keppni á opinber vefsíða verkefnisins.

6. Polaris

Síðasta tólið sem fjallað verður um í þessari grein er Polaris. (Tilkynning síðasta árs hans við þegar þýdd - ca. þýðing)

Polaris er hægt að setja upp í klasa eða nota í skipanalínuham. Eins og þú gætir hafa giskað á gerir það þér kleift að greina Kubernetes birtingarmyndir með kyrrstöðu.

Þegar keyrt er í skipanalínuham eru innbyggð próf fáanleg sem ná yfir svæði eins og öryggi og bestu starfsvenjur (svipað og kube-score). Að auki geturðu búið til þín eigin próf (eins og í config-lint, copper og conftest).

Með öðrum orðum, Polaris sameinar kosti beggja flokka verkfæra: með innbyggðum og sérsniðnum prófum.

Til að setja upp Polaris í skipanalínuham skaltu nota leiðbeiningar á heimasíðu verkefnisins.

Þegar upphaflega greinin er skrifuð er útgáfa 1.0.3 tiltæk.

Þegar uppsetningunni er lokið geturðu keyrt polaris á upplýsingaskránni base-valid.yaml með eftirfarandi skipun:

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

Það mun gefa út streng á JSON sniði með nákvæmri lýsingu á prófunum sem gerðar eru og niðurstöðum þeirra. Úttakið mun hafa eftirfarandi uppbyggingu:

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

Full framleiðsla í boði hér.

Eins og kube-score, greinir Polaris vandamál á svæðum þar sem upplýsingaskráin uppfyllir ekki bestu starfsvenjur:

• Það eru engar heilsufarsskoðanir fyrir belg.
• Merki fyrir gámamyndir eru ekki tilgreindar.
• Ílátið rekur sem rót.
• Beiðnir og takmörk fyrir minni og örgjörva eru ekki tilgreindar.

Hverri prófun, eftir niðurstöðum þess, er úthlutað ákveðinni gagnrýni: viðvörun eða hætta. Til að læra meira um tiltæk innbyggðu próf, vinsamlegast vísa til skjöl.

Ef ekki er þörf á upplýsingum er hægt að tilgreina fánann --format score. Í þessu tilviki mun Polaris gefa út tölu á bilinu 1 til 100 - skora (þ.e. mat):

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

Því nær sem stigið er 100, því hærra er samræmið. Ef þú athugar útgöngukóða skipunarinnar polaris audit, þá kemur í ljós að það er jafnt og 0.

Afl polaris audit Þú getur hætt vinnu með kóða sem er ekki núll með því að nota tvo fána:

• Flagga --set-exit-code-below-score tekur sem rök þröskuld á bilinu 1-100. Í þessu tilviki mun skipunin hætta með útgöngukóða 4 ef stigið er undir viðmiðunarmörkum. Þetta er mjög gagnlegt þegar þú ert með ákveðið viðmiðunargildi (t.d. 75) og þú þarft að fá viðvörun ef stigið fer undir.
• Flagga --set-exit-code-on-danger mun valda því að skipunin mistekst með kóða 3 ef eitt af hættuprófunum mistekst.

Nú skulum við reyna að búa til sérsniðið próf sem athugar hvort myndin sé tekin úr traustri geymslu. Sérsniðin próf eru tilgreind á YAML sniði og prófinu sjálfu er lýst með JSON Schema.

Eftirfarandi YAML kóðabútur lýsir nýju prófi sem kallast 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/.+$

Við skulum skoða það nánar:

• successMessage — þessi lína verður prentuð ef prófinu lýkur;
• failureMessage — þessi skilaboð verða sýnd ef bilun verður;
• category — gefur til kynna einn af flokkunum: Images, Health Checks, Security, Networking и Resources;
• target--- ákvarðar hvaða tegund af hlut (spec) próf er beitt. Möguleg gildi: Container, Pod eða Controller;
• Prófið sjálft er tilgreint í hlutnum schema með því að nota JSON skema. Lykilorðið í þessu prófi er pattern notað til að bera saman mynduppsprettu við þá sem krafist er.

Til að keyra prófið hér að ofan þarftu að búa til eftirfarandi Polaris stillingar:

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)

Við skulum flokka skrána:

• Á sviði checks mælt er fyrir um próf og gagnrýnistig þeirra. Þar sem æskilegt er að fá viðvörun þegar mynd er tekin frá ótraustum uppruna, stillum við stigið hér danger.
• Prófið sjálft checkImageRepo síðan skráð í hlutinn customChecks.

Vistaðu skrána sem custom_check.yaml. Nú geturðu hlaupið polaris audit með YAML upplýsingaskrá sem krefst staðfestingar.

Prófum stefnuskrá okkar base-valid.yaml:

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

Team polaris audit keyrði aðeins notendaprófið sem tilgreint er hér að ofan og það mistókst.

Ef þú lagar myndina við my-company.com/http-echo:1.0, Polaris mun ljúka með góðum árangri. Stefnuskráin með breytingunum er þegar komin inn geymslumsvo þú getur athugað fyrri skipunina á upplýsingaskránni image-valid-mycompany.yaml.

Nú vaknar spurningin: hvernig á að keyra innbyggð próf ásamt sérsniðnum? Auðveldlega! Þú þarft bara að bæta innbyggðu prófunarauðkennum við stillingarskrána. Þar af leiðandi mun það taka eftirfarandi form:

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)

Dæmi um fullkomna stillingarskrá er fáanleg hér.

Athugaðu upplýsingaskrá base-valid.yamlmeð því að nota innbyggð og sérsniðin próf geturðu notað skipunina:

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

Polaris bætir við innbyggðu prófunum með sérsniðnum prófunum og sameinar þar með það besta af báðum heimum.

Á hinn bóginn getur vanhæfni til að nota öflugri tungumál eins og Rego eða JavaScript verið takmarkandi þáttur sem kemur í veg fyrir að flóknari próf séu til.

Nánari upplýsingar um Polaris er að finna á heimasíðu verkefnisins.

Yfirlit

Þó að mörg verkfæri séu tiltæk til að skoða og meta Kubernetes YAML skrár, það er mikilvægt að hafa skýran skilning á því hvernig prófin verða hönnuð og framkvæmd.

Til dæmis, ef þú tekur Kubernetes upplýsingabréf sem fara í gegnum leiðslu, gæti kubeval verið fyrsta skrefið í slíkri leiðslu. Það myndi fylgjast með því hvort hlutskilgreiningar séu í samræmi við Kubernetes API skema.

Þegar slíkri endurskoðun er lokið gæti farið yfir í flóknari próf, svo sem samræmi við staðlaða bestu starfsvenjur og sérstakar stefnur. Þetta er þar sem kube-score og Polaris myndu koma sér vel.

Fyrir þá sem hafa flóknar kröfur og þurfa að sérsníða próf í smáatriðum, þá henta kopar, config-lint og conftest.

Conftest og config-lint nota YAML til að skilgreina sérsniðin próf, og kopar gefur þér aðgang að fullu forritunarmáli, sem gerir það að mjög aðlaðandi vali.

Á hinn bóginn, er það þess virði að nota eitt af þessum verkfærum og þess vegna búa til öll prófin handvirkt, eða kjósa Polaris og bæta aðeins því sem þarf við það? Það er ekkert skýrt svar við þessari spurningu.

Taflan hér að neðan gefur stutta lýsingu á hverju verkfæri:

Tól
Tilgangur
Takmarkanir
Notendapróf

kubeval
Staðfestir YAML birtingarmyndir gegn tiltekinni útgáfu af API skema
Getur ekki unnið með CRD
No

kúbe-stig
Greinir YAML birtingarmyndir gegn bestu starfsvenjum
Ekki er hægt að velja Kubernetes API útgáfuna þína til að athuga tilföng
No

kopar
Almenn rammi til að búa til sérsniðin JavaScript próf fyrir YAML birtingarmyndir
Engin innbyggð próf. Léleg skjöl
Já

config-lint
Almennur rammi til að búa til próf á lénssértæku tungumáli sem er innbyggt í YAML. Styður ýmis stillingarsnið (t.d. Terraform)
Það eru engin tilbúin próf. Innbyggðar fullyrðingar og aðgerðir duga kannski ekki
Já

keppni
Rammi til að búa til þín eigin próf með því að nota Rego (sérhæft fyrirspurnartungumál). Leyfir deilingu stefnu í gegnum OCI búnt
Engin innbyggð próf. Ég verð að læra Rego. Docker Hub er ekki stutt þegar reglur eru birtar
Já

Polaris
Umsagnir YAML birtast gegn stöðluðum bestu starfsvenjum. Gerir þér kleift að búa til þín eigin próf með því að nota JSON Schema
Prófunargeta sem byggir á JSON Schema gæti ekki verið nægjanleg
Já

Vegna þess að þessi verkfæri treysta ekki á aðgang að Kubernetes klasanum er auðvelt að setja þau upp. Þeir gera þér kleift að sía upprunaskrár og veita skjót endurgjöf til höfunda dráttarbeiðna í verkefnum.

PS frá þýðanda

Lestu líka á blogginu okkar:

• «Polaris kynnt til að halda Kubernetes þyrpingum heilbrigðum»;
• «Vim með YAML stuðningi fyrir Kubernetes»;
• «7 bestu starfsvenjur til að nota ílát samkvæmt Google'.

Heimild: www.habr.com