ProHoster > Blog > Administración > Valide Kubernetes YAML en función das mellores prácticas e políticas

Valide Kubernetes YAML en función das mellores prácticas e políticas

Nota. transl.: Co número crecente de configuracións YAML para ambientes K8s, a necesidade da súa verificación automatizada faise cada vez máis urxente. O autor desta revisión non só seleccionou solucións existentes para esta tarefa, senón que tamén utilizou Implementación como exemplo para ver como funcionan. Resultou moi informativo para os que estean interesados ​​neste tema.

Valide Kubernetes YAML en función das mellores prácticas e políticas

TL, RD: Este artigo compara seis ferramentas estáticas para validar e avaliar os ficheiros YAML de Kubernetes en función das mellores prácticas e requisitos.

As cargas de traballo de Kubernetes adoitan definirse en forma de documentos YAML. Un dos problemas con YAML é a dificultade de especificar restricións ou relacións entre ficheiros de manifesto.

E se necesitamos asegurarnos de que todas as imaxes despregadas no clúster proveñen dun rexistro de confianza?

Como podo evitar que as implementacións que non teñan PodDisruptionBudgets se envíen ao clúster?

A integración das probas estáticas permítelle identificar erros e infraccións de políticas na fase de desenvolvemento. Isto aumenta a garantía de que as definicións de recursos son correctas e seguras, e fai máis probable que as cargas de traballo de produción sigan as mellores prácticas.

O ecosistema de inspección de ficheiros YAML estático de Kubernetes pódese dividir nas seguintes categorías:

  • Validadores de API. As ferramentas desta categoría verifican o manifesto YAML cos requisitos do servidor da API de Kubernetes.
  • Probadores listos. As ferramentas desta categoría inclúen probas preparadas para a seguridade, o cumprimento das mellores prácticas, etc.
  • Validadores personalizados. Os representantes desta categoría permítenche crear probas personalizadas en varios idiomas, por exemplo, Rego e Javascript.

Neste artigo imos describir e comparar seis ferramentas diferentes:

  1. kubeval;
  2. puntuación kube;
  3. config-lint;
  4. cobre;
  5. concurso;
  6. polaris.

Ben, imos comezar!

Comprobación de implantacións

Antes de comezar a comparar ferramentas, imos crear un fondo sobre o que probalas.

O seguinte manifesto contén unha serie de erros e incumprimento das mellores prácticas: cantos deles podes atopar?

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)

Usaremos este YAML para comparar diferentes ferramentas.

O manifesto anterior base-valid.yaml e outros manifestos deste artigo pódense atopar en Repositorios Git.

O manifesto describe unha aplicación web cuxa tarefa principal é responder cunha mensaxe "Ola mundo" ao porto 5678. Pódese despregar co seguinte comando:

kubectl apply -f hello-world.yaml

E así, comproba o traballo:

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

Agora vai a http://localhost:8080 e confirma que a aplicación funciona. Pero segue as mellores prácticas? Comprobamos.

1. Kubeval

No corazón kubeval A idea é que calquera interacción con Kubernetes se produza a través da súa API REST. Noutras palabras, pode usar un esquema de API para comprobar se un determinado YAML cumpre con el. Vexamos un exemplo.

Instrucións de instalación kubeval están dispoñibles na páxina web do proxecto.

No momento de escribir o artigo orixinal, estaba dispoñible a versión 0.15.0.

Unha vez instalado, imos a alimentar o manifesto anterior:

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

Se ten éxito, kubeval sairá co código de saída 0. Podes comprobalo do seguinte xeito:

$ echo $?
0

Probemos agora kubeval cun manifesto diferente:

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)

Podes detectar o problema a simple vista? Imos lanzar:

$ 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

Non se está verificando o recurso.

Implementacións mediante a versión da API apps/v1, debe incluír un selector que coincida coa etiqueta do pod. O manifesto anterior non inclúe o selector, polo que kubeval informou dun erro e saíu cun código distinto de cero.

Pregúntome que pasará se o fago kubectl apply -f con este manifesto?

Ben, imos probar:

$ 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

Este é exactamente o erro sobre o que advertiu kubeval. Podes solucionar isto engadindo un selector:

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)

A vantaxe de ferramentas como kubeval é que estes erros poden detectarse no inicio do ciclo de implantación.

Ademais, estas comprobacións non requiren acceso ao clúster; pódense realizar sen conexión.

De forma predeterminada, kubeval comproba os recursos co último esquema da API de Kubernetes. Non obstante, na maioría dos casos é posible que teñas que comprobar unha versión específica de Kubernetes. Isto pódese facer usando a bandeira --kubernetes-version:

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

Teña en conta que a versión debe especificarse no formato Major.Minor.Patch.

Para obter unha lista de versións para as que se admite a verificación, consulte Esquema JSON en GitHub, que kubeval usa para a validación. Se precisa executar kubeval sen conexión, descargue os esquemas e especifique a súa localización local usando a marca --schema-location.

Ademais dos ficheiros YAML individuais, kubeval tamén pode funcionar con directorios e stdin.

Ademais, Kubeval intégrase facilmente na canalización de CI. Aqueles que desexen realizar probas antes de enviar manifestos ao clúster estarán encantados de saber que kubeval admite tres formatos de saída:

  1. Texto simple;
  2. JSON;
  3. Protocolo de proba de calquera cousa (TAP).

E calquera dos formatos pódese usar para analizar máis a saída para xerar un resumo dos resultados do tipo desexado.

Un dos inconvenientes de kubeval é que actualmente non pode comprobar o cumprimento das definicións de recursos personalizadas (CRD). Non obstante, é posible configurar kubeval ignoralos.

Kubeval é unha excelente ferramenta para comprobar e avaliar recursos; Non obstante, hai que subliñar que a superación da proba non garante que o recurso cumpra coas mellores prácticas.

Por exemplo, usando a etiqueta latest nun contedor non segue as mellores prácticas. Non obstante, kubeval non considera isto un erro e non o informa. É dicir, a verificación de tal YAML completarase sen avisos.

Pero que pasa se queres avaliar YAML e identificar infraccións como a etiqueta latest? Como comprobo un ficheiro YAML coas mellores prácticas?

2. Puntuación Kube

Puntuación Kube analiza os manifestos YAML e avalíaos contra as probas integradas. Estas probas son seleccionadas en función das directrices de seguridade e das mellores prácticas, como:

  • Execución do contedor non como root.
  • Dispoñibilidade de comprobacións de saúde do pod.
  • Establecemento de solicitudes e límites de recursos.

En función dos resultados da proba, dan tres resultados: OK, ATENCIÓN и CRÍTICO.

Podes probar Kube-score en liña ou instalalo localmente.

No momento de escribir o artigo orixinal, a última versión de kube-score era a 1.7.0.

Probámolo no noso manifesto 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 pasa as probas de kubeval, mentres que kube-score sinala os seguintes fallos:

  • As comprobacións de preparación non están configuradas.
  • Non hai solicitudes nin límites para os recursos da CPU e a memoria.
  • Non se especifican os orzamentos de interrupción do pod.
  • Non hai regras de separación (antiafinidade) para maximizar a dispoñibilidade.
  • O contedor execútase como root.

Todos estes son puntos válidos sobre as deficiencias que hai que abordar para facer a implantación máis eficiente e fiable.

Equipo kube-score mostra información en forma lexible por humanos, incluíndo todo tipo de violacións ATENCIÓN и CRÍTICO, que axuda moito durante o desenvolvemento.

Aqueles que desexen usar esta ferramenta dentro da canalización de CI poden activar unha saída máis comprimida usando a marca --output-format ci (neste caso, tamén se mostran as probas co resultado 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

Similar a kubeval, kube-score devolve un código de saída distinto de cero cando hai unha proba que falla CRÍTICO. Tamén podes activar un procesamento similar para ATENCIÓN.

Ademais, é posible comprobar os recursos para o cumprimento das diferentes versións da API (como en kubeval). Non obstante, esta información está codificada no propio kube-score: non pode seleccionar unha versión diferente de Kubernetes. Esta limitación pode ser un gran problema se pretendes actualizar o teu clúster ou se tes varios clústeres con diferentes versións de K8s.

Nótese que xa hai un problema cunha proposta para aproveitar esta oportunidade.

Podes atopar máis información sobre kube-score en sitio web oficial.

As probas de puntuación Kube son unha excelente ferramenta para implementar as mellores prácticas, pero e se precisas facer cambios na proba ou engadir as túas propias regras? Por desgraza, isto non se pode facer.

Kube-score non é extensible: non podes engadirlle políticas nin axustalas.

Se precisas escribir probas personalizadas para verificar o cumprimento das políticas da empresa, podes utilizar unha das catro ferramentas seguintes: config-lint, copper, conftest ou polaris.

3.Config-lint

Config-lint é unha ferramenta para validar ficheiros de configuración YAML, JSON, Terraform, CSV e manifestos de Kubernetes.

Podes instalalo usando instrucións na páxina web do proxecto.

A versión actual no momento de escribir o artigo orixinal é 1.5.0.

Config-lint non ten probas integradas para validar os manifestos de Kubernetes.

Para realizar calquera proba, cómpre crear regras adecuadas. Están escritos en ficheiros YAML chamados "conxuntos de regras" (reglamentos), e teñen a seguinte estrutura:

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

(rule.yaml)

Estudémolo máis detidamente:

  • Campo type especifica que tipo de configuración usará config-lint. Para K8s manifesta isto é sempre Kubernetes.
  • no campo files Ademais dos propios ficheiros, pode especificar un directorio.
  • Campo rules destinado a establecer probas de usuario.

Digamos que quere asegurarse de que as imaxes de Implementación se descarguen sempre dun repositorio de confianza como my-company.com/myapp:1.0. Unha regra de configuración-lint que realiza tal comprobación sería así:

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

Cada regra debe ter os seguintes atributos:

  • id — identificador único da regra;
  • severity - Pode ser FALLO, ATENCIÓN и NON_CONFORME;
  • message — se se infrinxe unha regra, móstranse o contido desta liña;
  • resource — o tipo de recurso ao que se aplica esta regra;
  • assertions — unha relación de condicións que serán avaliadas en relación con este recurso.

Na regra anterior assertion chamado every comproba que todos os contedores están en implementación (key: spec.templates.spec.containers) use imaxes fiables (é dicir, comezando por my-company.com/).

O conxunto de regras completo ten o seguinte aspecto:

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)

Para probar a proba, gardemos como check_image_repo.yaml. Imos facer unha comprobación do ficheiro 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"
  }
]

Fallou a comprobación. Agora imos ver o seguinte manifesto co repositorio de imaxes correcto:

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)

Facemos a mesma proba co manifesto anterior. Non se atoparon problemas:

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

Config-lint é un marco prometedor que che permite crear as túas propias probas para validar os manifestos YAML de Kubernetes mediante o DSL YAML.

Pero e se necesitas lóxica e probas máis complexas? YAML non é demasiado limitado para iso? E se puideses crear probas nunha linguaxe de programación completa?

4. Cobre

Cobre V2 é un marco para validar manifestos mediante probas personalizadas (semellante a config-lint).

Non obstante, difire deste último en que non usa YAML para describir as probas. As probas pódense escribir en JavaScript. Copper ofrece unha biblioteca con varias ferramentas básicas, que che axudan a ler información sobre obxectos de Kubernetes e informar de erros.

Os pasos para instalar Copper pódense atopar en documentación oficial.

2.0.1 é a última versión desta utilidade no momento de escribir o artigo orixinal.

Do mesmo xeito que config-lint, Copper non ten probas integradas. Escribamos un. Deixa que comprobe que os despregamentos usan imaxes de contedores exclusivamente de repositorios de confianza como my-company.com.

Crear un ficheiro check_image_repo.js co seguinte contido:

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

Agora a probar o noso manifesto base-valid.yaml, use o comando 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

Está claro que coa axuda do cobre podes realizar probas máis complexas, por exemplo, comprobando os nomes de dominio nos manifestos de Ingress ou rexeitando pods que se executan en modo privilexiado.

O cobre ten varias funcións de utilidade incorporadas:

  • DockerImage le o ficheiro de entrada especificado e crea un obxecto cos seguintes atributos:
    • name - nome da imaxe,
    • tag - etiqueta de imaxe,
    • registry - rexistro de imaxes,
    • registry_url - protocolo (https://) e rexistro de imaxes,
    • fqin - localización completa da imaxe.
  • Función findByName axuda a atopar un recurso por un tipo determinado (kind) e nome (name) do ficheiro de entrada.
  • Función findByLabels axuda a atopar un recurso por un tipo especificado (kind) e etiquetas (labels).

Podes ver todas as funcións de servizo dispoñibles aquí.

Por defecto, carga todo o ficheiro YAML de entrada nunha variable $$ e faino dispoñible para scripts (unha técnica familiar para aqueles con experiencia en jQuery).

A principal vantaxe de Copper é obvia: non precisa dominar unha linguaxe especializada e pode utilizar varias funcións de JavaScript para crear as súas propias probas, como interpolación de cadeas, funcións, etc.

Tamén hai que ter en conta que a versión actual de Copper funciona coa versión ES5 do motor JavaScript, non coa ES6.

Detalles dispoñibles en sitio web oficial do proxecto.

Non obstante, se non che gusta JavaScript e prefires unha linguaxe deseñada especificamente para crear consultas e describir políticas, deberías prestar atención ao concurso.

5.Concurso

Conftest é un marco para probar datos de configuración. Tamén é adecuado para probar/verificar manifestos de Kubernetes. As probas descríbense utilizando unha linguaxe de consulta especializada Rego.

Podes instalar o concurso usando instruciónslistados na páxina web do proxecto.

No momento de escribir o artigo orixinal, a última versión dispoñible era a 0.18.2.

Do mesmo xeito que config-lint e cobre, o concurso vén sen probas integradas. Probémolo e escribamos a nosa propia política. Como nos exemplos anteriores, comprobaremos se as imaxes do contedor están tomadas dunha fonte fiable.

Crear un directorio conftest-checks, e nel hai un ficheiro chamado check_image_registry.rego co seguinte contido:

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

Agora imos probar base-valid.yaml través 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

Previsiblemente, a proba fallou porque as imaxes proviñan dunha fonte non fiable.

No ficheiro Rego definimos o bloque deny. A súa verdade considérase unha violación. Se bloques deny varios, o concurso compróbaos independentemente uns dos outros, e a verdade de calquera dos bloques é tratada como unha violación.

Ademais da saída predeterminada, o concurso admite JSON, TAP e formato de táboa, unha característica moi útil se precisa incorporar informes nunha canalización de CI existente. Podes establecer o formato desexado usando a bandeira --output.

Para facilitar a depuración das políticas, o concurso ten unha bandeira --trace. Mostra un rastro de como conftest analiza os ficheiros de políticas especificados.

As políticas do concurso pódense publicar e compartir nos rexistros de OCI (Open Container Initiative) como artefactos.

Comandos push и pull permite publicar un artefacto ou recuperar un artefacto existente dun rexistro remoto. Tentemos publicar a política que creamos no rexistro local de Docker mediante conftest push.

Inicia o teu rexistro local de Docker:

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

Noutro terminal, vai ao directorio que creaches anteriormente conftest-checks e executa o seguinte comando:

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

Se o comando foi exitoso, verá unha mensaxe como esta:

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

Agora crea un directorio temporal e executa o comando nel conftest pull. Descargará o paquete creado polo comando anterior:

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

Aparecerá un subdirectorio no directorio temporal policyque contén o noso ficheiro de políticas:

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

As probas pódense executar directamente desde o repositorio:

$ 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

Desafortunadamente, DockerHub aínda non é compatible. Polo tanto, considérate afortunado se usas Rexistro de contedores de Azure (ACR) ou o seu propio rexistro.

O formato do artefacto é o mesmo que Abra os paquetes de Policy Agent (OPA), que che permite usar conftest para executar probas desde paquetes OPA existentes.

Podes obter máis información sobre o uso compartido de políticas e outras funcións do concurso en sitio web oficial do proxecto.

6. Polaris

A última ferramenta que se comentará neste artigo é Polaris. (O seu anuncio do ano pasado nós xa traducido - aprox. tradución)

Polaris pódese instalar nun clúster ou usar no modo de liña de comandos. Como xa adiviñaches, permíteche analizar de forma estática os manifestos de Kubernetes.

Cando se executa no modo de liña de comandos, hai dispoñibles probas integradas que abarcan áreas como a seguridade e as prácticas recomendadas (semellante ao kube-score). Ademais, podes crear as túas propias probas (como en config-lint, copper e conftest).

Noutras palabras, Polaris combina os beneficios de ambas categorías de ferramentas: con probas integradas e personalizadas.

Para instalar Polaris en modo de liña de comandos, use instrucións na páxina web do proxecto.

No momento de escribir o artigo orixinal, está dispoñible a versión 1.0.3.

Unha vez completada a instalación, pode executar polaris no manifesto base-valid.yaml co seguinte comando:

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

Sairá unha cadea en formato JSON cunha descrición detallada das probas realizadas e os seus resultados. A saída terá a seguinte estrutura:

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

Saída completa dispoñible aquí.

Do mesmo xeito que kube-score, Polaris identifica problemas nas áreas nas que o manifesto non cumpre coas prácticas recomendadas:

  • Non hai controis de saúde para as vainas.
  • Non se especifican as etiquetas para as imaxes do contedor.
  • O contedor execútase como root.
  • Non se especifican solicitudes e límites para a memoria e a CPU.

A cada proba, en función dos seus resultados, asígnaselle un grao de criticidade: aviso ou perigo. Para obter máis información sobre as probas integradas dispoñibles, consulte documentación.

Se non se precisan detalles, pode especificar a bandeira --format score. Neste caso, Polaris sairá un número que varía de 1 a 100 − conta (é dicir, avaliación):

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

Canto máis preto estea a puntuación de 100, maior será o grao de concordancia. Se verifica o código de saída do comando polaris audit, resulta que é igual a 0.

Forza polaris audit Podes finalizar o traballo con código distinto de cero usando dúas marcas:

  • Bandeira --set-exit-code-below-score toma como argumento un valor límite no intervalo 1-100. Neste caso, o comando sairá co código de saída 4 se a puntuación está por debaixo do limiar. Isto é moi útil cando tes un determinado valor límite (por exemplo, 75) e necesitas recibir unha alerta se a puntuación baixa.
  • Bandeira --set-exit-code-on-danger fará que o comando falle co código 3 se falla unha das probas de perigo.

Agora imos tentar crear unha proba personalizada que verifique se a imaxe está tomada dun repositorio de confianza. As probas personalizadas especifícanse en formato YAML e a propia proba descríbese mediante o esquema JSON.

O seguinte fragmento de código YAML describe unha nova proba chamada 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/.+$

Botámoslle unha ollada máis de cerca:

  • successMessage — esta liña imprimirase se a proba finaliza con éxito;
  • failureMessage — esta mensaxe mostrarase en caso de falla;
  • category - indica unha das categorías: Images, Health Checks, Security, Networking и Resources;
  • target--- determina que tipo de obxecto (spec) aplícase a proba. Valores posibles: Container, Pod ou Controller;
  • A propia proba está especificada no obxecto schema usando o esquema JSON. A palabra clave nesta proba é pattern usado para comparar a fonte da imaxe coa necesaria.

Para executar a proba anterior, cómpre crear a seguinte configuración de 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)

Imos analizar o ficheiro:

  • no campo checks prescríbense probas e o seu nivel de criticidade. Dado que é desexable recibir un aviso cando se toma unha imaxe dunha fonte non fiable, establecemos o nivel aquí danger.
  • A proba en si checkImageRepo despois rexistrado no obxecto customChecks.

Garda o ficheiro como custom_check.yaml. Agora podes correr polaris audit cun manifesto YAML que require verificación.

Probamos o noso manifesto base-valid.yaml:

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

Equipo polaris audit executou só a proba de usuario especificada anteriormente e fallou.

Se arranxas a imaxe para my-company.com/http-echo:1.0, Polaris completarase correctamente. O manifesto cos cambios xa está repositoriospara que poida comprobar o comando anterior no manifesto image-valid-mycompany.yaml.

Agora xorde a pregunta: como executar probas integradas xunto coas personalizadas? Doadamente! Só precisa engadir os identificadores de proba integrados ao ficheiro de configuración. Como resultado, adoptará a seguinte 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)

Hai un exemplo de ficheiro de configuración completo dispoñible aquí.

Comproba o manifesto base-valid.yamlusando probas integradas e personalizadas, pode usar o comando:

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

Polaris complementa as probas integradas con outras personalizadas, combinando así o mellor de ambos mundos.

Por outra banda, a incapacidade de utilizar linguaxes máis potentes como Rego ou JavaScript pode ser un factor limitante que impida a creación de probas máis sofisticadas.

Máis información sobre Polaris está dispoñible en sitio do proxecto.

Resumo

Aínda que hai moitas ferramentas dispoñibles para inspeccionar e avaliar ficheiros YAML de Kubernetes, é importante ter unha comprensión clara de como se deseñarán e executarán as probas.

Por exemplo, a se tomas os manifestos de Kubernetes pasando por unha canalización, kubeval podería ser o primeiro paso nesta canalización. Supervisaría se as definicións de obxectos se axustan ao esquema da API de Kubernetes.

Unha vez que se complete esa revisión, pódese pasar a probas máis sofisticadas, como o cumprimento das mellores prácticas estándar e políticas específicas. Aquí é onde Kube-score e Polaris serían útiles.

Para aqueles que teñen requisitos complexos e precisan personalizar as probas en detalle, serían axeitados cobre, config-lint e conftest..

Conftest e config-lint usan YAML para definir probas personalizadas, e o cobre dáche acceso a unha linguaxe de programación completa, o que o converte nunha opción bastante atractiva.

Por outra banda, paga a pena empregar unha destas ferramentas e, polo tanto, crear todas as probas manualmente, ou preferir Polaris e engadir só o necesario? Non hai unha resposta clara a esta pregunta.

A seguinte táboa ofrece unha breve descrición de cada ferramenta:

Ferramenta
Propósito
Limitacións
Probas de usuarios

kubeval
Valida os manifestos YAML contra unha versión específica do esquema da API
Non se pode traballar con CRD
Non

puntuación kube
Analiza os manifestos de YAML contra as mellores prácticas
Non se pode seleccionar a versión da API de Kubernetes para comprobar os recursos
Non

cobre
Un marco xeral para crear probas de JavaScript personalizadas para manifestos YAML
Non hai probas integradas. Pobre documentación
Si

config-lint
Un marco xeral para crear probas nunha linguaxe específica de dominio incorporada en YAML. Admite varios formatos de configuración (por exemplo, Terraform)
Non hai probas preparadas. As afirmacións e funcións integradas poden non ser suficientes
Si

concurso
Un marco para crear as súas propias probas usando Rego (unha linguaxe de consulta especializada). Permite compartir políticas mediante paquetes OCI
Non hai probas integradas. Teño que aprender Rego. Docker Hub non é compatible ao publicar políticas
Si

Polaris
Revisa os manifestos de YAML contra as prácticas recomendadas estándar. Permítelle crear as súas propias probas usando o esquema JSON
As capacidades de proba baseadas no esquema JSON poden non ser suficientes
Si

Dado que estas ferramentas non dependen do acceso ao clúster de Kubernetes, son fáciles de instalar. Permítenche filtrar ficheiros fonte e proporcionar comentarios rápidos aos autores das solicitudes de extracción nos proxectos.

PS do tradutor

Lea tamén no noso blog:

Fonte: www.habr.com

Engadir un comentario