모범 사례 및 정책을 기준으로 Kubernetes YAML 검증

메모. 번역: K8s 환경에 대한 YAML 구성의 수가 증가함에 따라 자동화된 검증의 필요성이 점점 더 시급해지고 있습니다. 이 리뷰의 작성자는 이 작업을 위해 기존 솔루션을 선택했을 뿐만 아니라 배포를 예로 들어 작동 방식을 확인했습니다. 이 주제에 관심이 있는 분들에게는 매우 유익한 내용이었습니다.

TL; DR: 이 문서에서는 모범 사례 및 요구 사항에 따라 Kubernetes YAML 파일을 검증하고 평가하는 XNUMX가지 정적 도구를 비교합니다.

Kubernetes 워크로드는 일반적으로 YAML 문서 형식으로 정의됩니다. YAML의 문제점 중 하나는 매니페스트 파일 간의 제약 조건이나 관계를 지정하기 어렵다는 것입니다.

클러스터에 배포된 모든 이미지가 신뢰할 수 있는 레지스트리에서 가져온 것인지 확인해야 하는 경우 어떻게 해야 합니까?

PodDisruptionBudget이 없는 배포가 클러스터로 전송되는 것을 방지하려면 어떻게 해야 합니까?

정적 테스트를 통합하면 개발 단계에서 오류 및 정책 위반을 식별할 수 있습니다. 이를 통해 리소스 정의가 정확하고 안전하다는 보장이 강화되고 프로덕션 워크로드가 모범 사례를 따를 가능성이 높아집니다.

Kubernetes 정적 YAML 파일 검사 에코시스템은 다음 범주로 나눌 수 있습니다.

• API 유효성 검사기. 이 카테고리의 도구는 Kubernetes API 서버의 요구 사항에 대해 YAML 매니페스트를 확인합니다.
• 준비된 테스터. 이 카테고리의 도구에는 보안, 모범 사례 준수 등에 대한 기성 테스트가 함께 제공됩니다.
• 맞춤 유효성 검사기. 이 카테고리의 대표자를 사용하면 Rego 및 Javascript와 같은 다양한 언어로 사용자 정의 테스트를 만들 수 있습니다.

이 글에서는 다음과 같은 XNUMX가지 도구를 설명하고 비교해 보겠습니다.

1. 큐브발;
2. 큐브 점수;
3. 구성 린트;
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 이 기사의 다른 선언문은 다음에서 찾을 수 있습니다. 힘내 저장소.

매니페스트는 포트 5678에 "Hello World" 메시지로 응답하는 것이 주요 작업인 웹 애플리케이션을 설명합니다. 다음 명령을 사용하여 배포할 수 있습니다.

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은 오류를 보고하고 XNUMX이 아닌 코드로 종료되었습니다.

그렇게 하면 어떻게 될지 궁금해요 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은 최신 Kubernetes API 스키마에 대해 리소스를 확인합니다. 그러나 대부분의 경우 특정 Kubernetes 릴리스를 확인해야 할 수도 있습니다. 이는 플래그를 사용하여 수행할 수 있습니다. --kubernetes-version:

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

버전은 다음 형식으로 지정되어야 합니다. Major.Minor.Patch.

검증이 지원되는 버전 목록은 다음을 참조하세요. GitHub의 JSON 스키마, kubeval이 유효성 검사에 사용하는 것입니다. kubeval을 오프라인으로 실행해야 하는 경우 스키마를 다운로드하고 플래그를 사용하여 로컬 위치를 지정하세요. --schema-location.

개별 YAML 파일 외에도 kubeval은 디렉터리 및 stdin에서도 작동할 수 있습니다.

또한 Kubeval은 CI 파이프라인에 쉽게 통합됩니다. 클러스터에 매니페스트를 보내기 전에 테스트를 실행하려는 경우 kubeval이 세 가지 출력 형식을 지원한다는 사실을 알게 되면 기뻐할 것입니다.

1. 일반 텍스트;
2. JSON;
3. TAP(무엇이든 테스트 프로토콜).

그리고 원하는 유형의 결과 요약을 생성하기 위해 출력을 추가로 구문 분석하는 데 모든 형식을 사용할 수 있습니다.

kubeval의 단점 중 하나는 현재 CRD(사용자 정의 리소스 정의) 준수 여부를 확인할 수 없다는 것입니다. 그러나 kubeval을 구성하는 것은 가능합니다. 그들을 무시하라.

Kubeval은 리소스를 확인하고 평가하는 훌륭한 도구입니다. 그러나 테스트를 통과한다고 해서 리소스가 모범 사례를 준수한다고 보장되는 것은 아니라는 점을 강조해야 합니다.

예를 들어 태그를 사용하면 latest 컨테이너에서는 모범 사례를 따르지 않습니다. 그러나 kubeval은 이를 오류로 간주하지 않으며 이를 보고하지 않습니다. 즉, 해당 YAML의 확인은 경고 없이 완료됩니다.

하지만 YAML을 평가하고 태그와 같은 위반을 식별하려면 어떻게 해야 할까요? latest? 모범 사례와 비교하여 YAML 파일을 확인하려면 어떻게 해야 합니까?

2. 큐브 점수

큐브 점수 YAML 매니페스트를 구문 분석하고 내장 테스트와 비교하여 평가합니다. 이러한 테스트는 다음과 같은 보안 지침 및 모범 사례를 기반으로 선택됩니다.

• 루트가 아닌 컨테이너를 실행합니다.
• 포드 상태 확인이 가능합니다.
• 리소스에 대한 요청 및 제한을 설정합니다.

테스트 결과에 따라 세 가지 결과가 제공됩니다. 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 리소스 및 메모리에 대한 요청이나 제한이 없습니다.
• 포드 중단 예산이 지정되지 않았습니다.
• 이별의 법칙은 없다 (반친화성) 가용성을 극대화합니다.
• 컨테이너는 루트로 실행됩니다.

이는 모두 배포를 보다 효율적이고 안정적으로 만들기 위해 해결해야 하는 단점에 대한 유효한 사항입니다.

팀 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는 실패한 테스트가 있는 경우 XNUMX이 아닌 종료 코드를 반환합니다. 결정적인. 다음에 대해 유사한 처리를 활성화할 수도 있습니다. 경고.

또한 kubeval에서와 같이 리소스가 다양한 API 버전을 준수하는지 확인할 수 있습니다. 그러나 이 정보는 kube-score 자체에 하드코딩되어 있으므로 다른 버전의 Kubernetes를 선택할 수 없습니다. 클러스터를 업그레이드하려는 경우 또는 K8 버전이 서로 다른 클러스터가 여러 개 있는 경우 이러한 제한은 큰 문제가 될 수 있습니다.

참고 이미 문제가 있어 이 기회를 실현하자는 제안으로.

kube-score에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 공식 웹 사이트.

Kube-score 테스트는 모범 사례를 구현하기 위한 훌륭한 도구입니다. 하지만 테스트를 변경하거나 자체 규칙을 추가해야 하는 경우에는 어떻게 해야 할까요? 아쉽게도 이것은 불가능합니다.

Kube-score는 확장이 불가능합니다. 정책을 추가하거나 조정할 수 없습니다.

회사 정책 준수 여부를 확인하기 위해 사용자 정의 테스트를 작성해야 하는 경우 config-lint, Copper, conftest 또는 polaris의 네 가지 도구 중 하나를 사용할 수 있습니다.

3.구성 린트

Config-lint는 YAML, JSON, Terraform, CSV 구성 파일 및 Kubernetes 매니페스트를 검증하기 위한 도구입니다.

다음을 사용하여 설치할 수 있습니다. 지침 프로젝트 웹사이트에서.

원본 기사를 작성하는 시점의 현재 릴리스는 1.5.0입니다.

Config-lint에는 Kubernetes 매니페스트 검증을 위한 내장 테스트가 없습니다.

테스트를 수행하려면 적절한 규칙을 만들어야 합니다. "ruleset"이라는 YAML 파일로 작성됩니다. (규칙 세트)이며 다음과 같은 구조를 갖습니다.

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

(rule.yaml)

좀 더 자세히 연구해 보겠습니다.

• 분야 type config-lint가 사용할 구성 유형을 지정합니다. K8의 경우 이는 다음과 같습니다. 항상 Kubernetes.
• 현장에서 files 파일 자체 외에도 디렉터리를 지정할 수 있습니다.
• 분야 rules 사용자 테스트를 설정하기 위한 것입니다.

배포의 이미지가 항상 다음과 같은 신뢰할 수 있는 저장소에서 다운로드되도록 하고 싶다고 가정해 보겠습니다. 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 - 아마도 고장 분석, 경고 и 비준수;
• 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는 YAML DSL을 사용하여 Kubernetes YAML 매니페스트를 검증하기 위한 자체 테스트를 생성할 수 있는 유망한 프레임워크입니다.

하지만 더 복잡한 로직과 테스트가 필요하다면 어떻게 될까요? 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

Copper의 도움으로 Ingress 매니페스트에서 도메인 이름을 확인하거나 권한 있는 모드에서 실행되는 포드를 거부하는 등 더 복잡한 테스트를 수행할 수 있다는 것은 분명합니다.

Copper에는 다양한 유틸리티 기능이 내장되어 있습니다.

• DockerImage 지정된 입력 파일을 읽고 다음 속성을 가진 객체를 생성합니다.
  • name - 이미지 이름,
  • tag - 이미지 태그,
  • registry - 이미지 레지스트리,
  • registry_url - 규약 (https://) 및 이미지 레지스트리,
  • fqin — 이미지의 전체 위치.
• 기능 findByName 특정 유형으로 리소스를 찾는 데 도움이 됩니다(kind) 및 이름(name) 입력 파일에서.
• 기능 findByLabels 지정된 유형으로 리소스를 찾는 데 도움이 됩니다(kind) 및 라벨(labels).

사용 가능한 모든 서비스 기능을 볼 수 있습니다. 여기에.

기본적으로 전체 입력 YAML 파일을 변수로 로드합니다. $$ 스크립팅(jQuery 경험이 있는 사람들에게 친숙한 기술)에 사용할 수 있습니다.

Copper의 주요 장점은 분명합니다. 전문 언어를 마스터할 필요가 없으며 다양한 JavaScript 기능을 사용하여 문자열 보간, 함수 등과 같은 자신만의 테스트를 만들 수 있다는 것입니다.

또한 현재 버전의 Copper는 ES5이 아닌 ES6 버전의 JavaScript 엔진에서 작동한다는 점에 유의해야 합니다.

자세한 내용은 다음에서 확인할 수 있습니다. 프로젝트 공식 홈페이지.

그러나 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는 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 패키지에서 테스트를 실행할 수 있습니다.

정책 공유 및 기타 컨테스트 기능에 대해 자세히 알아볼 수 있습니다. 프로젝트 공식 홈페이지.

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는 매니페스트가 모범 사례를 충족하지 않는 영역의 문제를 식별합니다.

• 포드에 대한 상태 확인은 없습니다.
• 컨테이너 이미지의 태그가 지정되지 않았습니다.
• 컨테이너는 루트로 실행됩니다.
• 메모리 및 CPU에 대한 요청 및 제한은 지정되지 않습니다.

각 테스트는 결과에 따라 중요도가 지정됩니다. 경고 또는 위험. 사용 가능한 내장 테스트에 대해 자세히 알아보려면 다음을 참조하세요. 선적 서류 비치.

세부 사항이 필요하지 않은 경우 플래그를 지정할 수 있습니다 --format score. 이 경우 Polaris는 1부터 100까지의 숫자를 출력합니다. 점수 (예: 평가):

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

점수가 100에 가까울수록 동의 정도가 높은 것입니다. 명령의 종료 코드를 확인하면 polaris audit, 0과 같다는 것이 밝혀졌습니다.

확인 polaris audit 두 개의 플래그를 사용하여 XNUMX이 아닌 코드로 작업을 종료할 수 있습니다.

• 깃발 --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가 유용하게 사용될 수 있는 부분입니다.

요구사항이 복잡하고 테스트를 세부적으로 맞춤화해야 하는 경우에는 Copper, config-lint 및 conftest가 적합할 것입니다..

Conftest와 config-lint는 YAML을 사용하여 사용자 정의 테스트를 정의하고 Copper는 전체 프로그래밍 언어에 대한 액세스를 제공하므로 매우 매력적인 선택입니다.

반면에 이러한 도구 중 하나를 사용하여 모든 테스트를 수동으로 생성하는 것이 가치가 있습니까, 아니면 Polaris를 선호하고 필요한 것만 추가하는 것이 가치가 있습니까? 이 질문에 대한 명확한 대답은 없습니다..

아래 표에는 각 도구에 대한 간략한 설명이 나와 있습니다.

수단
목적
제한
사용자 테스트

큐브발
특정 버전의 API 스키마에 대해 YAML 매니페스트를 검증합니다.
CRD로 작업할 수 없습니다
아니

큐브 점수
모범 사례에 대해 YAML 매니페스트를 분석합니다.
리소스를 확인하기 위해 Kubernetes API 버전을 선택할 수 없습니다.
아니

구리
YAML 매니페스트에 대한 사용자 정의 JavaScript 테스트를 생성하기 위한 일반 프레임워크
내장된 테스트가 없습니다. 잘못된 문서
Да

구성 린트
YAML에 포함된 도메인별 언어로 테스트를 생성하기 위한 일반 프레임워크입니다. 다양한 구성 형식 지원(예: Terraform)
준비된 테스트는 없습니다. 내장된 주장과 함수로는 충분하지 않을 수 있습니다
Да

콘테스트
Rego(특수 쿼리 언어)를 사용하여 자신만의 테스트를 생성하기 위한 프레임워크입니다. OCI 번들을 통해 정책 공유 가능
내장된 테스트가 없습니다. 레고를 배워야 해요. 정책 게시 시 Docker Hub는 지원되지 않습니다.
Да

폴라리스
표준 모범 사례를 기준으로 YAML 매니페스트를 검토합니다. JSON 스키마를 사용하여 자체 테스트를 만들 수 있습니다.
JSON 스키마 기반 테스트 기능이 충분하지 않을 수 있음
Да

이러한 도구는 Kubernetes 클러스터에 대한 액세스에 의존하지 않으므로 설치가 쉽습니다. 이를 통해 소스 파일을 필터링하고 프로젝트의 끌어오기 요청 작성자에게 빠른 피드백을 제공할 수 있습니다.

번역가의 추신

블로그에서도 읽어보세요.

• «Kubernetes 클러스터를 건강하게 유지하기 위해 Polaris 도입";
• «Kubernetes에 대한 YAML을 지원하는 Vim";
• «Google이 제시하는 컨테이너 사용에 대한 7가지 모범 사례".

출처 : habr.com