Валидирайте Kubernetes YAML спрямо най-добрите практики и политики

Забележка. превод: С нарастващия брой YAML конфигурации за K8s среди, необходимостта от тяхната автоматизирана проверка става все по-спешна. Авторът на този преглед не само е избрал съществуващи решения за тази задача, но е използвал и Deployment като пример, за да види как работят. Оказа се много информативно за тези, които се интересуват от тази тема.

TL; DR: Тази статия сравнява шест статични инструмента за валидиране и оценка на Kubernetes YAML файлове спрямо най-добрите практики и изисквания.

Работните натоварвания на Kubernetes обикновено се дефинират под формата на YAML документи. Един от проблемите с YAML е трудността при определяне на ограничения или връзки между манифестните файлове.

Какво ще стане, ако трябва да се уверим, че всички изображения, разположени в клъстера, идват от доверен регистър?

Как мога да предотвратя изпращането на разполагания, които нямат PodDisruptionBudgets, към клъстера?

Интегрирането на статично тестване ви позволява да идентифицирате грешки и нарушения на правилата на етапа на разработка. Това увеличава гаранцията, че дефинициите на ресурсите са правилни и сигурни и прави по-вероятно производствените натоварвания да следват най-добрите практики.

Статичната екосистема за проверка на YAML файлове на Kubernetes може да бъде разделена на следните категории:

• API валидатори. Инструментите в тази категория проверяват YAML манифеста спрямо изискванията на Kubernetes API сървъра.
• Готови тестери. Инструментите от тази категория идват с готови тестове за сигурност, съответствие с най-добрите практики и др.
• Персонализирани валидатори. Представителите на тази категория ви позволяват да създавате персонализирани тестове на различни езици, например Rego и Javascript.

В тази статия ще опишем и сравним шест различни инструмента:

1. кубевал;
2. kube-резултат;
3. config-lint;
4. мед;
5. конкурс;
6. Поларис.

Е, да започваме!

Проверка на внедряванията

Преди да започнем да сравняваме инструменти, нека създадем някакъв фон, върху който да ги тестваме.

Манифестът по-долу съдържа редица грешки и несъответствие с най-добрите практики: колко от тях можете да намерите?

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)

Ще използваме този YAML, за да сравним различни инструменти.

Горният манифест base-valid.yaml и други манифести от тази статия могат да бъдат намерени в Git хранилища.

Манифестът описва уеб приложение, чиято основна задача е да отговори със съобщение „Hello World“ на порт 5678. То може да бъде разгърнато със следната команда:

kubectl apply -f hello-world.yaml

И така - проверете работата:

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

Сега отидете на http://localhost:8080 и потвърдете, че приложението работи. Но следва ли най-добрите практики? Да проверим.

1. Кубевал

В сърцето кубевал Идеята е всяко взаимодействие с Kubernetes да става чрез неговия REST API. С други думи, можете да използвате API схема, за да проверите дали даден YAML отговаря на нея. Нека разгледаме един пример.

Инструкции за инсталация kubeval са достъпни на уебсайта на проекта.

Към момента на писане на оригиналната статия беше налична версия 0.15.0.

Веднъж инсталиран, нека го захраним с манифеста по-горе:

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

Ако успее, kubeval ще излезе с изходен код 0. Можете да го проверите по следния начин:

$ echo $?
0

Нека сега опитаме kubeval с различен манифест:

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)

Можете ли да забележите проблема с око? Да стартираме:

$ 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

Ресурсът не се проверява.

Внедрявания с помощта на версията на API apps/v1, трябва да включва селектор, който съответства на етикета на групата. Манифестът по-горе не включва селектора, така че kubeval съобщи за грешка и излезе с различен от нула код.

Чудя се какво ще стане, ако го направя kubectl apply -f с този манифест?

Е, нека опитаме:

$ 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

Това е точно грешката, за която kubeval предупреди. Можете да го поправите, като добавите селектор:

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 е, че грешки като тези могат да бъдат уловени в началото на цикъла на внедряване.

Освен това тези проверки не изискват достъп до клъстера; те могат да се извършват офлайн.

По подразбиране kubeval проверява ресурсите спрямо най-новата API схема на Kubernetes. Въпреки това, в повечето случаи може да се наложи да проверите спрямо конкретно издание на Kubernetes. Това може да стане с помощта на флага --kubernetes-version:

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

Моля, имайте предвид, че версията трябва да бъде посочена във формата Major.Minor.Patch.

За списък с версии, за които се поддържа проверка, вижте JSON схема в GitHub, който kubeval използва за валидиране. Ако трябва да стартирате kubeval офлайн, изтеглете схемите и посочете локалното им местоположение с помощта на флага --schema-location.

В допълнение към отделните YAML файлове, kubeval може да работи и с директории и stdin.

В допълнение, Kubeval лесно се интегрира в CI тръбопровода. Тези, които желаят да изпълнят тестове, преди да изпратят манифести към клъстера, ще се радват да знаят, че kubeval поддържа три изходни формата:

1. Обикновен текст;
2. JSON;
3. Test Anything Protocol (TAP).

Всеки от форматите може да се използва за по-нататъшно анализиране на изхода, за да се генерира обобщение на резултатите от желания тип.

Един от недостатъците на kubeval е, че в момента не може да проверява за съответствие с персонализирани дефиниции на ресурси (CRD). Въпреки това е възможно да конфигурирате kubeval игнорирай ги.

Kubeval е чудесен инструмент за проверка и оценка на ресурси; Трябва обаче да се подчертае, че преминаването на теста не гарантира, че ресурсът отговаря на най-добрите практики.

Например с помощта на етикета latest в контейнер не следва най-добрите практики. Kubeval обаче не счита това за грешка и не я докладва. Това означава, че проверката на такъв YAML ще завърши без предупреждения.

Но какво ще стане, ако искате да оцените YAML и да идентифицирате нарушения като етикета latest? Как да проверя YAML файл спрямо най-добрите практики?

2. Кубе-резултат

Кубе-резултат анализира YAML манифести и ги оценява спрямо вградени тестове. Тези тестове са избрани въз основа на указания за сигурност и най-добри практики, като например:

• Изпълнение на контейнера не като root.
• Наличие на проверки на здравето на капсулите.
• Задаване на заявки и лимити за ресурси.

Въз основа на резултатите от теста се дават три резултата: OK, ПРЕДУПРЕЖДЕНИЕ и КРИТИЧНО.

Можете да изпробвате Kube-score онлайн или да го инсталирате локално.

Към момента на писане на оригиналната статия най-новата версия на kube-score беше 1.7.0.

Нека го изпробваме в нашия манифест 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 преминава kubeval тестове, докато kube-score посочва следните недостатъци:

• Проверките за готовност не са конфигурирани.
• Няма заявки или ограничения за CPU ресурси и памет.
• Бюджетите за прекъсване на капсулите не са посочени.
• Няма правила за разделяне (анти-афинитет) за да увеличите максимално наличността.
• Контейнерът работи като root.

Това са всички валидни точки относно недостатъците, които трябва да бъдат решени, за да бъде разгръщането по-ефективно и надеждно.

Отбор kube-score показва информация в удобна за четене форма, включително всички нарушения на типа ПРЕДУПРЕЖДЕНИЕ и КРИТИЧНО, което помага много по време на разработката.

Тези, които желаят да използват този инструмент в рамките на CI тръбопровода, могат да активират по-компресиран изход с помощта на флага --output-format ci (в този случай се показват и тестове с резултата 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

Подобно на kubeval, kube-score връща ненулев изходен код, когато има тест, който е неуспешен КРИТИЧНО. Можете също да активирате подобна обработка за ПРЕДУПРЕЖДЕНИЕ.

Освен това е възможно да се проверяват ресурсите за съответствие с различни версии на API (както в kubeval). Тази информация обаче е твърдо кодирана в самия kube-score: не можете да изберете различна версия на Kubernetes. Това ограничение може да бъде голям проблем, ако възнамерявате да надстроите своя клъстер или ако имате няколко клъстера с различни версии на K8s.

Моля, имайте предвид, че вече има проблем с предложение за реализиране на тази възможност.

Повече информация за kube-score можете да намерите на официален сайт.

Kube-score тестовете са чудесен инструмент за внедряване на най-добри практики, но какво ще стане, ако трябва да направите промени в теста или да добавите свои собствени правила? Уви, това не може да стане.

Kube-score не е разширяем: не можете да добавяте политики към него или да ги коригирате.

Ако трябва да напишете персонализирани тестове, за да проверите съответствието с фирмените политики, можете да използвате един от следните четири инструмента: config-lint, copper, conftest или polaris.

3.Config-lint

Config-lint е инструмент за валидиране на YAML, JSON, Terraform, CSV конфигурационни файлове и манифести на Kubernetes.

Можете да го инсталирате с помощта на инструкции на уебсайта на проекта.

Текущата версия към момента на писане на оригиналната статия е 1.5.0.

Config-lint няма вградени тестове за валидиране на манифестите на Kubernetes.

За да провеждате тестове, трябва да създадете подходящи правила. Те са написани в YAML файлове, наречени "rulesets" (набори от правила)и имат следната структура:

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

(rule.yaml)

Нека го проучим по-отблизо:

• Област type указва какъв тип конфигурация ще използва config-lint. За манифестите на K8s това е винаги Kubernetes.
• В областта files В допълнение към самите файлове можете да посочите директория.
• Област rules предназначен за настройка на потребителски тестове.

Да приемем, че искате да сте сигурни, че изображенията в Deployment винаги се изтеглят от надеждно хранилище като 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)

Всяко правило трябва да има следните атрибути:

• id — уникален идентификатор на правилото;
• severity - Може би НЕУСПЕХ, ПРЕДУПРЕЖДЕНИЕ и NON_COMPLIANT;
• message — ако правилото е нарушено, се показва съдържанието на този ред;
• resource — вида на ресурса, за който се прилага това правило;
• assertions — списък с условия, които ще бъдат оценени във връзка с този ресурс.

В горното правило assertion нарича every проверява дали всички контейнери са в Разполагане (key: spec.templates.spec.containers) използвайте надеждни изображения (т.е. като започнете с my-company.com/).

Пълният набор от правила изглежда така:

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. Нека направим проверка на файла 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 е обещаваща рамка, която ви позволява да създавате свои собствени тестове за валидиране на Kubernetes YAML манифести с помощта на YAML DSL.

Но какво ще стане, ако имате нужда от по-сложна логика и тестове? YAML не е ли твърде ограничен за това? Какво ще стане, ако можете да създавате тестове на пълен език за програмиране?

4. Мед

Мед V2 е рамка за валидиране на манифести с помощта на персонализирани тестове (подобно на config-lint).

Въпреки това, той се различава от последния по това, че не използва YAML за описване на тестове. Вместо това тестовете могат да бъдат написани на JavaScript. Copper предоставя библиотека с няколко основни инструмента, които ви помагат да четете информация за обектите на Kubernetes и да съобщавате за грешки.

Стъпките за инсталиране на Copper могат да бъдат намерени в официална документация.

2.0.1 е най-новата версия на тази помощна програма към момента на писане на оригиналната статия.

Подобно на config-lint, Copper няма вградени тестове. Да напишем едно. Нека провери дали внедряванията използват изображения на контейнери изключително от надеждни хранилища като my-company.com.

Създайте файл check_image_repo.js със следното съдържание:

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

Сега да тестваме нашия манифест base-valid.yaml, използвайте командата 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

Ясно е, че с помощта на мед можете да извършвате по-сложни тестове - например проверка на имената на домейни в манифестите на Ingress или отхвърляне на подове, работещи в привилегирован режим.

Медта има различни полезни функции, вградени в нея:

• DockerImage чете посочения входен файл и създава обект със следните атрибути:
  • name - име на изображението,
  • tag - етикет на изображението,
  • registry - регистър на изображенията,
  • registry_url - протокол (https://) и регистър на изображенията,
  • fqin — пълно местоположение на изображението.
• Функция findByName помага за намиране на ресурс по даден тип (kind) и име (name) от входния файл.
• Функция findByLabels помага да се намери ресурс по определен тип (kind) и етикети (labels).

Можете да видите всички налични сервизни функции тук.

По подразбиране той зарежда целия входен YAML файл в променлива $$ и го прави достъпен за скриптове (позната техника за тези с опит в jQuery).

Основното предимство на Copper е очевидно: не е необходимо да владеете специализиран език и можете да използвате различни функции на JavaScript, за да създавате свои собствени тестове, като интерполация на низове, функции и т.н.

Трябва също да се отбележи, че текущата версия на Copper работи с версията ES5 на двигателя на JavaScript, а не с ES6.

Подробности са налични на официалния уебсайт на проекта.

Ако обаче наистина не харесвате JavaScript и предпочитате език, специално създаден за създаване на заявки и описване на политики, трябва да обърнете внимание на conftest.

5. Конкурс

Conftest е рамка за тестване на конфигурационни данни. Също така подходящ за тестване/проверка на Kubernetes манифести. Тестовете са описани с помощта на специализиран език за заявки Рего.

Можете да инсталирате conftest, като използвате инструкцииизброени на уебсайта на проекта.

Към момента на писане на оригиналната статия последната налична версия беше 0.18.2.

Подобно на config-lint и copper, conftest идва без никакви вградени тестове. Нека да го изпробваме и да напишем нашата собствена политика. Както в предишните примери, ще проверим дали изображенията на контейнера са взети от надежден източник.

Създайте директория conftest-checks, а в него има файл с име check_image_registry.rego със следното съдържание:

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

Сега нека тестваме base-valid.yaml през 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

Тестът очаквано се провали, защото изображенията идват от ненадежден източник.

Във файла Rego дефинираме блока deny. Истината му се счита за нарушение. Ако блокове deny няколко, conftest ги проверява независимо един от друг и истинността на всеки от блоковете се третира като нарушение.

В допълнение към изхода по подразбиране, conftest поддържа JSON, TAP и табличен формат - изключително полезна функция, ако трябва да вградите отчети в съществуващ CI канал. Можете да зададете желания формат с помощта на флага --output.

За да улесни отстраняването на грешки в политиките, conftest има флаг --trace. Той извежда следа за това как conftest анализира посочените файлове с правила.

Политиките на конкурса могат да бъдат публикувани и споделяни в регистрите на OCI (Open Container Initiative) като артефакти.

команди push и pull ви позволяват да публикувате артефакт или да извлечете съществуващ артефакт от отдалечен регистър. Нека опитаме да публикуваме политиката, която създадохме, в локалния регистър на Docker, използвайки conftest push.

Стартирайте вашия локален регистър на Docker:

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

В друг терминал отидете в директорията, която сте създали по-рано conftest-checks и изпълнете следната команда:

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

Ако командата е била успешна, ще видите съобщение като това:

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

Сега създайте временна директория и изпълнете командата в нея conftest pull. Той ще изтегли пакета, създаден от предишната команда:

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

Във временната директория ще се появи поддиректория policyсъдържащ нашия файл с правила:

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

Тестовете могат да се изпълняват директно от хранилището:

$ 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

За съжаление, DockerHub все още не се поддържа. Така че считайте се за късметлия, ако използвате Регистър на контейнери Azure (ACR) или вашия собствен регистър.

Форматът на артефакта е същият като Отворете пакетите на агента за политики (OPA), което ви позволява да използвате conftest за изпълнение на тестове от съществуващи OPA пакети.

Можете да научите повече за споделянето на политики и други функции на confest на официалния уебсайт на проекта.

6. Полярната звезда

Последният инструмент, който ще бъде обсъден в тази статия, е Полярната звезда. (Неговото миналогодишно съобщение ние вече е преведено - прибл. превод)

Polaris може да се инсталира в клъстер или да се използва в режим на команден ред. Както може би се досещате, това ви позволява да анализирате статично манифестите на Kubernetes.

Когато се изпълнява в режим на команден ред, са налични вградени тестове, обхващащи области като сигурност и най-добри практики (подобно на kube-score). Освен това можете да създадете свои собствени тестове (както в config-lint, copper и conftest).

С други думи, Polaris съчетава предимствата на двете категории инструменти: с вградени и персонализирани тестове.

За да инсталирате Polaris в режим на команден ред, използвайте инструкции на уебсайта на проекта.

Към момента на писане на оригиналната статия е налична версия 1.0.3.

След като инсталацията приключи, можете да стартирате polaris на манифеста 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": [
    /* длинный список */
  ]
}

Наличен пълен изход тук.

Подобно на kube-score, Polaris идентифицира проблеми в области, където манифестът не отговаря на най-добрите практики:

• Няма здравни прегледи за подс.
• Тагове за изображения на контейнери не са посочени.
• Контейнерът работи като root.
• Заявки и лимити за памет и процесор не са посочени.

На всеки тест, в зависимост от неговите резултати, се определя степен на критичност: предупреждение или опасност. За да научите повече за наличните вградени тестове, вижте документация.

Ако не са необходими подробности, можете да посочите флага --format score. В този случай Polaris ще изведе число в диапазона от 1 до 100 − резултат (т.е. оценка):

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

Колкото по-близо е резултатът до 100, толкова по-висока е степента на съгласие. Ако проверите изходния код на командата polaris audit, се оказва, че е равно на 0.

Сила polaris audit Можете да прекратите работата с ненулев код, като използвате два флага:

• флаг --set-exit-code-below-score приема като аргумент прагова стойност в диапазона 1-100. В този случай командата ще излезе с код за изход 4, ако резултатът е под прага. Това е много полезно, когато имате определена прагова стойност (да речем 75) и трябва да получите предупреждение, ако резултатът падне под него.
• флаг --set-exit-code-on-danger ще доведе до неуспех на командата с код 3, ако един от тестовете за опасност е неуспешен.

Сега нека се опитаме да създадем персонализиран тест, който проверява дали изображението е взето от надеждно хранилище. Персонализираните тестове са посочени във формат YAML, а самият тест е описан с помощта на JSON схема.

Следният YAML кодов фрагмент описва нов тест, извикан 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/.+$

Нека го разгледаме по-отблизо:

• successMessage — този ред ще бъде отпечатан, ако тестът завърши успешно;
• failureMessage — това съобщение ще се покаже в случай на повреда;
• category — посочва една от категориите: Images, Health Checks, Security, Networking и Resources;
• target--- определя какъв тип обект (spec) се прилага тест. Възможни стойности: Container, Pod или Controller;
• Самият тест е посочен в обекта schema използвайки JSON схема. Ключовата дума в този тест е pattern използва се за сравняване на източника на изображение с необходимия.

За да изпълните горния тест, трябва да създадете следната конфигурация на Polaris:

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

(polaris-conf.yaml)

Нека анализираме файла:

• В областта checks предписват се тестове и тяхното ниво на критичност. Тъй като е желателно да получите предупреждение, когато изображение е взето от ненадежден източник, ние задаваме нивото тук danger.
• Самият тест checkImageRepo след това регистриран в обекта customChecks.

Запазете файла като custom_check.yaml. Сега можете да бягате polaris audit с YAML манифест, който изисква проверка.

Нека тестваме нашия манифест base-valid.yaml:

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

Отбор polaris audit изпълни само потребителския тест, посочен по-горе, и не успя.

Ако коригирате изображението към my-company.com/http-echo:1.0, Polaris ще завърши успешно. Манифестът с промените вече е в сила хранилищатака че можете да проверите предишната команда в манифеста 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)

Наличен е пример за пълен конфигурационен файл тук.

Проверете манифеста base-valid.yamlизползвайки вградени и потребителски тестове, можете да използвате командата:

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

Polaris допълва вградените тестове с персонализирани, като по този начин съчетава най-доброто от двата свята.

От друга страна, невъзможността да се използват по-мощни езици като Rego или JavaScript може да бъде ограничаващ фактор, предотвратяващ създаването на по-сложни тестове.

Повече информация за Polaris можете да намерите на сайт на проекта.

Обобщение

Въпреки че има много налични инструменти за проверка и оценка на Kubernetes YAML файлове, важно е да имате ясно разбиране за това как ще бъдат проектирани и изпълнени тестовете.

Например, ако вземете манифестите на Kubernetes, преминаващи през тръбопровод, kubeval може да бъде първата стъпка в такъв тръбопровод. Ще следи дали дефинициите на обекти съответстват на схемата на Kubernetes API.

След като такъв преглед приключи, може да се премине към по-сложни тестове, като съответствие със стандартните най-добри практики и конкретни политики. Това е мястото, където kube-score и Polaris биха били полезни.

За тези, които имат сложни изисквания и трябва да персонализират тестовете в детайли, мед, config-lint и conftest биха били подходящи.

Conftest и config-lint използват YAML за дефиниране на персонализирани тестове, а copper ви дава достъп до пълен език за програмиране, което го прави доста привлекателен избор.

От друга страна, струва ли си да използвате един от тези инструменти и следователно да създавате всички тестове ръчно или да предпочетете Polaris и да добавите само това, което е необходимо към него? Няма ясен отговор на този въпрос.

Таблицата по-долу предоставя кратко описание на всеки инструмент:

Инструмент
съдба
Ограничения
Потребителски тестове

кубевал
Валидира YAML манифестите спрямо конкретна версия на API схемата
Не може да работи с CRD
Не

kube-резултат
Анализира YAML манифестите спрямо най-добрите практики
Не мога да избера вашата версия на Kubernetes API за проверка на ресурсите
Не

мед
Обща рамка за създаване на персонализирани JavaScript тестове за YAML манифести
Няма вградени тестове. Лоша документация
Да

config-lint
Обща рамка за създаване на тестове на специфичен за домейн език, вграден в YAML. Поддържа различни конфигурационни формати (напр. Terraform)
Няма готови тестове. Вградените твърдения и функции може да не са достатъчни
Да

конкурс
Рамка за създаване на ваши собствени тестове с помощта на Rego (специализиран език за заявки). Позволява споделяне на политики чрез OCI пакети
Няма вградени тестове. Трябва да науча Rego. Docker Hub не се поддържа при публикуване на правила
Да

Полярната звезда
Преглежда YAML манифестите спрямо стандартните най-добри практики. Позволява ви да създавате свои собствени тестове с помощта на JSON Schema
Възможностите за тестване на базата на JSON схема може да не са достатъчни
Да

Тъй като тези инструменти не разчитат на достъп до клъстера Kubernetes, те са лесни за инсталиране. Те ви позволяват да филтрирате изходните файлове и да предоставяте бърза обратна връзка на авторите на заявки за изтегляне в проекти.

PS от преводача

Прочетете също в нашия блог:

• «Polaris е въведен, за да поддържа клъстерите на Kubernetes здрави»;
• «Vim с YAML поддръжка за Kubernetes»;
• «7-те най-добри практики за контейнери на Google".

Източник: www.habr.com