ProHoster > Blogs > Administrācija > Apstipriniet Kubernetes YAML paraugpraksi un politiku

Apstipriniet Kubernetes YAML paraugpraksi un politiku

PiezÄ«me. tulk.: pieaugot K8s vidēm paredzēto YAML konfigurāciju skaitam, nepiecieÅ”amÄ«ba pēc to automātiskās verifikācijas kļūst arvien aktuālāka. Å Ä« pārskata autors ne tikai atlasÄ«ja Å”im uzdevumam esoÅ”us risinājumus, bet arÄ« izmantoja izvietoÅ”anu kā piemēru, lai redzētu, kā tie darbojas. Tas izrādÄ«jās ļoti informatÄ«vs tiem, kurus interesē Ŕī tēma.

Apstipriniet Kubernetes YAML paraugpraksi un politiku

TL; DR: Å ajā rakstā ir salÄ«dzināti seÅ”i statiskie rÄ«ki, lai pārbaudÄ«tu un novērtētu Kubernetes YAML failus, ņemot vērā labāko praksi un prasÄ«bas.

Kubernetes darba slodzes parasti tiek noteiktas YAML dokumentu veidā. Viena no YAML problēmām ir grūtības norādīt ierobežojumus vai attiecības starp manifesta failiem.

Ko darīt, ja mums ir jāpārliecinās, ka visi klasterī izvietotie attēli nāk no uzticama reģistra?

Kā es varu novērst to izvietojumu, kuriem nav PodDisruptionBudgets, nosÅ«tÄ«Å”anu uz kopu?

Statiskās testÄ“Å”anas integrācija ļauj identificēt kļūdas un politikas pārkāpumus izstrādes stadijā. Tas palielina garantiju, ka resursu definÄ«cijas ir pareizas un droÅ”as, un palielina iespēju, ka ražoÅ”anas darba slodzes tiks ievērotas paraugprakses veidā.

Kubernetes statisko YAML failu pārbaudes ekosistēmu var iedalÄ«t Ŕādās kategorijās:

  • API pārbaudÄ«tāji. Å Ä«s kategorijas rÄ«ki pārbauda YAML manifesta atbilstÄ«bu Kubernetes API servera prasÄ«bām.
  • Gatavi testētāji. Å Ä«s kategorijas rÄ«kiem ir gatavi droŔības, atbilstÄ«bas paraugprakses testi utt.
  • Pielāgoti pārbaudÄ«tāji. Å Ä«s kategorijas pārstāvji ļauj izveidot pielāgotus testus dažādās valodās, piemēram, Rego un Javascript.

Å ajā rakstā mēs aprakstÄ«sim un salÄ«dzināsim seÅ”us dažādus rÄ«kus:

  1. kubeval;
  2. kube-score;
  3. config-lint;
  4. vara;
  5. konkurss;
  6. polaris.

Nu ko, sāksim!

Izvietojumu pārbaude

Pirms sākam salīdzināt rīkus, izveidosim pamatinformāciju, lai tos pārbaudītu.

Tālāk esoŔajā manifestā ir vairākas kļūdas un neatbilstība paraugpraksei: cik no tām varat atrast?

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)

Mēs izmantosim Å”o YAML, lai salÄ«dzinātu dažādus rÄ«kus.

IepriekÅ” minētais manifests base-valid.yaml un citus manifestus no Ŕī raksta var atrast Git krātuves.

Manifestā ir aprakstÄ«ta tÄ«mekļa lietojumprogramma, kuras galvenais uzdevums ir atbildēt ar ziņojumu ā€œHello Worldā€ uz portu 5678. To var izvietot ar Ŕādu komandu:

kubectl apply -f hello-world.yaml

Un tā - pārbaudiet darbu:

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

Tagad ejiet uz http://localhost:8080 un apstipriniet, ka lietojumprogramma darbojas. Bet vai tas atbilst paraugpraksei? Pārbaudīsim.

1. Kubeval

Pie sirds kubeval Ideja ir tāda, ka jebkura mijiedarbība ar Kubernetes notiek, izmantojot tā REST API. Citiem vārdiem sakot, varat izmantot API shēmu, lai pārbaudītu, vai dotā YAML tai atbilst. Apskatīsim piemēru.

UzstādÄ«Å”anas instrukcijas kubeval ir pieejami projekta tÄ«mekļa vietnē.

Sākotnējā raksta rakstÄ«Å”anas laikā bija pieejama versija 0.15.0.

Kad tas ir instalēts, ievadÄ«sim to iepriekÅ” norādÄ«tajā manifestā:

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

Ja tas būs veiksmīgs, kubeval izies ar izejas kodu 0. Varat to pārbaudīt Ŕādi:

$ echo $?
0

Tagad izmēģināsim kubeval ar citu manifestu:

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)

Vai varat pamanīt problēmu ar aci? Sāksim:

$ 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

Resurss netiek pārbaudīts.

Izvietojumi, izmantojot API versiju apps/v1, ir jāiekļauj atlasÄ«tājs, kas atbilst aplikuma apzÄ«mējumam. IepriekÅ” minētajā manifestā nav iekļauts atlasÄ«tājs, tāpēc kubeval ziņoja par kļūdu un izgāja ar kodu, kas nav nulle.

Interesanti, kas notiks, ja es to darīŔu kubectl apply -f ar Ŕo manifestu?

Nu, mēģināsim:

$ 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

TieŔi par Ŕo kļūdu brīdināja Kubeval. Varat to labot, pievienojot atlasītāju:

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)

Tādu rÄ«ku kā kubeval priekÅ”rocÄ«ba ir tāda, ka Ŕādas kļūdas var konstatēt jau izvietoÅ”anas cikla sākumā.

Turklāt Ŕīm pārbaudēm nav nepiecieÅ”ama piekļuve klasterim; tās var veikt bezsaistē.

Pēc noklusējuma kubeval pārbauda resursus saskaņā ar jaunāko Kubernetes API shēmu. Tomēr vairumā gadÄ«jumu jums var bÅ«t nepiecieÅ”ams pārbaudÄ«t, vai tas atbilst konkrētam Kubernetes laidienam. To var izdarÄ«t, izmantojot karogu --kubernetes-version:

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

Lūdzu, ņemiet vērā, ka versija ir jānorāda formātā Major.Minor.Patch.

To versiju sarakstu, kurām tiek atbalstÄ«ta verifikācija, lÅ«dzu, skatiet JSON shēma vietnē GitHub, ko kubeval izmanto apstiprināŔanai. Ja jums ir nepiecieÅ”ams palaist kubeval bezsaistē, lejupielādējiet shēmas un norādiet to vietējo atraÅ”anās vietu, izmantojot karogu --schema-location.

Papildus atseviŔķiem YAML failiem kubeval var strādāt arī ar direktorijiem un stdin.

Turklāt Kubeval viegli integrējas CI cauruļvadā. Tie, kas vēlas veikt testus pirms manifestu nosÅ«tÄ«Å”anas klasterim, bÅ«s priecÄ«gi uzzināt, ka kubeval atbalsta trÄ«s izvades formātus:

  1. VienkārŔs teksts;
  2. JSON;
  3. Test Anything Protocol (TAP).

Un jebkuru no formātiem var izmantot turpmākai izvades parsÄ“Å”anai, lai izveidotu vajadzÄ«gā veida rezultātu kopsavilkumu.

Viens no kubeval trÅ«kumiem ir tas, ka tas paÅ”laik nevar pārbaudÄ«t atbilstÄ«bu pielāgotajām resursu definÄ«cijām (CRD). Tomēr ir iespējams konfigurēt kubeval ignorēt tos.

Kubeval ir lielisks lÄ«dzeklis resursu pārbaudei un novērtÄ“Å”anai; Tomēr jāuzsver, ka testa nokārtoÅ”ana negarantē, ka resurss atbilst labākajai praksei.

Piemēram, izmantojot tagu latest konteinerā neievēro labāko praksi. Tomēr kubeval neuzskata to par kļūdu un neziņo par to. Tas nozÄ«mē, ka Ŕāda YAML pārbaude tiks pabeigta bez brÄ«dinājumiem.

Bet ko darīt, ja vēlaties novērtēt YAML un noteikt pārkāpumus, piemēram, tagu latest? Kā pārbaudīt, vai YAML fails atbilst paraugpraksei?

2. Kube-rezultāts

Kube-rezultāts parsē YAML manifestus un novērtē tos, salÄ«dzinot ar iebÅ«vētajiem testiem. Å ie testi ir atlasÄ«ti, pamatojoties uz droŔības vadlÄ«nijām un labāko praksi, piemēram:

  • Palaižot konteineru nevis kā root.
  • Pāksts veselÄ«bas pārbaužu pieejamÄ«ba.
  • Resursu pieprasÄ«jumu un ierobežojumu iestatÄ«Å”ana.

Pamatojoties uz testa rezultātiem, tiek doti trÄ«s rezultāti: OK, BRÄŖDINĀJUMS Šø KRITISKS.

Varat izmēģināt Kube-score tieÅ”saistē vai instalēt to lokāli.

Sākotnējā raksta rakstÄ«Å”anas laikā jaunākā kube-score versija bija 1.7.0.

Izmēģināsim to mūsu 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.

YAML iztur kubeval testus, savukārt kube-score norāda uz Ŕādiem trūkumiem:

  • GatavÄ«bas pārbaudes nav konfigurētas.
  • CPU resursiem un atmiņai nav pieprasÄ«jumu vai ierobežojumu.
  • Pod traucējumu budžeti nav norādÄ«ti.
  • AtdalÄ«Å”anas noteikumu nav (pretafinitāte) lai maksimāli palielinātu pieejamÄ«bu.
  • Konteiners darbojas kā root.

Tie visi ir derÄ«gi punkti par trÅ«kumiem, kas jānovērÅ”, lai padarÄ«tu izvietoÅ”anu efektÄ«vāku un uzticamāku.

Komanda kube-score parāda informāciju cilvēkiem salasāmā formā, tostarp visus veidu pārkāpumus BRÄŖDINĀJUMS Šø KRITISKS, kas ļoti palÄ«dz attÄ«stÄ«bas gaitā.

Tie, kas vēlas izmantot Å”o rÄ«ku CI konveijerā, var iespējot vairāk saspiestu izvadi, izmantojot karogu --output-format ci (Å”ajā gadÄ«jumā tiek parādÄ«ti arÄ« testi ar rezultātu 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

LÄ«dzÄ«gi kā kubeval, kube-score atgriež izejas kodu, kas nav nulle, ja ir tests, kas neizdodas KRITISKS. Varat arÄ« iespējot lÄ«dzÄ«gu apstrādi BRÄŖDINĀJUMS.

Turklāt ir iespējams pārbaudÄ«t resursu atbilstÄ«bu dažādām API versijām (kā kubeval). Tomēr Ŕī informācija ir iekodēta paŔā kube-score: jÅ«s nevarat atlasÄ«t citu Kubernetes versiju. Å is ierobežojums var bÅ«t liela problēma, ja plānojat jaunināt savu kopu vai ja jums ir vairāki klasteri ar dažādām K8 versijām.

LÅ«dzu, ņemiet vērā, ka jau ir problēma ar priekÅ”likumu Å”o iespēju realizēt.

PlaŔāku informāciju par kube-score var atrast vietnē oficiālā vietne.

Kube-score testi ir lielisks rÄ«ks paraugprakses ievieÅ”anai, bet ko darÄ«t, ja jums ir jāveic izmaiņas testā vai jāpievieno savi noteikumi? Diemžēl to nevar izdarÄ«t.

Kube-score nav paplaŔināms: jūs nevarat tam pievienot politikas vai pielāgot tās.

Ja jums ir jāraksta pielāgoti testi, lai pārbaudÄ«tu atbilstÄ«bu uzņēmuma politikām, varat izmantot vienu no Å”iem četriem rÄ«kiem: config-lint, copper, conftest vai polaris.

3. Config-lint

Config-lint ir rīks YAML, JSON, Terraform, CSV konfigurācijas failu un Kubernetes manifestu apstiprināŔanai.

Jūs varat to instalēt, izmantojot instrukcijas projekta mājaslapā.

PaÅ”reizējais laidiens uz oriÄ£inālā raksta rakstÄ«Å”anas brÄ«di ir 1.5.0.

Programmā Config-lint nav iebÅ«vētu testu Kubernetes manifestu apstiprināŔanai.

Lai veiktu jebkādus testus, jums ir jāizveido atbilstoŔi noteikumi. Tie ir rakstīti YAML failos, ko sauc par "rulesets" (noteikumu kopas), un tiem ir Ŕāda struktūra:

version: 1
description: Rules for Kubernetes spec files
type: Kubernetes
files:
  - "*.yaml"
rules:
   # сŠæŠøсŠ¾Šŗ ŠæрŠ°Š²ŠøŠ»

(rule.yaml)

Izpētīsim to tuvāk:

  • Lauks type norāda, kāda veida konfigurācija tiks izmantota config-lint. AttiecÄ«bā uz K8s tas izpaužas vienmēr Kubernetes.
  • Å ajā jomā files Papildus paÅ”iem failiem varat norādÄ«t direktoriju.
  • Lauks rules paredzēts lietotāju testu iestatÄ«Å”anai.

Pieņemsim, ka vēlaties pārliecināties, ka izvietoÅ”anas attēli vienmēr tiek lejupielādēti no uzticamas krātuves, piemēram, my-company.com/myapp:1.0. Konfigurācijas lÄ«nijas kārtula, kas veic Ŕādu pārbaudi, izskatÄ«tos Ŕādi:

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

Katram noteikumam ir jābūt Ŕādiem atribūtiem:

  • id ā€” noteikuma unikālais identifikators;
  • severity - Var bÅ«t Neveiksmes, BRÄŖDINĀJUMS Šø NEATTIECAS;
  • message ā€” ja tiek pārkāpts noteikums, tiek parādÄ«ts Ŕīs rindas saturs;
  • resource ā€” resursa veids, uz kuru attiecas Å”is noteikums;
  • assertions ā€” nosacÄ«jumu saraksts, kas tiks izvērtēti saistÄ«bā ar Å”o resursu.

IepriekÅ” minētajā noteikumā assertion aicināja every pārbauda, ā€‹ā€‹vai visi konteineri ir izvietoÅ”anā (key: spec.templates.spec.containers) izmantojiet uzticamus attēlus (t.i., sākot ar my-company.com/).

Pilns noteikumu kopums izskatās Ŕādi:

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)

Lai izmēģinātu testu, saglabāsim to kā check_image_repo.yaml. Pārbaudīsim failu 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"
  }
]

Pārbaude neizdevās. Tagad apskatÄ«sim Å”o manifestu ar pareizo attēlu repozitoriju:

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)

Mēs izpildām to paÅ”u testu ar iepriekÅ” minēto manifestu. Problēmas nav atrastas:

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

Config-lint ir daudzsoloŔs ietvars, kas ļauj jums izveidot savus testus, lai apstiprinātu Kubernetes YAML manifestus, izmantojot YAML DSL.

Bet ko darÄ«t, ja jums ir nepiecieÅ”ama sarežģītāka loÄ£ika un testi? Vai YAML nav pārāk ierobežots Å”im nolÅ«kam? Ko darÄ«t, ja jÅ«s varētu izveidot testus pilnā programmÄ“Å”anas valodā?

4. Vara

Vara V2 ir ietvars manifestu apstiprināŔanai, izmantojot pielāgotus testus (līdzīgi kā config-lint).

Tomēr tas atŔķiras no pēdējā ar to, ka testu aprakstÄ«Å”anai neizmanto YAML. Tā vietā testus var rakstÄ«t JavaScript. Copper nodroÅ”ina bibliotēku ar vairākiem pamata rÄ«kiem, kas palÄ«dz lasÄ«t informāciju par Kubernetes objektiem un ziņot par kļūdām.

Vara instalÄ“Å”anas darbÄ«bas var atrast Å”eit oficiālā dokumentācija.

2.0.1 ir Ŕīs utilÄ«tas jaunākā versija sākotnējā raksta rakstÄ«Å”anas laikā.

Tāpat kā config-lint, arÄ« Copper nav iebÅ«vētu testu. UzrakstÄ«sim vienu. Ä»aujiet tai pārbaudÄ«t, vai izvietoÅ”anā tiek izmantoti konteinera attēli tikai no uzticamiem repozitorijiem, piemēram my-company.com.

Izveidojiet failu check_image_repo.js ar Ŕādu saturu:

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

Tagad, lai pārbaudītu mūsu manifestu base-valid.yaml, izmantojiet komandu 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

Skaidrs, ka ar vara palÄ«dzÄ«bu var veikt sarežģītākus testus ā€“ piemēram, pārbaudÄ«t domēna vārdus Ingress manifestos vai noraidÄ«t priviliģētajā režīmā strādājoÅ”us podiņus.

Varam ir iebūvētas dažādas lietderības funkcijas:

  • DockerImage nolasa norādÄ«to ievades failu un izveido objektu ar Ŕādiem atribÅ«tiem:
    • name - attēla nosaukums,
    • tag - attēla atzÄ«me,
    • registry - attēlu reÄ£istrs,
    • registry_url - protokols (https://) un attēlu reÄ£istrs,
    • fqin ā€” pilna attēla atraÅ”anās vieta.
  • Funkcija findByName palÄ«dz atrast resursu pēc noteikta veida (kind) un vārds (name) no ievades faila.
  • Funkcija findByLabels palÄ«dz atrast resursu pēc noteikta veida (kind) un etiÄ·etes (labels).

Varat apskatīt visas pieejamās pakalpojumu funkcijas Ŕeit.

Pēc noklusējuma tas ielādē visu YAML ievades failu mainÄ«gajā $$ un padara to pieejamu skriptÄ“Å”anai (pazÄ«stama tehnika tiem, kam ir jQuery pieredze).

Galvenā Copper priekÅ”rocÄ«ba ir acÄ«mredzama: jums nav jāapgÅ«st specializēta valoda, un jÅ«s varat izmantot dažādas JavaScript funkcijas, lai izveidotu savus testus, piemēram, virkņu interpolāciju, funkcijas utt.

Jāpiebilst arÄ«, ka paÅ”reizējā Copper versija darbojas ar JavaScript dzinēja ES5 versiju, nevis ES6.

Sīkāka informācija pieejama vietnē oficiālā projekta vietne.

Tomēr, ja jums nepatÄ«k JavaScript un dodat priekÅ”roku valodai, kas Ä«paÅ”i izstrādāta vaicājumu izveidei un politiku aprakstÄ«Å”anai, jums vajadzētu pievērst uzmanÄ«bu conftest.

5.Konkurss

Conftest ir konfigurācijas datu testÄ“Å”anas sistēma. Piemērots arÄ« Kubernetes manifestu testÄ“Å”anai/pārbaudÄ«Å”anai. Pārbaudes tiek aprakstÄ«tas, izmantojot specializētu vaicājumu valodu Rego.

Conftest var instalēt, izmantojot instrukcijasnorādīts projekta tīmekļa vietnē.

Sākotnējā raksta rakstÄ«Å”anas laikā jaunākā pieejamā versija bija 0.18.2.

LÄ«dzÄ«gi kā config-lint un copper, conftest tiek piedāvāts bez iebÅ«vētiem testiem. Izmēģināsim un izveidosim savu politiku. Tāpat kā iepriekŔējos piemēros, mēs pārbaudÄ«sim, vai konteinera attēli ir ņemti no uzticama avota.

Izveidojiet direktoriju conftest-checks, un tajā ir fails ar nosaukumu check_image_registry.rego ar Ŕādu saturu:

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

Tagad pārbaudīsim base-valid.yaml caur 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

Paredzams, ka pārbaude neizdevās, jo attēli tika iegūti no neuzticama avota.

Rego failā mēs definējam bloku deny. Tās patiesība tiek uzskatīta par pārkāpumu. Ja bloķē deny vairākus, conftest pārbauda tos neatkarīgi vienu no otra, un jebkura bloka patiesums tiek uzskatīts par pārkāpumu.

Papildus noklusējuma izvadei conftest atbalsta JSON, TAP un tabulas formātu ā€” ļoti noderÄ«ga funkcija, ja nepiecieÅ”ams iegult atskaites esoŔā CI konveijerā. Izmantojot karogu, varat iestatÄ«t vēlamo formātu --output.

Lai atvieglotu politiku atkļūdoÅ”anu, conftest ir karodziņŔ --trace. Tas izvada izsekojumu tam, kā conftest parsē norādÄ«tos politikas failus.

Konkursa politikas var publicēt un kopīgot OCI (Open Container Initiative) reģistros kā artefaktus.

Komandas push Šø pull ļauj publicēt artefaktu vai izgÅ«t esoÅ”u artefaktu no attālā reÄ£istra. Mēģināsim publicēt mÅ«su izveidoto politiku vietējā Docker reÄ£istrā, izmantojot conftest push.

Sāciet savu vietējo Docker reģistru:

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

Citā terminālī dodieties uz direktoriju, kuru izveidojāt iepriekŔ conftest-checks un palaidiet Ŕādu komandu:

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

Ja komanda bija veiksmÄ«ga, jÅ«s redzēsit Ŕādu ziņojumu:

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

Tagad izveidojiet pagaidu direktoriju un palaidiet tajā esoÅ”o komandu conftest pull. Tas lejupielādēs pakotni, kas izveidota ar iepriekŔējo komandu:

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

Pagaidu direktorijā parādīsies apakŔdirektorijs policykurā ir mūsu politikas fails:

$ tree
.
ā””ā”€ā”€ policy
  ā””ā”€ā”€ check_image_registry.rego

Testus var palaist tieŔi no repozitorija:

$ 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

Diemžēl DockerHub vēl netiek atbalstīts. Tāpēc uzskatiet, ka esat laimīgs, ja izmantojat Azure konteineru reģistrs (ACR) vai savu reģistru.

Artefakta formāts ir tāds pats kā Atveriet politikas aÄ£entu pakotnes (OPA), kas ļauj izmantot conftest, lai palaistu testus no esoÅ”ajām OPA pakotnēm.

Vairāk par politikas kopÄ«goÅ”anu un citām conftest funkcijām varat uzzināt vietnē oficiālā projekta vietne.

6. Polaris

Pēdējais rÄ«ks, kas tiks apspriests Å”ajā rakstā, ir Polaris. (Viņa pagājuŔā gada paziņojums mēs jau tulkots Sākot no apm. tulkojums)

Polaris var instalēt klasterī vai izmantot komandrindas režīmā. Kā jūs, iespējams, uzminējāt, tas ļauj statiski analizēt Kubernetes manifestus.

Darbojoties komandrindas režīmā, ir pieejami iebÅ«vēti testi, kas aptver tādas jomas kā droŔība un labākā prakse (lÄ«dzÄ«gi kā kube-score). Turklāt jÅ«s varat izveidot savus testus (piemēram, config-lint, copper un conftest).

Citiem vārdiem sakot, Polaris apvieno abu kategoriju rÄ«ku priekÅ”rocÄ«bas: ar iebÅ«vētiem un pielāgotiem testiem.

Lai instalētu Polaris komandrindas režīmā, izmantojiet norādījumus projekta tīmekļa vietnē.

Sākotnējā raksta rakstÄ«Å”anas laikā ir pieejama versija 1.0.3.

Kad instalÄ“Å”ana ir pabeigta, manifestā varat palaist polaris base-valid.yaml ar Ŕādu komandu:

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

Tas izvadÄ«s virkni JSON formātā ar detalizētu veikto testu un to rezultātu aprakstu. Izvadei bÅ«s Ŕāda struktÅ«ra:

{
  "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": [
    /* Š“Š»ŠøŠ½Š½Ń‹Š¹ сŠæŠøсŠ¾Šŗ */
  ]
}

Pieejama pilna izvade Ŕeit.

Tāpat kā kube-score, Polaris identificē problēmas jomās, kurās manifests neatbilst paraugpraksei:

  • PākstÄ«m nav veiktas veselÄ«bas pārbaudes.
  • Konteinera attēlu atzÄ«mes nav norādÄ«tas.
  • Konteiners darbojas kā root.
  • Atmiņas un CPU pieprasÄ«jumi un ierobežojumi nav norādÄ«ti.

Katram testam atkarÄ«bā no tā rezultātiem tiek pieŔķirta kritiskuma pakāpe: brÄ«dinājums vai briesmas. Lai uzzinātu vairāk par pieejamajiem iebÅ«vētajiem testiem, lÅ«dzu, skatiet dokumentācija.

Ja informācija nav nepiecieÅ”ama, varat norādÄ«t karogu --format score. Å ajā gadÄ«jumā Polaris izvadÄ«s skaitli no 1 lÄ«dz 100 āˆ’ punktu skaits (t.i., novērtējums):

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

Jo tuvāk rezultāts ir 100, jo augstāka ir sakritības pakāpe. Ja pārbaudāt komandas izejas kodu polaris audit, izrādās, ka tas ir vienāds ar 0.

Spēks polaris audit Varat pārtraukt darbu ar kodu, kas nav nulle, izmantojot divus karodziņus:

  • AtzÄ«mēt --set-exit-code-below-score kā argumentu izmanto sliekŔņa vērtÄ«bu diapazonā no 1 lÄ«dz 100. Å ajā gadÄ«jumā komanda tiks aizvērta ar izejas kodu 4, ja rezultāts ir zem sliekŔņa. Tas ir ļoti noderÄ«gi, ja jums ir noteikta sliekŔņa vērtÄ«ba (piemēram, 75) un jums ir jāsaņem brÄ«dinājums, ja rezultāts ir zemāks.
  • AtzÄ«mēt --set-exit-code-on-danger izraisÄ«s komandas neveiksmi ar kodu 3, ja kāds no bÄ«stamÄ«bas testiem neizdodas.

Tagad mēģināsim izveidot pielāgotu testu, kas pārbauda, ā€‹ā€‹vai attēls ir ņemts no uzticamas krātuves. Pielāgotie testi ir norādÄ«ti YAML formātā, un pats tests ir aprakstÄ«ts, izmantojot JSON shēmu.

Å is YAML koda fragments apraksta jaunu testu ar nosaukumu 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/.+$

Apskatīsim to tuvāk:

  • successMessage ā€” Ŕī rindiņa tiks izdrukāta, ja tests bÅ«s sekmÄ«gi pabeigts;
  • failureMessage ā€” Å”is ziņojums tiks parādÄ«ts kļūmes gadÄ«jumā;
  • category ā€” norāda vienu no kategorijām: Images, Health Checks, Security, Networking Šø Resources;
  • target--- nosaka, kāda veida objekts (spec) tiek piemērots tests. Iespējamās vērtÄ«bas: Container, Pod vai Controller;
  • Pats tests ir norādÄ«ts objektā schema izmantojot JSON shēmu. Atslēgas vārds Å”ajā testā ir pattern izmanto, lai salÄ«dzinātu attēla avotu ar nepiecieÅ”amo.

Lai palaistu iepriekÅ” minēto testu, jums ir jāizveido Ŕāda Polaris konfigurācija:

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)

Parsēsim failu:

  • Å ajā jomā checks tiek noteikti testi un to kritiskuma lÄ«menis. Tā kā ir vēlams saņemt brÄ«dinājumu, kad attēls ir ņemts no neuzticama avota, mēs iestatām lÄ«meni Å”eit danger.
  • Pats tests checkImageRepo pēc tam reÄ£istrēts objektā customChecks.

Saglabājiet failu kā custom_check.yaml. Tagad jūs varat skriet polaris audit ar YAML manifestu, kam nepiecieŔama pārbaude.

Pārbaudīsim savu manifestu base-valid.yaml:

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

Komanda polaris audit veica tikai iepriekŔ norādīto lietotāja testu, un tas neizdevās.

Ja labojat attēlu, lai my-company.com/http-echo:1.0, Polaris veiksmÄ«gi pabeigs. Manifests ar izmaiņām jau ir iekŔā krātuveslai jÅ«s varētu pārbaudÄ«t iepriekŔējo komandu manifestā image-valid-mycompany.yaml.

Tagad rodas jautājums: kā palaist iebÅ«vētos testus kopā ar pielāgotajiem? Viegli! Jums vienkārÅ”i jāpievieno iebÅ«vētie testa identifikatori konfigurācijas failam. Rezultātā tam bÅ«s Ŕāda forma:

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)

Ir pieejams pilna konfigurācijas faila piemērs Å”eit.

Pārbaudiet manifestu base-valid.yamlizmantojot iebūvētos un pielāgotos testus, varat izmantot komandu:

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

Polaris papildina iebūvētos testus ar pielāgotiem testiem, tādējādi apvienojot labāko no abām pasaulēm.

No otras puses, nespēja izmantot jaudÄ«gākas valodas, piemēram, Rego vai JavaScript, var bÅ«t ierobežojoÅ”s faktors, kas neļauj izveidot sarežģītākus testus.

PlaŔāka informācija par Polaris ir pieejama vietnē projekta vietne.

Kopsavilkums

Lai gan ir pieejami daudzi rīki, lai pārbaudītu un novērtētu Kubernetes YAML failus, ir svarīgi skaidri saprast, kā testi tiks izstrādāti un izpildīti.

Tā, piemēram, ja lietojat Kubernetes manifestus, kas iet cauri cauruļvadam, kubeval varētu bÅ«t pirmais solis Ŕādā cauruļvadā. Tas pārraudzÄ«tu, vai objektu definÄ«cijas atbilst Kubernetes API shēmai.

Kad Ŕāda pārskatÄ«Å”ana ir pabeigta, varētu pāriet uz sarežģītākiem testiem, piemēram, atbilstÄ«bu standarta paraugpraksei un Ä«paÅ”ai politikai. Å eit noderētu kube-score un Polaris.

Tiem, kam ir sarežģītas prasÄ«bas un kuriem nepiecieÅ”ams detalizēti pielāgot testus, bÅ«tu piemērots varÅ”, config-lint un conftest.

Conftest un config-lint izmanto YAML, lai definētu pielāgotus testus, un vara nodroÅ”ina piekļuvi pilnai programmÄ“Å”anas valodai, padarot to par diezgan pievilcÄ«gu izvēli.

No otras puses, vai ir vērts izmantot kādu no Å”iem rÄ«kiem un lÄ«dz ar to visus testus izveidot manuāli, vai dot priekÅ”roku Polaris un pievienot tam tikai nepiecieÅ”amo? Uz Å”o jautājumu nav skaidras atbildes.

Tālāk esoŔajā tabulā ir sniegts īss katra rīka apraksts:

Instruments
Destinies
Ierobežojumi
Lietotāju testi

kubeval
Pārbauda YAML manifestus attiecībā pret konkrētu API shēmas versiju
Nevar strādāt ar CRD
Nē

kube-score
Analizē YAML izpausmes pret labāko praksi
Nevar atlasīt savu Kubernetes API versiju, lai pārbaudītu resursus
Nē

varÅ”
Vispārējs ietvars pielāgotu JavaScript testu izveidei YAML manifestiem
Nav iebūvētu testu. Slikta dokumentācija
Jā

config-lint
Vispārīga sistēma testu izveidei domēnam specifiskā valodā, kas iegulta YAML. Atbalsta dažādus konfigurācijas formātus (piem., Terraform)
Nav gatavu testu. Ar iebūvētiem apgalvojumiem un funkcijām var nepietikt
Jā

konkurss
Ietvars savu testu izveidei, izmantojot Rego (specializētu vaicājumu valodu). Ļauj koplietot politikas, izmantojot OCI komplektus
Nav iebūvētu testu. Man jāiemācās Rego. Docker Hub netiek atbalstīts, publicējot politikas
Jā

Polaris
Atsauksmes par YAML izpausmēm, salīdzinot ar standarta labāko praksi. Ļauj izveidot savus testus, izmantojot JSON shēmu
Var nepietikt ar testÄ“Å”anas iespējām, kuru pamatā ir JSON shēma
Jā

Tā kā Å”ie rÄ«ki nav atkarÄ«gi no piekļuves Kubernetes klasterim, tos ir viegli instalēt. Tie ļauj filtrēt avota failus un nodroÅ”ināt ātru atgriezenisko saiti projektu piesaistes pieprasÄ«jumu autoriem.

PS no tulka

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru