Validasi Kubernetes YAML marang praktik lan kabijakan sing paling apik

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

TL; DR: Artikel iki mbandhingake enem alat statis kanggo validasi lan ngevaluasi 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?

Kadospundi kula saged nyegah Deployments sing ora duwe PodDisruptionBudgets dikirim menyang kluster?

Integrasi tes statis ngidini sampeyan ngenali kesalahan lan pelanggaran kebijakan ing tahap pangembangan. Iki nambah jaminan manawa definisi sumber daya wis bener lan aman, lan luwih akeh manawa beban kerja produksi bakal ngetutake praktik paling apik.

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

• validators API. Piranti ing kategori iki mriksa manifest YAML miturut syarat server API Kubernetes.
• Tester siap. Piranti saka 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, contone, Rego lan Javascript.

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

1. kubeval;
2. kube-skor;
3. config-lint;
4. tembaga;
5. kontes;
6. polaris.

Inggih, ayo padha miwiti!

Priksa Penyebaran

Sadurunge miwiti mbandhingake alat, ayo nggawe sawetara latar mburi kanggo nyoba.

Manifesto ing ngisor iki ngemot sawetara kesalahan lan ora netepi 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 kasebut nggambarake aplikasi web sing tugas utama yaiku nanggapi kanthi pesen "Hello World" menyang port 5678. Bisa disebarake kanthi prentah 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 Ide kasebut yaiku manawa interaksi karo Kubernetes dumadi liwat API REST. Kanthi tembung liyane, sampeyan bisa nggunakake skema API kanggo mriksa apa YAML sing diwenehake cocog karo iku. Ayo katon ing conto.

instruksi instalasi kubeval kasedhiya ing situs web proyek.

Nalika nulis artikel asli, versi 0.15.0 kasedhiya.

Sawise diinstal, ayo diwenehi tandha 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 diluncurake:

$ 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 diverifikasi.

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 kesalahan kaya iki 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 kudu 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 dhaptar versi sing didhukung 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 gampang nggabungake menyang pipa CI. Sing pengin nganakake tes sadurunge ngirim manifests menyang kluster bakal seneng ngerti yen kubeval ndhukung telung format output:

1. Teks biasa;
2. JSON;
3. Test Anything Protocol (TAP).

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

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

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

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

Nanging apa yen sampeyan pengin ngevaluasi YAML lan ngenali pelanggaran kaya tag latest? Kepiye carane mriksa file YAML babagan praktik paling apik?

2. Kube-skor

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

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

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

Sampeyan bisa nyoba Kube-skor online utawa nginstal sacara lokal.

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

Ayo nyoba metu ing manifest 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 lulus tes kubeval, dene kube-skor nuduhake cacat ing ngisor iki:

• Priksa kesiapan ora dikonfigurasi.
• Ora ana panjalukan utawa watesan kanggo sumber daya lan memori CPU.
• Anggaran gangguan pod ora ditemtokake.
• Ora ana aturan pemisahan (anti afinitas) kanggo nggedhekake kasedhiyan.
• Wadhah kasebut mlaku minangka root.

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

tim kube-score nampilake informasi ing wangun sing bisa diwaca manungsa kalebu kabeh jinis pelanggaran PÈNGET и KRITIKAL, sing mbantu akeh sajrone pembangunan.

Sing pengin nggunakake alat iki ing 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-score ngasilake kode metu non-nol nalika ana tes sing gagal KRITIKAL. Sampeyan uga bisa ngaktifake pangolahan sing padha kanggo PÈNGET.

Kajaba iku, iku bisa kanggo mriksa sumber daya kanggo tundhuk karo versi API beda (kaya ing kubeval). Nanging, informasi iki hardcoded ing kube-skor dhewe: sampeyan ora bisa milih versi liyane saka Kubernetes. Watesan iki bisa dadi masalah gedhe yen sampeyan pengin nganyarke kluster utawa yen sampeyan duwe sawetara klompok kanthi versi K8 sing beda.

elinga yen wis ana masalah kanthi proposal kanggo mujudake kesempatan iki.

Informasi liyane babagan kube-skor bisa ditemokaké ing situs resmi.

Tes Kube-skor minangka alat sing apik kanggo ngleksanakake praktik paling apik, nanging kepiye yen sampeyan kudu ngowahi tes kasebut utawa nambah aturan sampeyan dhewe? Sayange, iki ora bisa ditindakake.

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

Yen sampeyan kudu nulis tes khusus kanggo verifikasi 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 duwe 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 "aturan" (aturan), lan duwe struktur ing ngisor iki:

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

(rule.yaml)

Ayo sinau kanthi luwih 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.0. Aturan 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)

Saben aturan kudu nduweni atribut ing ngisor iki:

• id - pengenal unik saka aturan;
• 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 ing hubungane karo 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 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 metu test, ayo kang nyimpen 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 janji 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 kanggo iki? Apa yen sampeyan bisa nggawe 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. Tes bisa ditulis ing JavaScript tinimbang. Tembaga nyedhiyakake perpustakaan kanthi sawetara alat dhasar, sing mbantu sampeyan maca informasi babagan obyek Kubernetes lan laporan kesalahan.

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 duwe tes dibangun ing. 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 manifest 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 kanthi bantuan tembaga sampeyan bisa nindakake tes sing luwih rumit - umpamane, mriksa jeneng domain ing manifests Ingress utawa nolak pod sing mlaku ing mode istimewa.

Tembaga nduweni macem-macem fungsi utilitas sing dibangun ing:

• 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 kanthi jinis tartamtu (kind) lan label (labels).

Sampeyan bisa ndeleng kabeh fungsi layanan sing kasedhiya kene.

Kanthi gawan, mbukak kabeh file YAML input menyang variabel $$ lan kasedhiya kanggo scripting (teknik menowo kanggo sing duwe pengalaman jQuery).

Kauntungan utama Copper jelas: sampeyan ora perlu nguwasani 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.

Rincian kasedhiya ing situs web proyek resmi.

Nanging, yen sampeyan ora seneng karo JavaScript lan luwih seneng basa sing dirancang khusus kanggo nggawe pitakon lan njlentrehake kabijakan, sampeyan kudu menehi perhatian marang kontest.

5. Kontes

Conftest minangka kerangka kanggo nguji data konfigurasi. Uga cocog kanggo nyoba / verifikasi manifests Kubernetes. Tes diterangake nggunakake basa pitakon khusus Rego.

Sampeyan bisa nginstal conftest nggunakake instruksikadhaptar 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 bisa 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 bisa diramal gagal amarga gambar kasebut asale saka sumber sing ora dipercaya.

Ing file Rego kita nemtokake pamblokiran deny. Bebenere dianggep nglanggar. 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 - fitur sing migunani banget yen sampeyan kudu nglebokake laporan menyang pipa CI sing wis ana. Sampeyan bisa nyetel format sing dikarepake nggunakake gendera --output.

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

Kabijakan kontes bisa diterbitake lan dituduhake ing registri OCI (Open Container Initiative) minangka artefak.

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

Miwiti registri Docker lokal sampeyan:

$ 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:

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

Subdirektori bakal katon ing direktori sementara policyngemot 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. Dadi nimbang dhewe begja yen sampeyan nggunakake Registry Wadhah Azure (ACR) utawa pendaptaran dhewe.

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

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

6. Polaris

Alat pungkasan sing bakal dibahas ing artikel iki yaiku Polaris. (Pengumuman taun kepungkur kita 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, kasedhiya tes dibangun ing nutupi wilayah kayata keamanan lan praktik paling apik (padha karo kube-skor). Kajaba iku, sampeyan bisa nggawe tes dhewe (kaya ing config-lint, tembaga lan conftest).

Kanthi tembung liyane, Polaris nggabungake keuntungan saka rong kategori alat: kanthi 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 kanthi printah ing ngisor iki:

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

Bakal ngasilake senar ing format 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 cocog karo praktik paling apik:

• Ora ana pemeriksaan kesehatan kanggo polong.
• Tag kanggo gambar wadhah ora ditemtokake.
• Wadhah kasebut mlaku minangka root.
• Panjaluk lan watesan kanggo memori lan CPU ora ditemtokake.

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

Yen rincian ora dibutuhake, sampeyan bisa nemtokake gendera --format score. Ing kasus iki, Polaris bakal ngasilake angka 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 persetujuan. Yen sampeyan mriksa kode metu saka printah polaris audit, pranyata padha karo 0.

meksa polaris audit Sampeyan bisa mungkasi karya kanthi kode non-nol nggunakake rong bendera:

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

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

Cuplikan kode 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 dicithak yen tes rampung kasil;
• failureMessage — pesen iki bakal ditampilake ing cilik saka 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. Tembung kunci ing tes iki yaiku pattern digunakake kanggo mbandhingake sumber gambar karo sing dibutuhake.

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 parsing file kasebut:

• Ing lapangan checks tes lan tingkat kritisitas wis diwènèhaké. 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 mung mbukak tes pangguna sing kasebut ing ndhuwur lan gagal.

Yen sampeyan ndandani gambar kanggo my-company.com/http-echo:1.0, Polaris bakal rampung kanthi sukses. Manifesto kanthi owah-owahan wis ana repositorisupaya sampeyan bisa mriksa printah sadurungé ing manifest image-valid-mycompany.yaml.

Saiki pitakonan muncul: carane mbukak tes sing dibangun bebarengan karo sing khusus? Gampang! Sampeyan mung kudu nambah pengenal test sing dibangun ing file konfigurasi. Akibaté, bakal njupuk formulir ing ngisor 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.yamlnggunakake 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, saéngga nggabungake 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 nggawe tes sing luwih canggih.

Informasi liyane babagan Polaris kasedhiya ing situs web proyek.

Ringkesan

Nalika ana akeh alat sing kasedhiya kanggo mriksa lan ngevaluasi file YAML Kubernetes, iku penting kanggo duwe pangerten cetha carane tes bakal dirancang lan kaleksanan.

Contone, yen sampeyan njupuk Kubernetes manifests arep liwat pipa, kubeval bisa dadi langkah pisanan ing pipeline kuwi. Bakal ngawasi apa definisi obyek cocog karo skema API Kubernetes.

Sawise review kasebut rampung, siji bisa pindhah 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 ngatur tes kanthi rinci, 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, nggawe pilihan cantik atraktif.

Ing sisih liya, apa gunane nggunakake salah sawijining alat kasebut lan, mula, nggawe kabeh tes kanthi manual, utawa luwih seneng Polaris lan mung nambah apa sing dibutuhake? Ora ana jawaban sing jelas kanggo pitakonan iki.

Tabel ing ngisor iki menehi katrangan ringkes saben alat:

Instrumen
Tujuan
Kekurangan
Tes pangguna

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

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

tembaga
Kerangka umum kanggo nggawe tes JavaScript khusus kanggo manifes 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 nggunakake Rego (basa pitakon khusus). Ngidini enggo bareng kabijakan liwat bundel OCI
Ora ana tes sing dibangun. Aku kudu sinau Rego. Docker Hub ora didhukung nalika nerbitake kabijakan
Ya

Polaris
Review YAML diwujudake nglawan praktik paling apik standar. Ngidini sampeyan nggawe tes dhewe nggunakake Skema JSON
Kapabilitas tes adhedhasar Skema JSON bisa uga ora cukup
Ya

Amarga alat kasebut ora ngandelake akses menyang kluster Kubernetes, piranti kasebut gampang diinstal. Padha ngijini sampeyan kanggo nyaring file sumber lan menehi saran cepet kanggo penulis panjalukan narik ing proyèk.

PS saka penerjemah

Waca uga ing blog kita:

• «Polaris ngenalaken supaya kluster Kubernetes tetep sehat";
• «Vim kanthi dhukungan YAML kanggo Kubernetes";
• «7 praktik paling apik kanggo nggunakake wadhah miturut Google".

Source: www.habr.com