ProHoster > Blog > Pangangasiwa > I-validate ang Kubernetes YAML laban sa pinakamahuhusay na kagawian at patakaran

I-validate ang Kubernetes YAML laban sa pinakamahuhusay na kagawian at patakaran

Tandaan. transl.: Sa dumaraming bilang ng mga configuration ng YAML para sa mga kapaligiran ng K8, ang pangangailangan para sa kanilang awtomatikong pag-verify ay nagiging mas apurahan. Ang may-akda ng pagsusuring ito ay hindi lamang pumili ng mga kasalukuyang solusyon para sa gawaing ito, ngunit ginamit din ang Deployment bilang isang halimbawa upang makita kung paano gumagana ang mga ito. Ito ay naging napaka-kaalaman para sa mga interesado sa paksang ito.

I-validate ang Kubernetes YAML laban sa pinakamahuhusay na kagawian at patakaran

Tl; DR: Ang artikulong ito ay naghahambing ng anim na static na tool upang patunayan at suriin ang mga Kubernetes YAML file kumpara sa pinakamahuhusay na kagawian at kinakailangan.

Ang mga workload ng Kubernetes ay karaniwang tinutukoy sa anyo ng mga dokumento ng YAML. Ang isa sa mga problema sa YAML ay ang kahirapan sa pagtukoy ng mga hadlang o relasyon sa pagitan ng mga manifest file.

Paano kung kailangan nating tiyakin na ang lahat ng mga larawang na-deploy sa cluster ay nagmumula sa isang pinagkakatiwalaang registry?

Paano ko mapipigilan ang mga Deployment na walang PodDisruptionBudgets na maipadala sa cluster?

Nagbibigay-daan sa iyo ang pagsasama ng static na pagsubok na matukoy ang mga error at paglabag sa patakaran sa yugto ng pag-unlad. Pinapataas nito ang garantiya na tama at secure ang mga kahulugan ng mapagkukunan, at ginagawang mas malamang na susundin ng mga workload sa produksyon ang pinakamahuhusay na kagawian.

Ang Kubernetes static YAML file inspection ecosystem ay maaaring hatiin sa mga sumusunod na kategorya:

  • Mga validator ng API. Sinusuri ng mga tool sa kategoryang ito ang manifest ng YAML laban sa mga kinakailangan ng server ng Kubernetes API.
  • Mga handa na tester. Ang mga tool mula sa kategoryang ito ay may kasamang mga handa na pagsubok para sa seguridad, pagsunod sa pinakamahuhusay na kagawian, atbp.
  • Mga custom na validator. Binibigyang-daan ka ng mga kinatawan ng kategoryang ito na lumikha ng mga custom na pagsubok sa iba't ibang wika, halimbawa, Rego at Javascript.

Sa artikulong ito, ilalarawan at ihahambing namin ang anim na magkakaibang tool:

  1. kubeval;
  2. kube-score;
  3. config-lint;
  4. tanso;
  5. paligsahan;
  6. polaris.

Well, magsimula tayo!

Sinusuri ang Mga Deployment

Bago natin simulan ang paghahambing ng mga tool, gumawa tayo ng ilang background kung saan susubukan ang mga ito.

Ang manifesto sa ibaba ay naglalaman ng ilang mga error at hindi pagsunod sa pinakamahuhusay na kagawian: ilan sa mga ito ang makikita mo?

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)

Gagamitin namin ang YAML na ito upang ihambing ang iba't ibang mga tool.

Ang manifesto sa itaas base-valid.yaml at iba pang mga manifesto mula sa artikulong ito ay matatagpuan sa Mga repositoryo ng Git.

Inilalarawan ng manifest ang isang web application na ang pangunahing gawain ay tumugon gamit ang isang "Hello World" na mensahe sa port 5678. Maaari itong i-deploy gamit ang sumusunod na command:

kubectl apply -f hello-world.yaml

At kaya - suriin ang trabaho:

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

Ngayon punta ka na http://localhost:8080 at kumpirmahin na gumagana ang application. Ngunit sinusunod ba nito ang pinakamahuhusay na kagawian? Suriin natin.

1. Kubeval

Sa puso kubeval Ang ideya ay ang anumang pakikipag-ugnayan sa Kubernetes ay nangyayari sa pamamagitan ng REST API nito. Sa madaling salita, maaari kang gumamit ng API schema upang suriin kung ang isang ibinigay na YAML ay sumusunod dito. Tingnan natin ang isang halimbawa.

Mga tagubilin sa pag-install Kubeval ay makukuha sa website ng proyekto.

Sa oras ng pagsulat ng orihinal na artikulo, ang bersyon 0.15.0 ay magagamit.

Kapag na-install na, ipakain natin ito sa manifest sa itaas:

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

Kung matagumpay, lalabas ang kubeval na may exit code 0. Maaari mong suriin ito bilang mga sumusunod:

$ echo $?
0

Subukan natin ngayon ang kubeval gamit ang ibang 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)

Nakikita mo ba ang problema sa pamamagitan ng mata? Ilunsad natin:

$ 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

Ang mapagkukunan ay hindi nabe-verify.

Mga deployment gamit ang bersyon ng API apps/v1, dapat may kasamang selector na tumutugma sa label ng pod. Ang manifest sa itaas ay hindi kasama ang selector, kaya nag-ulat ang kubeval ng isang error at lumabas na may hindi zero na code.

Iniisip ko kung ano ang mangyayari kung gagawin ko kubectl apply -f sa manifesto na ito?

Well, subukan natin:

$ 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

Ito mismo ang error na binalaan ni kubeval. Maaayos mo ito sa pamamagitan ng pagdaragdag ng isang tagapili:

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)

Ang pakinabang ng mga tool tulad ng kubeval ay ang mga error na tulad nito ay maaaring mahuli nang maaga sa cycle ng deployment.

Bilang karagdagan, ang mga pagsusuring ito ay hindi nangangailangan ng access sa cluster; maaari silang isagawa offline.

Bilang default, sinusuri ng kubeval ang mga mapagkukunan laban sa pinakabagong Kubernetes API schema. Gayunpaman, sa karamihan ng mga kaso maaaring kailanganin mong suriin laban sa isang partikular na paglabas ng Kubernetes. Magagawa ito gamit ang bandila --kubernetes-version:

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

Mangyaring tandaan na ang bersyon ay dapat na tinukoy sa format Major.Minor.Patch.

Para sa isang listahan ng mga bersyon kung saan sinusuportahan ang pag-verify, mangyaring sumangguni sa JSON schema sa GitHub, na ginagamit ng kubeval para sa pagpapatunay. Kung kailangan mong patakbuhin ang kubeval offline, i-download ang mga schema at tukuyin ang kanilang lokal na lokasyon gamit ang flag --schema-location.

Bilang karagdagan sa mga indibidwal na YAML file, ang kubeval ay maaari ding gumana sa mga direktoryo at stdin.

Bilang karagdagan, ang Kubeval ay madaling sumasama sa pipeline ng CI. Ang mga nagnanais na magpatakbo ng mga pagsubok bago magpadala ng mga manifest sa cluster ay malulugod na malaman na ang kubeval ay sumusuporta sa tatlong mga format ng output:

  1. Payak na teksto;
  2. JSON;
  3. Subukan ang Anything Protocol (TAP).

At alinman sa mga format ay maaaring gamitin para sa karagdagang pag-parse ng output upang makabuo ng isang buod ng mga resulta ng nais na uri.

Ang isa sa mga disbentaha ng kubeval ay ang kasalukuyan ay hindi nito masusuri ang pagsunod sa mga Custom Resource Definition (CRDs). Gayunpaman, posibleng i-configure ang kubeval wag mo silang pansinin.

Ang Kubeval ay isang mahusay na tool para sa pagsusuri at pagsusuri ng mga mapagkukunan; Gayunpaman, dapat itong bigyang-diin na ang pagpasa sa pagsusulit ay hindi ginagarantiyahan na ang mapagkukunan ay sumusunod sa mga pinakamahusay na kasanayan.

Halimbawa, gamit ang tag latest sa isang lalagyan ay hindi sumusunod sa pinakamahuhusay na kagawian. Gayunpaman, hindi ito itinuturing ng kubeval na isang error at hindi ito iniuulat. Iyon ay, ang pag-verify ng naturang YAML ay makukumpleto nang walang mga babala.

Ngunit paano kung gusto mong suriin ang YAML at tukuyin ang mga paglabag tulad ng tag latest? Paano ko susuriin ang isang YAML file laban sa pinakamahuhusay na kagawian?

2. Kube-score

Kube-score nag-parse ng YAML manifests at sinusuri ang mga ito laban sa mga built-in na pagsubok. Pinipili ang mga pagsubok na ito batay sa mga alituntunin sa seguridad at pinakamahuhusay na kagawian, gaya ng:

  • Ang pagpapatakbo ng lalagyan ay hindi bilang ugat.
  • Availability ng pod health checks.
  • Pagtatakda ng mga kahilingan at limitasyon para sa mga mapagkukunan.

Batay sa mga resulta ng pagsusulit, tatlong resulta ang ibinigay: OK, BABALA ΠΈ MAPANGANIB.

Maaari mong subukan ang Kube-score online o i-install ito nang lokal.

Sa panahon ng pagsulat ng orihinal na artikulo, ang pinakabagong bersyon ng kube-score ay 1.7.0.

Subukan natin ito sa ating manifest 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.

Ang YAML ay pumasa sa mga pagsusulit sa kubeval, habang ang kube-score ay tumuturo sa mga sumusunod na kapintasan:

  • Ang mga pagsusuri sa kahandaan ay hindi na-configure.
  • Walang mga kahilingan o limitasyon para sa mga mapagkukunan at memorya ng CPU.
  • Hindi tinukoy ang mga badyet sa pagkaantala ng pod.
  • Walang mga patakaran ng paghihiwalay (anti-affinity) upang i-maximize ang availability.
  • Ang lalagyan ay tumatakbo bilang ugat.

Ito ang lahat ng wastong punto tungkol sa mga pagkukulang na kailangang tugunan upang gawing mas mahusay at maaasahan ang Deployment.

Koponan kube-score nagpapakita ng impormasyon sa form na nababasa ng tao kasama ang lahat ng uri ng paglabag BABALA ΠΈ MAPANGANIB, na nakakatulong nang malaki sa panahon ng pag-unlad.

Ang mga nagnanais na gamitin ang tool na ito sa loob ng pipeline ng CI ay maaaring paganahin ang mas naka-compress na output gamit ang bandila --output-format ci (sa kasong ito, ang mga pagsubok na may resulta ay ipinapakita din 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

Katulad ng kubeval, ang kube-score ay nagbabalik ng non-zero exit code kapag may pagsubok na nabigo MAPANGANIB. Maaari mo ring paganahin ang katulad na pagproseso para sa BABALA.

Bilang karagdagan, posibleng suriin ang mga mapagkukunan para sa pagsunod sa iba't ibang bersyon ng API (tulad ng sa kubeval). Gayunpaman, ang impormasyong ito ay naka-hardcode sa kube-score mismo: hindi ka makakapili ng ibang bersyon ng Kubernetes. Maaaring maging malaking problema ang limitasyong ito kung balak mong i-upgrade ang iyong cluster o kung marami kang cluster na may iba't ibang bersyon ng K8s.

Mangyaring tandaan na ang may isyu na na may panukala upang maisakatuparan ang pagkakataong ito.

Higit pang impormasyon tungkol sa kube-score ay matatagpuan sa opisyal na website.

Ang mga pagsusulit ng Kube-score ay isang mahusay na tool para sa pagpapatupad ng pinakamahuhusay na kagawian, ngunit paano kung kailangan mong gumawa ng mga pagbabago sa pagsubok o magdagdag ng sarili mong mga panuntunan? Naku, hindi ito magagawa.

Ang Kube-score ay hindi mapapalawak: hindi ka maaaring magdagdag ng mga patakaran dito o ayusin ang mga ito.

Kung kailangan mong magsulat ng mga custom na pagsubok para i-verify ang pagsunod sa mga patakaran ng kumpanya, maaari mong gamitin ang isa sa sumusunod na apat na tool: config-lint, copper, conftest, o polaris.

3.Config-lint

Ang Config-lint ay isang tool para sa pagpapatunay ng YAML, JSON, Terraform, CSV configuration file at Kubernetes manifests.

Maaari mong i-install ito gamit ang mga tagubilin sa website ng proyekto.

Ang kasalukuyang release sa oras ng pagsulat ng orihinal na artikulo ay 1.5.0.

Walang mga built-in na pagsubok ang Config-lint para sa pagpapatunay ng mga manifest ng Kubernetes.

Upang magsagawa ng anumang mga pagsubok, kailangan mong lumikha ng mga naaangkop na panuntunan. Ang mga ito ay nakasulat sa YAML file na tinatawag na "rulesets" (mga panuntunan), at magkaroon ng sumusunod na istraktura:

version: 1
description: Rules for Kubernetes spec files
type: Kubernetes
files:
  - "*.yaml"
rules:
   # список ΠΏΡ€Π°Π²ΠΈΠ»

(rule.yaml)

Pag-aralan natin ito nang mas mabuti:

  • Field type tumutukoy kung anong uri ng configuration config-lint ang gagamitin. Para sa K8s manifests ito ay laging Kubernetes.
  • Sa larangan files Bilang karagdagan sa mga file mismo, maaari mong tukuyin ang isang direktoryo.
  • Field rules nilayon para sa pagtatakda ng mga pagsubok ng user.

Sabihin nating gusto mong tiyakin na ang mga larawan sa Deployment ay palaging dina-download mula sa isang pinagkakatiwalaang repositoryo tulad ng my-company.com/myapp:1.0. Ang isang config-lint na panuntunan na nagsasagawa ng naturang pagsusuri ay magiging ganito:

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

Ang bawat panuntunan ay dapat magkaroon ng mga sumusunod na katangian:

  • id β€” natatanging identifier ng panuntunan;
  • severity - Maaaring Pagkabigo, BABALA ΠΈ NON_COMPLIANT;
  • message β€” kung ang isang panuntunan ay nilabag, ang mga nilalaman ng linyang ito ay ipinapakita;
  • resource β€” ang uri ng mapagkukunan kung saan nalalapat ang panuntunang ito;
  • assertions β€” isang listahan ng mga kundisyon na susuriin kaugnay ng mapagkukunang ito.

Sa tuntunin sa itaas assertion tinawagan every sinusuri kung ang lahat ng mga lalagyan ay nasa Deployment (key: spec.templates.spec.containers) gumamit ng mga pinagkakatiwalaang larawan (ibig sabihin, nagsisimula sa my-company.com/).

Ang kumpletong ruleset ay ganito ang hitsura:

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)

Upang subukan ang pagsubok, i-save natin ito bilang check_image_repo.yaml. Suriin natin ang file 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"
  }
]

Nabigo ang tseke. Ngayon tingnan natin ang sumusunod na manifest na may tamang imbakan ng imahe:

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)

Nagpapatakbo kami ng parehong pagsubok sa manifest sa itaas. Walang nakitang problema:

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

Ang Config-lint ay isang promising framework na nagbibigay-daan sa iyong gumawa ng sarili mong mga pagsubok para ma-validate ang Kubernetes YAML manifests gamit ang YAML DSL.

Ngunit paano kung kailangan mo ng mas kumplikadong lohika at mga pagsubok? Hindi ba masyadong limitado ang YAML para dito? Paano kung maaari kang lumikha ng mga pagsubok sa isang buong programming language?

4. tanso

Copper V2 ay isang balangkas para sa pagpapatunay ng mga manifest gamit ang mga custom na pagsubok (katulad ng config-lint).

Gayunpaman, naiiba ito sa huli dahil hindi ito gumagamit ng YAML upang ilarawan ang mga pagsubok. Ang mga pagsubok ay maaaring isulat sa JavaScript sa halip. Ang Copper ay nagbibigay ng isang silid-aklatan na may ilang mga pangunahing kasangkapan, na tumutulong sa iyong magbasa ng impormasyon tungkol sa mga bagay ng Kubernetes at mag-ulat ng mga error.

Ang mga hakbang para sa pag-install ng Copper ay matatagpuan sa opisyal na dokumentasyon.

Ang 2.0.1 ay ang pinakabagong release ng utility na ito sa oras ng pagsulat ng orihinal na artikulo.

Tulad ng config-lint, ang Copper ay walang mga built-in na pagsubok. Sumulat tayo ng isa. Hayaang suriin na ang mga deployment ay gumagamit ng mga larawan ng container na eksklusibo mula sa mga pinagkakatiwalaang repositoryo tulad ng my-company.com.

Gumawa ng file check_image_repo.js na may sumusunod na nilalaman:

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

Ngayon upang subukan ang aming manifest base-valid.yaml, gamitin ang command 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

Malinaw na sa tulong ng tanso maaari kang magsagawa ng mas kumplikadong mga pagsubok - halimbawa, ang pagsuri sa mga pangalan ng domain sa Ingress ay nagpapakita o pagtanggi sa mga pod na tumatakbo sa privileged mode.

Ang tanso ay may iba't ibang mga function ng utility na nakapaloob dito:

  • DockerImage binabasa ang tinukoy na input file at lumilikha ng isang bagay na may mga sumusunod na katangian:
    • name - pangalan ng larawan,
    • tag - tag ng larawan,
    • registry - pagpapatala ng larawan,
    • registry_url - protocol (https://) at pagpapatala ng larawan,
    • fqin β€” buong lokasyon ng larawan.
  • Tungkulin findByName tumutulong na makahanap ng mapagkukunan ayon sa isang partikular na uri (kind) at pangalan (name) mula sa input file.
  • Tungkulin findByLabels tumutulong na makahanap ng mapagkukunan ayon sa isang tiyak na uri (kind) at mga label (labels).

Maaari mong tingnan ang lahat ng magagamit na mga function ng serbisyo dito.

Bilang default, nilo-load nito ang buong input na YAML file sa isang variable $$ at ginagawa itong magagamit para sa pag-script (isang pamilyar na pamamaraan para sa mga may karanasan sa jQuery).

Ang pangunahing bentahe ng Copper ay halata: hindi mo kailangang makabisado ang isang espesyal na wika at maaari mong gamitin ang iba't ibang mga tampok ng JavaScript upang lumikha ng iyong sariling mga pagsubok, tulad ng string interpolation, mga function, atbp.

Dapat ding tandaan na ang kasalukuyang bersyon ng Copper ay gumagana sa ES5 na bersyon ng JavaScript engine, hindi ES6.

Available ang mga detalye sa opisyal na website ng proyekto.

Gayunpaman, kung hindi mo talaga gusto ang JavaScript at mas gusto mo ang isang wikang partikular na idinisenyo para sa paglikha ng mga query at paglalarawan ng mga patakaran, dapat mong bigyang-pansin ang kumpetisyon.

5. Kumpetisyon

Ang Contest ay isang framework para sa pagsubok ng data ng configuration. Angkop din para sa pagsubok/pag-verify ng mga manifest ng Kubernetes. Inilalarawan ang mga pagsubok gamit ang isang espesyal na wika ng query Rego.

Maaari kang mag-install ng conftest gamit ang mga tagubilinnakalista sa website ng proyekto.

Sa panahon ng pagsulat ng orihinal na artikulo, ang pinakabagong bersyon na magagamit ay 0.18.2.

Katulad ng config-lint at copper, dumarating ang conftest nang walang anumang built-in na pagsubok. Subukan natin ito at magsulat ng sarili nating patakaran. Tulad ng sa mga nakaraang halimbawa, susuriin namin kung ang mga larawan ng lalagyan ay kinuha mula sa isang mapagkakatiwalaang pinagmulan.

Lumikha ng isang direktoryo conftest-checks, at sa loob nito ay may isang file na pinangalanan check_image_registry.rego na may sumusunod na nilalaman:

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

Ngayon subukan natin base-valid.yaml sa pamamagitan ng 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

Mahuhulaan na nabigo ang pagsubok dahil nagmula ang mga larawan sa hindi pinagkakatiwalaang pinagmulan.

Sa Rego file ay tinukoy namin ang block deny. Ang katotohanan nito ay itinuturing na isang paglabag. Kung block deny ilan sa kanila, independiyenteng sinusuri ng conftest ang isa't isa, at ang katotohanan ng alinman sa mga bloke ay itinuturing na isang paglabag.

Bilang karagdagan sa default na output, sinusuportahan ng conftest ang JSON, TAP at format ng talahanayan - isang lubhang kapaki-pakinabang na feature kung kailangan mong mag-embed ng mga ulat sa isang umiiral nang pipeline ng CI. Maaari mong itakda ang nais na format gamit ang bandila --output.

Upang gawing mas madali ang pag-debug ng mga patakaran, may flag ang conftest --trace. Naglalabas ito ng bakas kung paano pinag-parse ng conftest ang mga tinukoy na file ng patakaran.

Maaaring i-publish at ibahagi ang mga patakaran sa paligsahan sa mga rehistro ng OCI (Open Container Initiative) bilang mga artifact.

Mga Koponan push ΠΈ pull nagbibigay-daan sa iyong mag-publish ng isang artifact o kumuha ng isang umiiral na artifact mula sa isang remote registry. Subukan nating i-publish ang patakarang ginawa namin sa lokal na Docker registry gamit conftest push.

Simulan ang iyong lokal na pagpapatala ng Docker:

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

Sa isa pang terminal, pumunta sa direktoryo na ginawa mo kanina conftest-checks at patakbuhin ang sumusunod na command:

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

Kung matagumpay ang utos, makakakita ka ng mensaheng tulad nito:

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

Ngayon lumikha ng isang pansamantalang direktoryo at patakbuhin ang utos dito conftest pull. Ida-download nito ang package na nilikha ng nakaraang command:

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

May lalabas na subdirectory sa pansamantalang direktoryo policynaglalaman ng aming file ng patakaran:

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

Maaaring direktang tumakbo ang mga pagsubok mula sa imbakan:

$ 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

Sa kasamaang palad, hindi pa sinusuportahan ang DockerHub. Kaya isaalang-alang ang iyong sarili na masuwerte kung gagamitin mo Azure Container Registry (ACR) o ang iyong sariling pagpapatala.

Ang format ng artifact ay pareho sa Buksan ang mga package ng Policy Agent (OPA), na nagbibigay-daan sa iyong gumamit ng conftest upang magpatakbo ng mga pagsubok mula sa mga umiiral nang OPA package.

Maaari kang matuto nang higit pa tungkol sa pagbabahagi ng patakaran at iba pang mga feature ng conftest sa opisyal na website ng proyekto.

6. Polaris

Ang huling tool na tatalakayin sa artikulong ito ay Polaris. (Yung last year's announcement namin naisalin na - tinatayang pagsasalin)

Maaaring i-install ang Polaris sa isang cluster o gamitin sa command line mode. Tulad ng maaaring nahulaan mo, pinapayagan ka nitong suriin nang statically ang mga manifest ng Kubernetes.

Kapag tumatakbo sa command line mode, available ang mga built-in na pagsubok na sumasaklaw sa mga lugar gaya ng seguridad at pinakamahuhusay na kagawian (katulad ng kube-score). Bilang karagdagan, maaari kang lumikha ng iyong sariling mga pagsubok (tulad ng sa config-lint, tanso at conftest).

Sa madaling salita, pinagsasama ng Polaris ang mga benepisyo ng parehong kategorya ng mga tool: na may mga built-in at custom na pagsubok.

Upang i-install ang Polaris sa command line mode, gamitin mga tagubilin sa website ng proyekto.

Sa oras ng pagsulat ng orihinal na artikulo, ang bersyon 1.0.3 ay magagamit.

Kapag nakumpleto na ang pag-install maaari mong patakbuhin ang polaris sa manifest base-valid.yaml gamit ang sumusunod na utos:

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

Maglalabas ito ng string sa JSON na format na may detalyadong paglalarawan ng mga pagsubok na isinagawa at ang kanilang mga resulta. Ang output ay magkakaroon ng sumusunod na istraktura:

{
  "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": [
    /* Π΄Π»ΠΈΠ½Π½Ρ‹ΠΉ список */
  ]
}

Available ang buong output dito.

Tulad ng kube-score, kinikilala ng Polaris ang mga isyu sa mga lugar kung saan hindi natutugunan ng manifest ang pinakamahuhusay na kagawian:

  • Walang mga pagsusuri sa kalusugan para sa mga pod.
  • Ang mga tag para sa mga larawan ng lalagyan ay hindi tinukoy.
  • Ang lalagyan ay tumatakbo bilang ugat.
  • Ang mga kahilingan at limitasyon para sa memorya at CPU ay hindi tinukoy.

Ang bawat pagsubok, depende sa mga resulta nito, ay itinalaga ng antas ng pagiging kritikal: babala o panganib. Upang matuto nang higit pa tungkol sa mga available na built-in na pagsubok, mangyaring sumangguni sa dokumentasyon.

Kung ang mga detalye ay hindi kailangan, maaari mong tukuyin ang bandila --format score. Sa kasong ito, maglalabas ang Polaris ng isang numero mula 1 hanggang 100 βˆ’ puntos (ibig sabihin, pagtatasa):

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

Kung mas malapit ang marka sa 100, mas mataas ang antas ng kasunduan. Kung susuriin mo ang exit code ng command polaris audit, lumalabas na ito ay katumbas ng 0.

Puwersa polaris audit Maaari mong wakasan ang trabaho gamit ang non-zero code gamit ang dalawang flag:

  • I-flag --set-exit-code-below-score kumukuha bilang argumento ng halaga ng threshold sa hanay na 1-100. Sa kasong ito, lalabas ang command na may exit code 4 kung ang marka ay mas mababa sa threshold. Ito ay lubhang kapaki-pakinabang kapag mayroon kang isang tiyak na halaga ng threshold (sabihin ang 75) at kailangan mong makatanggap ng alerto kung mas mababa ang marka.
  • I-flag --set-exit-code-on-danger ay magiging sanhi ng pagbagsak ng utos sa code 3 kung ang isa sa mga pagsubok sa panganib ay nabigo.

Ngayon subukan nating gumawa ng custom na pagsubok na nagsusuri kung ang larawan ay kinuha mula sa isang pinagkakatiwalaang repositoryo. Ang mga custom na pagsubok ay tinukoy sa YAML na format, at ang pagsubok mismo ay inilalarawan gamit ang JSON Schema.

Ang sumusunod na YAML code snippet ay naglalarawan ng isang bagong pagsubok na tinatawag 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/.+$

Tingnan natin ito nang mas malapitan:

  • successMessage β€” ang linyang ito ay ipi-print kung matagumpay na makumpleto ang pagsubok;
  • failureMessage β€” ang mensaheng ito ay ipapakita kung sakaling mabigo;
  • category β€” nagsasaad ng isa sa mga kategorya: Images, Health Checks, Security, Networking ΠΈ Resources;
  • target--- tinutukoy kung anong uri ng bagay (spec) ang pagsubok ay inilapat. Mga posibleng halaga: Container, Pod o Controller;
  • Ang pagsubok mismo ay tinukoy sa bagay schema gamit ang JSON schema. Ang pangunahing salita sa pagsusulit na ito ay pattern ginagamit upang ihambing ang pinagmulan ng larawan sa kinakailangang isa.

Upang patakbuhin ang pagsubok sa itaas, kailangan mong gawin ang sumusunod na configuration ng Polaris:

checks:
  checkImageRepo: danger
customChecks:
  checkImageRepo:
    successMessage: Image registry is valid
    failureMessage: Image registry is not valid
    category: Images
    target: Container
    schema:
      '$schema': http://json-schema.org/draft-07/schema
      type: object
      properties:
        image:
          type: string
          pattern: ^my-company.com/.+$

(polaris-conf.yaml)

I-parse natin ang file:

  • Sa larangan checks ang mga pagsusulit at ang kanilang antas ng pagiging kritikal ay inireseta. Dahil kanais-nais na makatanggap ng babala kapag ang isang larawan ay kinuha mula sa isang hindi pinagkakatiwalaang pinagmulan, itinakda namin ang antas dito danger.
  • Ang pagsubok mismo checkImageRepo pagkatapos ay nakarehistro sa bagay customChecks.

I-save ang file bilang custom_check.yaml. Ngayon ay maaari kang tumakbo polaris audit na may YAML manifest na nangangailangan ng pag-verify.

Subukan natin ang ating manifesto base-valid.yaml:

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

Koponan polaris audit nagpatakbo lamang ng pagsubok ng gumagamit na tinukoy sa itaas at nabigo ito.

Kung ayusin mo ang imahe sa my-company.com/http-echo:1.0, Matagumpay na makukumpleto ang Polaris. Ang manifesto na may mga pagbabago ay nasa loob na mga repositoryopara masuri mo ang nakaraang command sa manifest image-valid-mycompany.yaml.

Ngayon ang tanong ay lumitaw: kung paano magpatakbo ng mga built-in na pagsubok kasama ng mga pasadya? Madali lang! Kailangan mo lang idagdag ang mga built-in na pantukoy na pagsubok sa configuration file. Bilang resulta, kukuha ito ng sumusunod na anyo:

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)

Available ang isang halimbawa ng kumpletong configuration file dito.

Suriin ang manifest base-valid.yamlgamit ang built-in at custom na mga pagsubok, maaari mong gamitin ang command:

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

Pinuno ng Polaris ang mga built-in na pagsubok gamit ang mga custom, at sa gayon ay pinagsasama ang pinakamahusay sa parehong mundo.

Sa kabilang banda, ang kawalan ng kakayahang gumamit ng mas makapangyarihang mga wika tulad ng Rego o JavaScript ay maaaring maging isang limitasyong salik na pumipigil sa paglikha ng mas sopistikadong mga pagsubok.

Higit pang impormasyon tungkol sa Polaris ay makukuha sa website ng proyekto.

Buod

Bagama't mayroong maraming tool na magagamit upang siyasatin at suriin ang mga Kubernetes YAML file, mahalagang magkaroon ng malinaw na pag-unawa sa kung paano idinisenyo at isasagawa ang mga pagsusulit.

Halimbawa, kung kukuha ka ng Kubernetes manifests na dumadaan sa pipeline, maaaring ang kubeval ang unang hakbang sa naturang pipeline. Susubaybayan nito kung ang mga kahulugan ng object ay sumusunod sa schema ng Kubernetes API.

Kapag nakumpleto na ang naturang pagsusuri, maaaring magpatuloy ang isa sa mas sopistikadong mga pagsubok, gaya ng pagsunod sa mga karaniwang pinakamahuhusay na kagawian at mga partikular na patakaran. Dito magagamit ang kube-score at Polaris.

Para sa mga may kumplikadong mga kinakailangan at kailangang i-customize ang mga pagsubok nang detalyado, ang tanso, config-lint at conftest ay magiging angkop.

Gumagamit ang Conftest at config-lint ng YAML upang tukuyin ang mga custom na pagsubok, at binibigyan ka ng tanso ng access sa isang buong programming language, na ginagawa itong medyo kaakit-akit na pagpipilian.

Sa kabilang banda, sulit ba ang paggamit ng isa sa mga tool na ito at, samakatuwid, ang paglikha ng lahat ng mga pagsubok nang manu-mano, o mas gusto ang Polaris at idagdag lamang ang kailangan dito? Walang malinaw na sagot sa tanong na ito.

Ang talahanayan sa ibaba ay nagbibigay ng maikling paglalarawan ng bawat tool:

Kasangkapan
Layunin
Mga hangganan
Mga pagsubok ng user

kubeval
Pinapatunayan ang mga manifest ng YAML laban sa isang partikular na bersyon ng schema ng API
Hindi gumana sa CRD
Hindi

kube-score
Sinusuri ang mga manifest ng YAML laban sa pinakamahuhusay na kagawian
Hindi mapili ang iyong bersyon ng Kubernetes API upang suriin ang mga mapagkukunan
Hindi

tanso
Isang pangkalahatang balangkas para sa paggawa ng mga custom na pagsubok sa JavaScript para sa mga manifest ng YAML
Walang mga built-in na pagsubok. Hindi magandang dokumentasyon
Oo

config-lint
Isang pangkalahatang balangkas para sa paggawa ng mga pagsubok sa isang wikang partikular sa domain na naka-embed sa YAML. Sinusuportahan ang iba't ibang mga format ng pagsasaayos (hal. Terraform)
Walang mga handa na pagsubok. Maaaring hindi sapat ang mga built-in na assertion at function
Oo

paligsahan
Isang balangkas para sa paglikha ng sarili mong mga pagsubok gamit ang Rego (isang espesyal na wika ng query). Nagbibigay-daan sa pagbabahagi ng mga patakaran sa pamamagitan ng mga bundle ng OCI
Walang mga built-in na pagsubok. Kailangan kong matuto ng Rego. Hindi sinusuportahan ang Docker Hub kapag nag-publish ng mga patakaran
Oo

Polaris
Mga review na ipinapakita ng YAML laban sa mga karaniwang pinakamahusay na kagawian. Binibigyang-daan kang lumikha ng sarili mong mga pagsubok gamit ang JSON Schema
Maaaring hindi sapat ang mga kakayahan sa pagsubok batay sa JSON Schema
Oo

Dahil ang mga tool na ito ay hindi umaasa sa access sa Kubernetes cluster, ang mga ito ay madaling i-install. Nagbibigay-daan sa iyo ang mga ito na i-filter ang mga source file at magbigay ng mabilis na feedback sa mga may-akda ng mga pull request sa mga proyekto.

PS mula sa tagasalin

Basahin din sa aming blog:

Pinagmulan: www.habr.com

Magdagdag ng komento