🥇Kubernetes YAML-i kinnitamine parimate tavade ja eeskirjade alusel

Märge. tõlge: Kuna K8-keskkondade YAML-i konfiguratsioonide arv kasvab, muutub nende automaatse kontrollimise vajadus üha pakilisemaks. Selle ülevaate autor mitte ainult ei valinud selle ülesande jaoks olemasolevaid lahendusi, vaid kasutas ka juurutamist näitena, et näha, kuidas need töötavad. See osutus väga informatiivseks neile, keda see teema huvitab.

TL; DR: selles artiklis võrreldakse kuut staatilist tööriista Kubernetes YAML-failide kinnitamiseks ja hindamiseks parimate tavade ja nõuete alusel.

Рабочие нагрузки Kubernetes, как правило, определяются в форме YAML-документов. Одна из проблем с YAML’ом — сложность задания ограничений или взаимоотношений между файлами манифестов.

Mis siis, kui peame tagama, et kõik klastris juurutatud pildid pärinevad usaldusväärsest registrist?

Kuidas saan takistada juurutusi, millel pole PodDisruptionBudgets'i, saatmist klastrisse?

Staatilise testimise integreerimine võimaldab tuvastada vigu ja poliitika rikkumisi arendusetapis. See suurendab garantiid, et ressursside määratlused on õiged ja turvalised, ning muudab tõenäolisemaks, et tootmise töökoormused järgivad parimaid tavasid.

Экосистему статической проверки YAML-файлов Kubernetes можно разделить на следующие категории:

API valideerijad. Selle kategooria tööriistad kontrollivad YAML-i manifesti vastavust Kubernetes API serveri nõuetele.
Готовые тестеры. Инструменты из данной категории идут с готовыми тестами на безопасность, соответствие лучшим практикам и т.п.
Kohandatud validaatorid. Selle kategooria esindajad võimaldavad teil luua kohandatud teste erinevates keeltes, näiteks Rego ja Javascript.

Selles artiklis kirjeldame ja võrdleme kuut erinevat tööriista:

kubeval;
kube-score;
config-lint;
vask;
võistlus;
polaris.

Noh, alustame!

Juurutuste kontrollimine

Enne kui hakkame tööriistu võrdlema, loome tausta, mille põhjal neid testida.

Allolev manifest sisaldab mitmeid vigu ja parimate tavade mittejärgimist: kui palju neist leiate?

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)

Kasutame seda YAML-i erinevate tööriistade võrdlemiseks.

Ülaltoodud manifest base-valid.yaml ja teised selle artikli manifestid leiate aadressilt Giti hoidlad.

Manifest kirjeldab veebirakendust, mille põhiülesanne on vastata "Tere maailm" sõnumiga pordile 5678. Seda saab juurutada järgmise käsuga:

kubectl apply -f hello-world.yaml

Ja nii - kontrollige tööd:

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

Nüüd minge aadressile http://localhost:8080 и подтвердите, что приложение работает. Но следует ли оно лучшим практикам? Kontrollime.

1. Kubeval

Keskmes kubeval Idee seisneb selles, et igasugune suhtlus Kubernetesega toimub selle REST API kaudu. Teisisõnu saate API-skeemi abil kontrollida, kas antud YAML vastab sellele. Vaatame näidet.

Paigaldusjuhised kubeval on saadaval projekti veebisaidil.

На момент написания оригинальной статьи была доступна версия 0.15.0.

Pärast installimist edastame sellele ülaltoodud manifesti:

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

Kui see õnnestub, väljub kubeval väljumiskoodiga 0. Saate seda kontrollida järgmiselt:

$ echo $?
0

Proovime nüüd kubeval teistsuguse manifestiga:

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)

Kas saate probleemi silmaga märgata? Käivitame:

$ 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

Ressursi ei kinnitata.

Juurutused API versiooni abil apps/v1, должны включать селектор, соответствующий метке pod’а. Манифест выше не включает селектор, поэтому kubeval сообщил об ошибке и вышел с ненулевым кодом.

Huvitav, mis siis saab, kui teen kubectl apply -f с этим манифестом?

Noh, proovime:

$ 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

Just selle vea eest kubeval hoiatas. Saate selle parandada valija lisamisega:

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)

Преимущество инструментов вроде kubeval в том, что подобные ошибки можно отлавливать на ранних стадиях цикла развертывания.

Lisaks ei nõua need kontrollid juurdepääsu klastrile, neid saab teha võrguühenduseta.

Vaikimisi kontrollib kubeval ressursse Kubernetese API uusima skeemi alusel. Kuid enamikul juhtudel peate võib-olla kontrollima konkreetse Kubernetese väljalase. Seda saab teha lipu abil --kubernetes-version:

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

Pange tähele, et versioon tuleb vormingus täpsustada Major.Minor.Patch.

Versioonide loendi, mille puhul kinnitamist toetatakse, leiate siit JSON-skeem GitHubis, mida kubeval valideerimiseks kasutab. Kui peate kubevali võrguühenduseta käivitama, laadige skeemid alla ja määrake lipu abil nende kohalik asukoht --schema-location.

Lisaks üksikutele YAML-failidele saab kubeval töötada ka kataloogide ja stdin-iga.

Lisaks integreerub Kubeval hõlpsasti CI torujuhtmesse. Neil, kes soovivad enne manifestide klastrisse saatmist teste läbi viia, on hea meel teada, et kubeval toetab kolme väljundvormingut:

Lihttekst;
JSON;
Test Anything Protocol (TAP).

Ja mis tahes vorminguid saab kasutada väljundi edasiseks sõelumiseks, et luua soovitud tüüpi tulemuste kokkuvõte.

Üks kubevali puudusi on see, et praegu ei saa see kontrollida vastavust kohandatud ressursside määratlustele (CRD). Küll aga on võimalik kubeval seadistada neid ignoreerida.

Kubeval on suurepärane tööriist ressursside kontrollimiseks ja hindamiseks; Siiski tuleb rõhutada, et testi läbimine ei taga, et ressurss vastab parimatele tavadele.

Näiteks sildi kasutamine latest в контейнере не соответствует лучшим практикам. Однако kubeval не считает это ошибкой и не сообщает о ней. То есть проверка такого YAML завершится без предупреждений.

Aga mis siis, kui soovite YAMLi hinnata ja tuvastada rikkumisi, nagu silt latest? Kuidas kontrollida YAML-faili parimate tavade suhtes?

2. Kube-skoor

Kube-skoor parsib YAML-i manifeste ja hindab neid sisseehitatud testide alusel. Need testid valitakse turvajuhiste ja parimate tavade alusel, näiteks:

Konteinerit ei käitata juurkasutajana.
Kauna tervisekontrollide kättesaadavus.
Ressursside taotluste ja piirangute seadmine.

Testi tulemuste põhjal antakse kolm tulemust: OK, HOIATUS и Kriitiline.

Saate proovida Kube-score'i võrgus või installida selle kohapeal.

Algse artikli kirjutamise ajal oli kube-score'i uusim versioon 1.7.0.

Proovime seda oma manifestis 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 läbib kubevali testid, samas kui kube-score osutab järgmistele vigadele:

Valmisoleku kontrollid pole konfigureeritud.
Protsessori ressurssidele ja mälule pole taotlusi ega piiranguid.
Podi katkestuste eelarveid pole täpsustatud.
Eraldamise reeglid puuduvad (afiinsuse vastane) saadavuse maksimeerimiseks.
Konteiner töötab root-vormingus.

Need on kõik kehtivad punktid puuduste kohta, mis tuleb kõrvaldada, et muuta juurutamine tõhusamaks ja usaldusväärsemaks.

Meeskond kube-score kuvab teavet inimloetaval kujul, sealhulgas kõiki tüüpi rikkumisi HOIATUS и Kriitiline, что очень помогает во время разработки.

Need, kes soovivad seda tööriista CI torujuhtmes kasutada, saavad lipu abil lubada tihendatud väljundit --output-format ci (sel juhul kuvatakse ka testid koos tulemusega 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

Sarnaselt kubevaliga tagastab kube-score nullist erineva väljumiskoodi, kui test ebaõnnestub Kriitiline. Saate lubada ka sarnase töötlemise HOIATUS.

Lisaks on võimalik kontrollida ressursside vastavust erinevatele API versioonidele (nagu kubeval). See teave on aga kube-skooris endas kõvasti kodeeritud: te ei saa valida teist Kubernetese versiooni. See piirang võib osutuda suureks probleemiks, kui kavatsete oma klastrit uuendada või kui teil on mitu klastrit erinevate K8-de versioonidega.

Pange tähele, et probleem on juba käes ettepanekuga see võimalus realiseerida.

Lisateavet kube-score'i kohta leiate aadressilt ametlikul kodulehel.

Kube-skoori testid on suurepärane tööriist parimate tavade rakendamiseks, kuid mis siis, kui teil on vaja testis muudatusi teha või oma reegleid lisada? Kahjuks ei saa seda teha.

Kube-skoor ei ole laiendatav: sellele ei saa lisada reegleid ega neid kohandada.

Kui teil on vaja kirjutada kohandatud teste, et kontrollida ettevõtte eeskirjade järgimist, võite kasutada ühte neljast järgmisest tööriistast: config-lint, copper, conftest või polaris.

3. Config-lint

Config-lint on tööriist YAML-i, JSON-i, Terraformi, CSV-konfiguratsioonifailide ja Kubernetese manifestide valideerimiseks.

Saate selle installida kasutades juhiseid на сайте проекта.

Algse artikli kirjutamise seisuga on praegune versioon 1.5.0.

Config-lintil pole Kubernetese manifestide kinnitamiseks sisseehitatud teste.

Testide läbiviimiseks peate looma sobivad reeglid. Need on kirjutatud YAML-failides, mida nimetatakse "reeglistikuks" (rulesets)ja neil on järgmine struktuur:

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

(rule.yaml)

Uurime seda lähemalt:

Väli type указывает, какой тип конфигурации будет использовать config-lint. Для манифестов K8s это alati Kubernetes.
Valdkonnas files Lisaks failidele endile saate määrata kataloogi.
Väli rules mõeldud kasutajatestide seadistamiseks.

Oletame, et soovite veenduda, et juurutamise pildid laaditakse alati alla usaldusväärsest hoidlast, näiteks my-company.com/myapp:1.0. Правило для config-lint, осуществляющее подобную проверку, будет выглядеть следующим образом:

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

Igal reeglil peavad olema järgmised atribuudid:

id — reegli kordumatu tunnus;
severity - Võib olla FAILURE, HOIATUS и MITTEKAHJULIK;
message — reegli rikkumise korral kuvatakse selle rea sisu;
resource — ressursi liik, mille suhtes seda reeglit kohaldatakse;
assertions — tingimuste loetelu, mida selle ressursi suhtes hinnatakse.

Ülaltoodud reeglis assertion kutsutud every kontrollib, et kõik konteinerid oleksid juurutusrežiimis (key: spec.templates.spec.containers) kasutage usaldusväärseid pilte (st alustades my-company.com/).

Täielik reeglistik näeb välja selline:

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)

Чтобы испытать тест, давайте сохраним его как check_image_repo.yaml. Kontrollime faili 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"
  }
]

Проверка завершилась неудачно. Теперь давайте проверим следующий манифест с правильным репозиторием образов:

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)

Запускаем тот же самый тест с приведенным выше манифестом. Проблем не обнаружено:

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

Config-lint on paljutõotav raamistik, mis võimaldab teil luua oma teste Kubernetes YAML-i manifestide kinnitamiseks YAML DSL-i abil.

Aga mis siis, kui vajate keerukamat loogikat ja teste? Kas YAML pole selleks liiga piiratud? Mis siis, kui saaksite luua teste täisprogrammeerimiskeeles?

4. Vask

Vask V2 on raamistik manifestide valideerimiseks kohandatud testide abil (sarnaselt config-lintiga).

Viimasest erineb see aga selle poolest, et ei kasuta testide kirjeldamiseks YAMLi. Teste saab kirjutada hoopis JavaScriptis. Copper pakub raamatukogu mitme põhitööriistaga, помогающими считывать информацию об объектах Kubernetes и сообщать об ошибках.

Последовательность шагов для установки Copper можно найти в ametlik dokumentatsioon.

2.0.1 on selle utiliidi uusim versioon algse artikli kirjutamise ajal.

Как и config-lint, Copper не имеет встроенных тестов. Давайте напишем один. Пусть он проверяет, что deployment’ы используют контейнерные образы исключительно из доверенных репозиториев вроде my-company.com.

Looge fail check_image_repo.js järgmise sisuga:

$$.forEach(function($){
    if ($.kind === 'Deployment') {
        $.spec.template.spec.containers.forEach(function(container) {
            var image = new DockerImage(container.image);
            if (image.registry.lastIndexOf('my-company.com/') != 0) {
                errors.add_error('no_company_repo',"Image " + $.metadata.name + " is not from my-company.com repo", 1)
            }
        });
    }
});

Nüüd testige oma manifesti base-valid.yaml, kasutage käsku 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

On selge, et vase abil saate teha keerukamaid teste - näiteks kontrollida domeeninimesid Ingressi manifestides või keelduda privilegeeritud režiimis töötavatest podidest.

Vasele on sisse ehitatud mitmesugused kasulikud funktsioonid:

DockerImage loeb määratud sisendfaili ja loob objekti järgmiste atribuutidega:
- name - pildi nimi,
- tag - pildi silt,
- registry - pildiregister,
- registry_url - protokoll (https://) ja pildiregister,
- fqin — полное местоположение образа.
Funktsioon findByName aitab leida ressurssi antud tüübi järgi (kind) ja nimi (name) sisendfailist.
Funktsioon findByLabels aitab leida ressurssi määratud tüübi järgi (kind) ja sildid (labels).

Saate vaadata kõiki saadaolevaid teenusefunktsioone siin.

Vaikimisi laadib see muutujasse kogu sisend-YAML-faili $$ ja teeb selle skriptimiseks kättesaadavaks (tuttav tehnika neile, kellel on jQuery kogemus).

Copperi peamine eelis on ilmne: te ei pea valdama spetsiaalset keelt ja saate oma testide loomiseks kasutada erinevaid JavaScripti funktsioone, nagu stringide interpolatsioon, funktsioonid jne.

Samuti tuleb märkida, et Copperi praegune versioon töötab JavaScripti mootori ES5 versiooniga, mitte ES6-ga.

Üksikasjad saadaval aadressil projekti ametlikul veebisaidil.

Kui teile aga JavaScript väga ei meeldi ja eelistate spetsiaalselt päringute loomiseks ja poliitikate kirjeldamiseks mõeldud keelt, peaksite tähelepanu pöörama conftestile.

5.Konkurss

Conftest on raamistik konfiguratsiooniandmete testimiseks. Sobib ka Kubernetese manifestide testimiseks/kontrollimiseks. Teste kirjeldatakse spetsiaalse päringukeele abil Rego.

Установить conftest можно с помощью juhiseidloetletud projekti veebisaidil.

Algse artikli kirjutamise ajal oli uusim saadaolev versioon 0.18.2.

Sarnaselt config-lintile ja vasele on conftest ilma sisseehitatud testideta. Proovime seda ja koostame oma poliitika. Nagu eelmistes näidetes, kontrollime, kas konteineri pildid on võetud usaldusväärsest allikast.

Создайте директорию conftest-checks, ja selles on fail nimega check_image_registry.rego järgmise sisuga:

package main

deny[msg] {

  input.kind == "Deployment"
  image := input.spec.template.spec.containers[_].image
  not startswith(image, "my-company.com/")
  msg := sprintf("image '%v' doesn't come from my-company.com repository", [image])
}

Nüüd testime base-valid.yaml läbi 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

Test ebaõnnestus ennustatavalt, kuna pildid pärinesid ebausaldusväärsest allikast.

Rego failis määratleme ploki deny. Selle tõde peetakse rikkumiseks. Kui blokeerib deny mitu, conftest kontrollib neid üksteisest sõltumatult ja mis tahes plokkide õigsust käsitletakse rikkumisena.

Lisaks vaikeväljundile toetab conftest JSON-i, TAP-i ja tabelivormingut – see on äärmiselt kasulik funktsioon, kui teil on vaja manustada aruandeid olemasolevasse CI-konveierisse. Lipu abil saate määrata soovitud vormingu --output.

Eeskirjade silumise hõlbustamiseks on conftestil lipp --trace. See väljastab jälje selle kohta, kuidas conftest määratletud poliitikafaile analüüsib.

Konkursipoliitikaid saab avaldada ja jagada OCI (Open Container Initiative) registrites artefaktidena.

Käsud push и pull võimaldab avaldada artefakti või tuua olemasoleva artefakti kaugregistrist. Proovime avaldada loodud poliitika kohalikus Dockeri registris conftest push.

Käivitage kohalik Dockeri register:

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

Minge teises terminalis varem loodud kataloogi conftest-checks ja käivitage järgmine käsk:

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

Kui käsk õnnestus, näete sellist teadet:

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

Nüüd looge ajutine kataloog ja käivitage selles käsk conftest pull. See laadib alla eelmise käsuga loodud paketi:

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

Ajutisse kataloogi ilmub alamkataloog policymis sisaldab meie poliitikafaili:

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

Teste saab käivitada otse hoidlast:

$ 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

Kahjuks ei toetata DockerHubi veel. Nii et pidage end õnnelikuks, kui kasutate Azure'i konteinerite register (ACR) või teie enda registris.

Artefaktide vorming on sama, mis Avage poliitikaagendi paketid (OPA), mis võimaldab teil olemasolevatest OPA-pakettidest testide käivitamiseks kasutada conftest.

Lisateavet poliitika jagamise ja muude conftesti funktsioonide kohta leiate aadressilt projekti ametlikul veebisaidil.

6. Põhjanael

Последний инструмент, о котором пойдет речь в этой статье, — это Põhjanael. (Tema eelmise aasta teadaanne me уже переводили - u. tõlge)

Polarist saab installida klastrisse või kasutada käsurearežiimis. Nagu võite arvata, võimaldab see Kubernetese manifeste staatiliselt analüüsida.

Käsurearežiimis töötamisel on saadaval sisseehitatud testid, mis hõlmavad selliseid valdkondi nagu turvalisus ja parimad tavad (sarnaselt kube-score'iga). Lisaks saate luua oma teste (nt config-lint, copper ja conftest).

Teisisõnu ühendab Polaris mõlema tööriistakategooria eelised: sisseehitatud ja kohandatud testidega.

Polarise installimiseks käsurearežiimis kasutage juhised projekti veebisaidil.

На момент написания оригинальной статьи доступна версия 1.0.3.

Kui installimine on lõppenud, saate manifestis käivitada polarise base-valid.yaml с помощью следующей команды:

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

Она выведет строку в формате JSON с подробным описанием выполненных тестов и их результатами. Вывод будет иметь следующую структуру:

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

Saadaval on täielik väljund siin.

Nagu kube-score, tuvastab Polaris probleemid valdkondades, kus manifest ei vasta parimatele tavadele.

Kaunade tervisekontrolli ei tehta.
Не указаны теги для контейнерных образов.
Konteiner töötab root-vormingus.
Mälu ja protsessori taotlusi ja piiranguid pole täpsustatud.

Igale testile, olenevalt selle tulemustest, määratakse kriitilisus: hoiatus või oht. Saadaolevate sisseehitatud testide kohta lisateabe saamiseks vaadake dokumentatsioon.

Kui üksikasju pole vaja, saate lipu määrata --format score. Sel juhul väljastab Polaris numbri vahemikus 1 kuni 100 − skoor (st hindamine):

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

Mida lähemal on skoor 100-le, seda suurem on kokkuleppe aste. Kui kontrollite käsu väljumiskoodi polaris audit, selgub, et see on võrdne 0-ga.

Jõud polaris audit завершать работу с ненулевым кодом можно с помощью двух флагов:

Lipp --set-exit-code-below-score võtab argumendina läviväärtuse vahemikus 1–100. Sel juhul väljub käsk väljumiskoodiga 4, kui tulemus jääb alla läve. See on väga kasulik, kui teil on teatud läviväärtus (näiteks 75) ja kui tulemus langeb allapoole, peate saama hoiatuse.
Lipp --set-exit-code-on-danger põhjustab koodiga 3 käsu ebaõnnestumise, kui üks ohutestidest ebaõnnestub.

Nüüd proovime luua kohandatud testi, mis kontrollib, kas pilt on võetud usaldusväärsest hoidlast. Kohandatud testid on määratud YAML-vormingus ja testi ennast kirjeldatakse JSON-skeemi abil.

Järgmine YAML-i koodilõik kirjeldab uut testi nimega 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/.+$

Vaatame seda lähemalt:

successMessage — see rida prinditakse, kui test on edukalt lõpule viidud;
failureMessage — это сообщение будет показано в случае неудачи;
category — tähistab ühte kategooriatest: Images, Health Checks, Security, Networking и Resources;
target—- определяет, к какому типу объекту (spec) testi rakendatakse. Võimalikud väärtused: Container, Pod või Controller;
Test ise on määratud objektis schema kasutades JSON-skeemi. Selle testi võtmesõna on pattern kasutatakse pildiallika võrdlemiseks vajalikuga.

Ülaltoodud testi käivitamiseks peate looma järgmise Polarise konfiguratsiooni:

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)

Analüüsime faili:

Valdkonnas checks on ette nähtud testid ja nende kriitilisuse tase. Kuna ebausaldusväärsest allikast tehtud pildi puhul on soovitav saada hoiatus, siis määrame taseme siin danger.
Test ise checkImageRepo seejärel registreeriti objektil customChecks.

Salvestage fail nimega custom_check.yaml. Nüüd saate joosta polaris audit YAML-i manifestiga, mis nõuab kinnitamist.

Протестируем наш манифест base-valid.yaml:

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

Meeskond polaris audit käivitas ainult ülaltoodud kasutajatesti ja see ebaõnnestus.

Kui parandate pildi my-company.com/http-echo:1.0, lõpetab Polaris edukalt. Manifest koos muudatustega on juba sees hoidladet saaksite kontrollida manifestis eelmist käsku image-valid-mycompany.yaml.

Теперь возникает вопрос: как запускать встроенные тесты совместно с пользовательскими? Легко! Просто надо добавить идентификаторы встроенных тестов в файл конфигурации. В результате он приобретет следующий вид:

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)

Saadaval on täieliku konfiguratsioonifaili näide siin.

Kontrolli manifesti base-valid.yamlkasutades sisseehitatud ja kohandatud teste, saate kasutada käsku:

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

Polaris дополняет встроенные тесты пользовательскими, тем самым сочетая лучшее из двух миров.

Teisest küljest võib võimetus kasutada võimsamaid keeli, nagu Rego või JavaScript, olla piirav tegur, mis takistab keerukamate testide loomist.

Lisateavet Polarise kohta leiate aadressilt projekti veebisait.

Kokkuvõte

Kuigi Kubernetes YAML-failide kontrollimiseks ja hindamiseks on saadaval palju tööriistu, oluline on omada selget arusaama sellest, kuidas teste kavandatakse ja teostatakse.

Näiteks если взять манифесты Kubernetes, проходящие через пайплайн, kubeval мог бы стать первым шагом в таком пайплайне. See jälgiks, kas objektide määratlused vastavad Kubernetes API skeemile.

Kui selline ülevaatus on lõpule viidud, võiks liikuda keerukamate testide juurde, näiteks vastavus standardsetele parimatele tavadele ja konkreetsetele poliitikatele. Siin tuleks kasuks kube-score ja Polaris.

Neile, kellel on keerulised nõuded ja on vaja teste üksikasjalikult kohandada, sobivad vask, config-lint ja conftest.

Conftest ja config-lint kasutavad kohandatud testide määratlemiseks YAMLi ja vask annab teile juurdepääsu täielikule programmeerimiskeelele, muutes selle üsna atraktiivseks valikuks.

Teisest küljest, kas tasub kasutada mõnda neist tööriistadest ja seetõttu luua kõik testid käsitsi või eelistada Polarist ja lisada sellele ainult vajalik? Sellele küsimusele pole selget vastust.

Allolevas tabelis on iga tööriista lühikirjeldus:

Vahend
Eesmärk
Piirangud
Пользовательские тесты

kubeval
Проверяет YAML-манифесты на соответствие определенной версии схемы API
CRD-ga ei saa töötada
ei

kube-skoor
Analüüsib YAML-i manifeste parimate tavade suhtes
Ressursside kontrollimiseks ei saa valida Kubernetes API versiooni
ei

vask
Üldine raamistik YAML-i manifestide jaoks kohandatud JavaScripti testide loomiseks
Sisseehitatud teste pole. Kehv dokumentatsioon
Jah

config-lint
Üldine raamistik testide loomiseks YAML-i manustatud domeenispetsiifilises keeles. Toetab erinevaid konfiguratsioonivorminguid (nt Terraform)
Valmis teste pole. Sisseehitatud väidetest ja funktsioonidest ei pruugi piisata
Jah

võistlus
Raamistik oma testide loomiseks Rego (spetsiaalne päringukeel) abil. Võimaldab poliitikate jagamist OCI-pakettide kaudu
Нет встроенных тестов. Приходится изучать Rego. Docker Hub не поддерживается при публикации политик
Jah

Põhjanael
Arvustused YAML-i manifestide tavapäraste parimate tavade vastaselt. Võimaldab luua JSON-skeemi abil oma teste
JSON-skeemil põhinevatest testimisvõimalustest ei pruugi piisata
Jah

Kuna need tööriistad ei sõltu juurdepääsust Kubernetese klastrile, on neid lihtne installida. Need võimaldavad filtreerida lähtefaile ja anda kiiret tagasisidet projektide tõmbamistaotluste autoritele.

PS tõlkijalt

Loe ka meie blogist:

Allikas: www.habr.com

Kontrollige Kubernetes YAML-i parimate tavade ja poliitikate suhtes