🥇Validasi Kubernetes YAML marang praktik lan kabijakan sing paling apik

Cathetan. nerjemahake.: Kanthi akeh konfigurasi YAML kanggo lingkungan K8s, perlu kanggo verifikasi otomatis sing dadi tambah urgent. Penulis review iki ora mung milih solusi sing wis ana kanggo tugas iki, nanging uga ndeleng cara kerjane nggunakake conto Deployment. Iku dadi banget informatif kanggo wong-wong sing kasengsem ing topik iki.

TL; DR: Artikel iki mbandhingake enem alat statis kanggo mriksa lan netepake file YAML Kubernetes nglawan praktik lan syarat sing paling apik.

Beban kerja Kubernetes biasane ditetepake ing wangun dokumen YAML. Salah sawijining masalah karo YAML yaiku angel nemtokake watesan utawa hubungan antarane file nyata.

Apa yen kita kudu mesthekake yen kabeh gambar sing dikirim menyang kluster asale saka pendaptaran sing dipercaya?

Pripun nyegah Deployments sing ora duwe PodDisruptionBudgets disetel kanggo dikirim menyang kluster?

Nggabungake tes statis ngidini sampeyan ngenali kesalahan lan nglanggar kabijakan ing awal proses pangembangan, saéngga nambah jaminan manawa definisi sumber daya bener lan aman, lan nambah kemungkinan beban kerja produksi bakal ngetutake praktik paling apik.

Ekosistem validasi statis Kubernetes YAML bisa dipérang dadi kategori ing ngisor iki:

validators API. Piranti ing kategori iki validasi manifest YAML marang syarat server API Kubernetes.
Tester sing wis siap. Piranti ing kategori iki dilengkapi tes sing wis siap kanggo keamanan, tundhuk karo praktik paling apik, lsp.
Validator khusus. Perwakilan saka kategori iki ngidini sampeyan nggawe tes khusus ing macem-macem basa, kayata Rego lan Javascript.

Ing artikel iki kita bakal njlèntrèhaké lan mbandhingaké enem alat beda:

kubeval;
kube-skor;
config-lint;
tembaga;
kontes;
polaris.

Inggih, ayo padha miwiti!

Priksa Penyebaran

Sadurunge miwiti mbandhingake alat kasebut, ayo nggawe sawetara dhasar kanggo nyoba.

Manifesto ing ngisor iki ngemot sawetara kasalahan lan inconsistencies karo praktik paling apik: pira sing bisa ditemokake?

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)

Kita bakal nggunakake YAML iki kanggo mbandhingake alat sing beda.

Manifesto ing ndhuwur base-valid.yaml lan manifesto liyane saka artikel iki bisa ditemokake ing Repositori Git.

Manifes nggambarake aplikasi web sing tugas utama kanggo nanggapi kanthi pesen "Hello World" ing port 5678. Bisa digunakake kanthi printah ing ngisor iki:

kubectl apply -f hello-world.yaml

Lan - mriksa karya:

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

Saiki pindhah menyang http://localhost:8080 lan konfirmasi manawa aplikasi kasebut bisa digunakake. Nanging apa ngetutake praktik paling apik? Ayo priksa.

1. Kubeval

Ing jantung kubeval punika idea sing sembarang interaksi karo Kubernetes kelakon liwat API REST sawijining. Ing tembung liyane, sampeyan bisa nggunakake skema API kanggo mriksa yen YAML diwenehi cocog. Ayo padha ndeleng conto.

instruksi instalasi kubeval kasedhiya ing situs web proyek.

Nalika nulis artikel asli, versi 0.15.0 kasedhiya.

Sawise diinstal, ayo diwenehi manifesto ing ndhuwur:

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

Yen sukses, kubeval bakal metu kanthi kode metu 0. Sampeyan bisa mriksa kaya ing ngisor iki:

$ echo $?
0

Saiki ayo nyoba kubeval kanthi manifes sing beda:

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)

Apa sampeyan bisa nemokake masalah kanthi mripat? Ayo mlaku:

$ 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

Sumber daya ora lulus verifikasi.

Panyebaran nggunakake versi API apps/v1, kudu kalebu pamilih sing cocog karo label pod. Manifest ing ndhuwur ora kalebu pamilih, mula kubeval nglaporake kesalahan lan metu nganggo kode non-nol.

Aku wonder apa bakal kelakon yen aku kubectl apply -f karo manifesto iki?

Inggih, ayo nyoba:

$ 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

Iki persis kesalahan sing dielingake kubeval. Sampeyan bisa ndandani kanthi nambah pamilih:

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)

Keuntungan saka alat kaya kubeval yaiku jinis kesalahan kasebut bisa dideteksi ing awal siklus penyebaran.

Kajaba iku, pamriksaan kasebut ora mbutuhake akses menyang kluster: bisa ditindakake kanthi offline.

Kanthi gawan, kubeval mriksa sumber daya marang skema API Kubernetes paling anyar. Nanging, ing sawetara kasus, sampeyan bisa uga pengin mriksa rilis Kubernetes tartamtu. Iki bisa ditindakake kanthi nggunakake gendera --kubernetes-version:

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

Wigati dimangerteni manawa versi kasebut kudu ditemtokake ing format kasebut Major.Minor.Patch.

Kanggo ndeleng dhaptar versi sing didhukung kanggo verifikasi, waca Skema JSON ing GitHub, sing digunakake kubeval kanggo validasi. Yen sampeyan kudu mbukak kubeval offline, download skema lan nemtokake lokasi lokal nggunakake gendera --schema-location.

Saliyane file YAML individu, kubeval uga bisa nggarap direktori lan stdin.

Kajaba iku, Kubeval bisa gampang digabungake menyang pipa CI. Sing pengin nganakake tes sadurunge ngirim manifests menyang kluster bakal seneng ngerti yen kubeval ndhukung telung format output:

Teks biasa;
JSON;
Test Anything Protocol (TAP).

Lan samubarang format bisa digunakake kanggo parsing luwih saka output kanggo generate ringkesan asil ing wangun dikarepake.

Salah sawijining kekurangan kubeval yaiku saiki ora bisa mriksa Definisi Sumber Daya Khusus (CRD). Nanging, sampeyan bisa ngatur kubeval nglirwakake wong-wong mau.

Kubeval minangka alat sing apik kanggo nguji lan ngevaluasi sumber daya; Nanging, kudu ditekanake yen lulus tes ora njamin manawa sumber kasebut tundhuk karo praktik paling apik.

Contone, nggunakake tag latest ing wadhah ora tundhuk karo praktik paling apik. Nanging, kubeval ora nganggep iki minangka kesalahan lan ora nglaporake. Yaiku, mriksa YAML kasebut bakal rampung tanpa bebaya.

Nanging apa yen sampeyan pengin ngevaluasi YAML lan ndeteksi pelanggaran kaya tag latest? Kepiye cara mriksa file YAML kanggo praktik paling apik?

2. Kube-skor

Kube-skor parses YAML manifests lan ngevaluasi marang tes dibangun ing. Tes kasebut dipilih adhedhasar rekomendasi keamanan lan praktik paling apik, kayata:

Mlaku wadhah minangka non-root.
Kasedhiya pamriksa kesehatan pod.
Nyetel panjalukan lan watesan sumber.

Adhedhasar asil tes, telung asil diterbitake: OK, PÈNGET и KRITIKAL.

Kube-skor bisa nyoba online utawa diinstal sacara lokal.

Nalika nulis artikel asli, versi paling anyar saka kube-skor yaiku 1.7.0.

Ayo nyoba ing manifesto kita. 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 ngliwati cek kubeval, dene kube-skor nuduhake cacat ing ngisor iki:

Priksa kesiapan ora dikonfigurasi.
Ora ana panjalukan utawa watesan kanggo sumber daya CPU lan memori.
Anggaran gangguan pod ora disetel.
Ora ana aturan kanggo orane sing kapisah (anti afinitas) kanggo nggedhekake aksesibilitas.
Wadhah kasebut mlaku ing ngisor oyod.

Iki kabeh minangka titik sing bener babagan kekurangan sing kudu ditanggulangi supaya Deployment luwih efisien lan dipercaya.

tim kube-score informasi output ing wangun diwaca karo Gawan kabeh Pelanggaran saka jinis PÈNGET и KRITIKAL, kang banget mbiyantu sak pembangunan.

Sing pengin nggunakake alat iki minangka bagean saka pipa CI bisa ngaktifake output sing luwih dikompres nggunakake gendera --output-format ci (ing kasus iki, tes kanthi asil uga ditampilake 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

Kaya kubeval, kube-skor ngasilake kode metu non-nol yen ana tes sing gagal. KRITIKAL. Sampeyan uga bisa ngaktifake pangolahan sing padha kanggo PÈNGET.

Sampeyan uga bisa mriksa sumber daya marang versi API beda (kaya ing kubeval). Nanging, informasi iki 'hardcoded' ing kube-skor dhewe: sampeyan ora bisa milih versi Kubernetes beda. Watesan iki bisa dadi masalah gedhe yen sampeyan pengin upgrade kluster utawa duwe sawetara klompok karo versi K8s beda.

elinga yen Wis ana masalah kanthi proposal kanggo ngleksanakake kesempatan iki.

Sampeyan bisa mangerteni sing luwih lengkap babagan kube-skor ing situs resmi.

tes kube-skor minangka alat sing apik kanggo ngleksanakake praktik paling apik, nanging kepiye yen sampeyan pengin ngganti tes utawa nambah aturan sampeyan dhewe? Sayange, sampeyan ora bisa nglakoni.

Kube-skor ora extensible: sampeyan ora bisa nambah kawicaksanan kanggo utawa ngapiki mau.

Yen sampeyan kudu nulis tes khusus kanggo mriksa kepatuhan karo kabijakan perusahaan, sampeyan bisa nggunakake salah siji saka papat alat ing ngisor iki: config-lint, copper, conftest, utawa polaris.

3. Config-lint

Config-lint minangka alat kanggo validasi YAML, JSON, Terraform, file konfigurasi CSV lan manifests Kubernetes.

Sampeyan bisa nginstal nggunakake instruksi ing situs web proyek.

Rilis saiki nalika nulis artikel asli yaiku 1.5.0.

Config-lint ora ngemot tes sing dibangun kanggo validasi manifes Kubernetes.

Kanggo nindakake tes apa wae, sampeyan kudu nggawe aturan sing cocog. Iki ditulis ing file YAML sing diarani "set aturan" (aturan), lan duwe struktur ing ngisor iki:

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

(rule.yaml)

Ayo dideleng kanthi cetha:

lapangan type nemtokake jinis konfigurasi config-lint apa sing bakal digunakake. Kanggo K8s manifests, iki tansah Kubernetes.
Ing lapangan files Saliyane file dhewe, sampeyan bisa nemtokake direktori.
lapangan rules dimaksudaké kanggo nyetel tes pangguna.

Contone, sampeyan pengin mesthekake yen gambar ing Deployment tansah diundhuh saka repositori sing dipercaya kaya my-company.com/myapp:1.0Aturan config-lint sing nindakake mriksa kaya iki:

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

Kanggo saben aturan, atribut ing ngisor iki kudu ditemtokake:

id - pengenal aturan unik;
severity - Bisa uga GAGAL, PÈNGET и NON_COMPLIANT;
message - yen aturan dilanggar, isi baris iki ditampilake;
resource - jinis sumber daya sing ditrapake aturan iki;
assertions - dhaptar kahanan sing bakal dievaluasi babagan sumber daya iki.

Ing aturan ndhuwur assertion miturut jeneng every mriksa manawa kabeh wadhah ing Deployment (key: spec.templates.spec.containers) nggunakake gambar sing dipercaya (yaiku, sing diwiwiti karo my-company.com/).

Aturan lengkap katon kaya iki:

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)

Kanggo nyoba tes, ayo simpen minangka check_image_repo.yaml. Ayo mriksa file kasebut 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"
  }
]

Priksa gagal. Saiki ayo mriksa manifest ing ngisor iki kanthi repositori gambar sing bener:

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)

Kita nindakake tes sing padha karo manifest ing ndhuwur. Ora ana masalah sing ditemokake:

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

Config-lint minangka kerangka kerja sing bakal teka sing ngidini sampeyan nggawe tes dhewe kanggo validasi Manifestasi YAML Kubernetes nggunakake YAML DSL.

Nanging kepiye yen sampeyan butuh logika lan tes sing luwih rumit? Apa YAML ora winates banget? Apa yen sampeyan bisa nulis tes ing basa pamrograman lengkap?

4. Tembaga

Tembaga V2 - minangka kerangka kanggo validasi manifests nggunakake tes khusus (padha karo config-lint).

Nanging, beda karo sing terakhir amarga ora nggunakake YAML kanggo njlèntrèhaké tes. Nanging, tes bisa ditulis ing JavaScript. Tembaga nyedhiyakake perpustakaan kanthi sawetara alat dhasar., sing mbantu maca informasi babagan obyek Kubernetes lan laporan kesalahan.

Urutan langkah-langkah kanggo nginstal Tembaga bisa ditemokake ing dokumentasi resmi.

2.0.1 minangka rilis paling anyar saka sarana iki nalika nulis artikel asli.

Kaya config-lint, Tembaga ora ana tes sing dibangun. Ayo nulis siji. Priksa manawa penyebaran nggunakake gambar wadhah khusus saka repositori sing dipercaya kaya my-company.com.

Nggawe file check_image_repo.js kanthi isi ing ngisor iki:

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

Saiki kanggo nyoba manifesto kita base-valid.yaml, nggunakake printah 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

Cetha yen tembaga bisa digunakake kanggo nindakake tes sing luwih rumit, kayata mriksa jeneng domain ing manifests Ingress utawa nolak pod sing mlaku ing mode istimewa.

Tembaga nduweni macem-macem fungsi utilitas sing dibangun:

DockerImage maca file input sing ditemtokake lan nggawe obyek kanthi atribut ing ngisor iki:
- name - jeneng gambar,
- tag - tag gambar,
- registry - registri gambar,
- registry_url - protokol (https://) lan registri gambar,
- fqin - lokasi lengkap gambar.
fungsi findByName mbantu nemokake sumber daya miturut jinis tartamtu (kind) lan jeneng (name) saka file input.
fungsi findByLabels mbantu nemokake sumber daya miturut jinis tartamtu (kind) lan tag (labels).

Kabeh fungsi layanan sing kasedhiya bisa ditemokake ing kene kene.

Kanthi gawan, ngemot kabeh file YAML input menyang variabel. $$ lan kasedhiya kanggo skrip (cara sing akrab kanggo sing ngalami jQuery).

Kauntungan utama Copper jelas: sampeyan ora perlu sinau basa khusus lan sampeyan bisa nggunakake macem-macem fitur JavaScript kanggo nggawe tes dhewe, kayata interpolasi string, fungsi, lsp.

Sampeyan uga kudu dicathet yen versi Tembaga saiki bisa digunakake karo versi ES5 saka mesin JavaScript, dudu ES6.

Details kasedhiya ing situs web proyek resmi.

Nanging, yen sampeyan dudu penggemar JavaScript lan luwih seneng basa sing dirancang khusus kanggo nggawe pitakon lan njlentrehake kabijakan, sampeyan kudu mriksa kontest.

5. Kontes

Conftest minangka kerangka kanggo mriksa data konfigurasi. Iku uga cocok kanggo testing / verifikasi manifests Kubernetes. Tes diterangake nggunakake basa pitakon khusus Rego.

Sampeyan bisa nginstal conftest nggunakake instruksi, kadhaptar ing situs web proyek.

Nalika nulis artikel asli, versi paling anyar sing kasedhiya yaiku 0.18.2.

Kaya config-lint lan tembaga, conftest teka tanpa tes dibangun ing. Ayo nyoba lan nulis kabijakan kita dhewe. Kaya ing conto sadurunge, kita bakal mriksa manawa gambar wadhah dijupuk saka sumber sing dipercaya.

Nggawe direktori conftest-checks, lan ing kono ana file jenenge check_image_registry.rego kanthi isi ing ngisor iki:

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

Saiki ayo nyoba base-valid.yaml liwat 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

Tes kasebut gagal kaya sing dikarepake amarga gambar kasebut asale saka sumber sing ora dipercaya.

Ing file Rego kita nemtokake blok deny. Bebenere dianggep minangka pelanggaran. Yen pamblokiran deny sawetara, conftest mriksa wong independen saka saben liyane, lan bebener samubarang pamblokiran dianggep minangka nerak.

Saliyane output standar, conftest ndhukung format JSON, TAP, lan tabel, sing minangka fitur sing migunani banget yen sampeyan kudu nglebokake laporan menyang pipa CI sing ana. Sampeyan bisa nyetel format sing dikarepake nggunakake gendera --output.

Kanggo nggawe kabijakan debugging luwih gampang, conftest duwe gendera --trace. Iki ngasilake jejak babagan carane conftest ngurai file kebijakan sing ditemtokake.

kabijakan conftest bisa diterbitake lan dituduhake ing OCI (Open Container Initiative) registri minangka artefak.

Tim push и pull ngidini sampeyan nerbitake artefak utawa narik artefak sing ana saka pendaptaran remot. Ayo coba nerbitake kabijakan sing digawe menyang registri Docker lokal nggunakake conftest push.

Miwiti registri Docker lokal:

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

Ing terminal liyane, pindhah menyang direktori sing digawe sadurunge conftest-checks lan jalanake printah ing ngisor iki:

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

Yen printah kasebut sukses, sampeyan bakal weruh pesen kaya iki:

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

Saiki gawe direktori sementara lan jalanake perintah kasebut conftest pull. Bakal ndownload paket sing digawe dening prentah sadurunge menyang:

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

Subdirektori bakal katon ing direktori sementara. policy, ngemot file kabijakan kita:

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

Tes bisa ditindakake langsung saka repositori:

$ 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

Sayange, DockerHub durung didhukung, mula nganggep awake dhewe begja yen sampeyan nggunakake Registry Wadhah Azure (ACR) utawa pendaptaran dhewe.

Format artefak padha karo Bukak paket Agen Kebijakan (OPA), sing ngidini conftest digunakake kanggo mbukak tes saka paket OPA ana.

Sampeyan bisa sinau luwih lengkap babagan enggo bareng kabijakan lan fitur kontes liyane ing situs web proyek resmi.

6. Polaris

Alat pungkasan sing bakal dibahas ing artikel iki yaiku Polaris. (Kita ndeleng pengumumane taun kepungkur wis dijarwakake - kira-kira. ngartekne)

Polaris bisa diinstal ing kluster utawa digunakake ing mode baris printah. Minangka sampeyan bisa uga wis guessed, ngijini sampeyan kanggo statis analisa Kubernetes manifests.

Nalika mlaku ing mode baris printah, ana tes dibangun ing nutupi wilayah kayata keamanan lan praktik paling apik (padha karo kube-skor), lan sampeyan uga bisa nggawe tes dhewe (padha config-lint, tembaga, lan conftest).

Kanthi tembung liyane, Polaris nggabungake kaluwihan saka rong kategori alat: tes sing dibangun lan khusus.

Kanggo nginstal Polaris ing mode baris printah, gunakake instruksi ing situs web project.

Nalika nulis artikel asli, versi 1.0.3 kasedhiya.

Sawise instalasi rampung, sampeyan bisa mbukak polaris ing manifest base-valid.yaml nggunakake printah ing ngisor iki:

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

Bakal ngasilake senar JSON kanthi katrangan rinci babagan tes sing ditindakake lan asile. Output bakal duwe struktur ing ngisor iki:

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

Output lengkap kasedhiya kene.

Kaya kube-skor, Polaris ngenali masalah ing wilayah sing manifes ora tundhuk karo praktik paling apik:

Ora ana pemeriksaan kesehatan pod.
Ora ana tag sing ditemtokake kanggo gambar wadhah.
Wadhah kasebut mlaku ing ngisor oyod.
Panjaluk lan watesan kanggo memori lan CPU ora ditemtokake.

Saben tes diwenehi tingkat kritis gumantung saka asile: bebaya utawa bebaya. Kanggo sinau luwih lengkap babagan tes sing kasedhiya, waca dokumentasi.

Yen rincian ora dibutuhake, gendéra bisa ditemtokake --format score. Ing kasus iki, Polaris bakal ngasilake nomer ing kisaran saka 1 nganti 100 - skor (yaiku penilaian):

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

Sing nyedhaki skor 100, sing luwih dhuwur tingkat kepatuhan. Yen sampeyan mriksa kode metu saka printah polaris audit, pranyata padha karo 0.

meksa polaris audit Sampeyan bisa metu nganggo kode non-nol nggunakake rong bendera:

Bendera --set-exit-code-below-score njupuk nilai ambang ing kisaran 1-100 minangka argumen. Ing kasus iki, printah bakal metu karo kode metu 4 yen skor ngisor batesan. Iki migunani banget nalika sampeyan duwe sawetara nilai batesan (ngomong, 75), lan sampeyan pengin njaluk tandha yen skor tiba ing ngisor iki.
Bendera --set-exit-code-on-danger bakal nimbulaké printah metu karo kode 3 yen salah siji saka tes bebaya gagal.

Saiki ayo nyoba nggawe tes khusus sing mriksa manawa gambar dijupuk saka gudang sing dipercaya. Tes khusus ditetepake ing format YAML, lan tes kasebut dhewe diterangake nggunakake Skema JSON.

Fragmen YAML ing ngisor iki nggambarake tes anyar sing diarani 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/.+$

Ayo dideleng kanthi cetha:

successMessage - baris iki bakal metu yen tes sukses;
failureMessage - pesen iki bakal ditampilake yen gagal;
category - nuduhake salah sawijining kategori: Images, Health Checks, Security, Networking и Resources;
target—- nemtokake jinis obyek (spec) tes ditrapake. Nilai sing bisa ditindakake: Container, Pod utawa Controller;
Tes kasebut dhewe ditemtokake ing obyek kasebut schema nggunakake skema JSON. Ing tes iki, tembung kunci pattern digunakake kanggo mbandhingake gambar sumber karo sing dikarepake.

Kanggo nindakake tes ing ndhuwur, sampeyan kudu nggawe konfigurasi Polaris ing ngisor iki:

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)

Ayo analisa file kasebut:

Ing lapangan checks tes lan tingkat kritisitas ditemtokake. Awit iku seng di pengeni kanggo nampa bebaya nalika gambar dijupuk saka sumber untrusted, kita nyetel tingkat kene danger.
Tes dhewe checkImageRepo banjur kadhaftar ing obyek customChecks.

Simpen file minangka custom_check.yaml. Saiki sampeyan bisa mlaku polaris audit karo manifest YAML sing mbutuhake verifikasi.

Ayo nyoba manifesto kita base-valid.yaml:

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

tim polaris audit Aku mung mbukak tes pangguna ing ndhuwur lan ora sukses.

Yen sampeyan mbenerake gambar ing my-company.com/http-echo:1.0, Polaris bakal rampung kanthi sukses. Manifesto kanthi owah-owahan wis ana repositori, supaya sampeyan bisa mriksa printah sadurunge ing manifest image-valid-mycompany.yaml.

Saiki pitakonan muncul: carane mbukak tes sing dibangun bebarengan karo tes pangguna? Gampang! Sampeyan mung kudu nambah ID test sing dibangun ing file konfigurasi. Akibaté, bakal katon kaya iki:

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)

Conto file konfigurasi lengkap kasedhiya kene.

Priksa manifest base-valid.yaml, nggunakake tes sing dibangun lan khusus, sampeyan bisa nggunakake printah:

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

Polaris nglengkapi tes sing dibangun kanthi tes khusus, menehi sampeyan sing paling apik ing loro-lorone.

Ing sisih liya, ora bisa nggunakake basa sing luwih kuat kayata Rego utawa JavaScript bisa dadi faktor watesan sing nyegah sampeyan nggawe tes sing luwih canggih.

Informasi tambahan babagan Polaris kasedhiya ing situs web proyek.

Ringkesan

Nalika ana akeh alat sing kasedhiya kanggo mriksa lan ngevaluasi file YAML Kubernetes, Penting kanggo duwe ide sing jelas babagan carane tes bakal dirancang lan dieksekusi.

Contone, yen sampeyan njupuk Manifes Kubernetes sing liwat pipa, kubeval bisa dadi langkah pisanan ing pipa kasebut. Iku bakal ngawasi apa definisi obyek tundhuk karo skema API Kubernetes.

Sawise mriksa iki rampung, kita bisa nerusake menyang tes sing luwih canggih, kayata tundhuk karo praktik paling apik standar lan kabijakan khusus. Iki ngendi kube-skor lan Polaris bakal teka ing Handy.

Kanggo sing duwe syarat rumit lan kudu nyempurnakake tes, tembaga, config-lint lan conftest bakal cocog..

Conftest lan config-lint nggunakake YAML kanggo nemtokake tes adat, lan tembaga menehi akses menyang basa program lengkap, dadi pilihan atraktif.

Ing sisih liya, sampeyan kudu nggunakake salah sawijining alat kasebut lan mulane nggawe kabeh tes kanthi manual, utawa sampeyan kudu milih Polaris lan mung nulis sing dibutuhake? Ora ana jawaban sing jelas kanggo pitakonan iki..

Tabel ing ngisor iki ngemot katrangan ringkes saben alat:

Instrumen
Tujuan
Kekurangan
Tes pangguna

kubeval
Validates YAML manifests marang versi skema API tartamtu
Ora bisa nggarap CRD
Ora

kube-skor
Nganalisa manifests YAML kanggo praktik paling apik
Ora bisa milih versi API Kubernetes kanggo mriksa sumber daya
Ora

tembaga
Kerangka umum kanggo nggawe tes JavaScript sampeyan dhewe kanggo manifests YAML
Ora ana tes sing dibangun. Dokumentasi sing ora apik.
Ya

config-lint
Kerangka umum kanggo nggawe tes ing basa khusus domain sing dipasang ing YAML. Ndhukung macem-macem format konfigurasi (eg Terraform)
Ora ana tes sing wis siap. Pernyataan lan fungsi sing dibangun bisa uga ora cukup
Ya

kontes
Kerangka kanggo nggawe tes dhewe ing Rego (basa pitakon khusus). Ngidini enggo bareng kabijakan liwat bundel OCI
Ora ana tes sing dibangun. Rego kudu sinau. Docker Hub ora didhukung nalika nerbitake kabijakan.
Ya

Polaris
Parses YAML diwujudake nglawan praktik paling apik standar. Ngidini sampeyan nggawe tes dhewe nggunakake Skema JSON
Tes adhedhasar skema JSON bisa uga ora cukup kuat
Ya

Amarga alat kasebut ora gumantung marang akses menyang kluster Kubernetes, gampang diinstal, ngidini file sumber disaring, lan menehi saran cepet kanggo narik panyuwunan penulis ing proyek.