🥇ベストプラクティスとポリシーに照らして Kubernetes YAML を検証する

ノート。翻訳。: K8s 環境の YAML 構成の数が増えるにつれ、自動検証の必要性がますます高まっています。このレビューの著者は、このタスク用に既存のソリューションを選択しただけでなく、展開を例として使用して、それらがどのように機能するかを確認しました。このトピックに興味がある人にとっては非常に有益であることがわかりました。

TL; DR: この記事では、ベストプラクティスと要件に照らして Kubernetes YAML ファイルを検証および評価するための XNUMX つの静的ツールを比較します。

Kubernetes ワークロードは通常、YAML ドキュメントの形式で定義されます。 YAML の問題の XNUMX つは、マニフェストファイル間の制約や関係を指定することが難しいことです。

クラスターにデプロイされたすべてのイメージが信頼できるレジストリーからのものであることを確認する必要がある場合はどうすればよいでしょうか?

PodDisruptionBudget を持たないデプロイメントがクラスターに送信されないようにするにはどうすればよいですか?

静的テストを統合すると、開発段階でエラーやポリシー違反を特定できます。これにより、リソース定義が正しく安全であるという保証が強化され、実稼働ワークロードがベストプラクティスに従う可能性が高くなります。

Kubernetes の静的 YAML ファイル検査エコシステムは、次のカテゴリに分類できます。

APIバリデーター。このカテゴリのツールは、Kubernetes API サーバーの要件に対して YAML マニフェストをチェックします。
準備ができたテスター。このカテゴリのツールには、セキュリティ、ベストプラクティスへの準拠などのための既製のテストが付属しています。
カスタムバリデーター。このカテゴリの代表的なものを使用すると、Rego や Javascript などのさまざまな言語でカスタムテストを作成できます。

この記事では、XNUMX つの異なるツールについて説明し、比較します。

クベヴァル。
kubeスコア;
設定-lint;
銅;
コンテスト。
ポラリス。

さあ、始めましょう！

デプロイメントの確認

ツールの比較を始める前に、ツールをテストするための背景を作成しましょう。

以下のマニフェストには、多数のエラーとベストプラクティスへの違反が含まれています。そのうちのいくつかを見つけることができますか?

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リポジトリ.

マニフェストには、ポート 5678 に「Hello World」メッセージで応答することを主なタスクとする Web アプリケーションが記述されています。これは、次のコマンドでデプロイできます。

kubectl apply -f hello-world.yaml

そして、作業を確認してください。

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

今すぐに行きます http://localhost:8080 アプリケーションが動作していることを確認します。しかし、それはベストプラクティスに従っているでしょうか? 確認しよう。

1.クベヴァル

心の中でクベヴァル Kubernetes とのやり取りは REST API を通じて行われるという考え方です。つまり、API スキーマを使用して、特定の YAML がそれに準拠しているかどうかを確認できます。例を見てみましょう。

インストール手順 kubeval はプロジェクト Web サイトから入手できます。

元の記事の執筆時点では、バージョン 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 は最新の 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 はディレクトリや標準入力も操作できます。

さらに、Kubeval は CI パイプラインに簡単に統合できます。 マニフェストをクラスターに送信する前にテストを実行したい場合は、kubeval が XNUMX つの出力形式をサポートしていることを知っておいてください。

プレーンテキスト。
JSON;
テストエニシングプロトコル (TAP)。

また、いずれの形式も出力をさらに解析して、目的のタイプの結果の概要を生成するために使用できます。

kubeval の欠点の XNUMX つは、現時点ではカスタムリソース定義 (CRD) への準拠をチェックできないことです。 ただし、kubeval を構成することは可能です無視してください.

Kubeval は、リソースを確認および評価するための優れたツールです。ただし、テストに合格したからといって、リソースがベストプラクティスに準拠していることが保証されるわけではないことを強調しておく必要があります。

たとえば、タグを使用すると、 latest コンテナ内での使用はベストプラクティスに従っていません。ただし、kubeval はこれをエラーとはみなさず、報告しません。つまり、このような YAML の検証は警告なしで完了します。

しかし、YAML を評価してタグのような違反を特定したい場合はどうすればよいでしょうか latest? YAML ファイルをベストプラクティスと照合してチェックするにはどうすればよいですか?

2. キューブスコア

キューブスコア YAML マニフェストを解析し、組み込みテストに対して評価します。これらのテストは、次のようなセキュリティガイドラインとベストプラクティスに基づいて選択されます。

root としてではなくコンテナを実行します。
ポッドのヘルスチェックの可用性。
リソースのリクエストと制限を設定します。

テスト結果に基づいて、次の XNUMX つの結果が得られます。 OK, 警告 и CRITICAL.

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 すべての型違反を含む情報を人間が判読できる形式で表示します警告 и CRITICAL、開発中に非常に役立ちます。

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 はテストが失敗した場合にゼロ以外の終了コードを返します。 CRITICAL。同様の処理を有効にすることもできます警告.

さらに、リソースがさまざまな API バージョン (kubeval など) に準拠しているかどうかを確認することもできます。ただし、この情報は kube-score 自体にハードコーディングされているため、別のバージョンの Kubernetes を選択することはできません。クラスターをアップグレードする予定がある場合、または異なるバージョンの K8 が含まれる複数のクラスターがある場合、この制限は大きな問題となる可能性があります。

ご了承くださいすでに問題がありますこの機会を実現するためのご提案をさせていただきます。

kube-score の詳細については、次のサイトを参照してください。公式サイト.

Kube スコアテストは、ベストプラクティスを実装するための優れたツールですが、テストに変更を加えたり、独自のルールを追加したりする必要がある場合はどうすればよいでしょうか? 残念ながら、これはできません。

Kube スコアは拡張可能ではありません。ポリシーを追加したり、調整したりすることはできません。

会社のポリシーへの準拠を検証するためにカスタムテストを作成する必要がある場合は、config-lint、Copper、conftest、または Polaris の XNUMX つのツールのいずれかを使用できます。

3.Config-lint

Config-lint は、YAML、JSON、Terraform、CSV 構成ファイル、および Kubernetes マニフェストを検証するためのツールです。

を使用してインストールできます手順プロジェクトのウェブサイトで。

元の記事の執筆時点での現在のリリースは 1.5.0 です。

Config-lint には、Kubernetes マニフェストを検証するための組み込みテストがありません。

テストを実行するには、適切なルールを作成する必要があります。これらは「ルールセット」と呼ばれる YAML ファイルに記述されます。 (ルールセット)、次の構造を持っています。

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 - 多分故障, 警告 и 非準拠;
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

銅の助けを借りて、より複雑なテストを実行できることは明らかです。たとえば、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 や銅と同様に、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 パッケージからテストを実行できます。

ポリシー共有や conftest のその他の機能について詳しくは、次の Web サイトをご覧ください。プロジェクトの公式ウェブサイト.

6。ポラリス

この記事で説明する最後のツールは、ポラリス. （彼の昨年の発表では、すでに翻訳済み - 約。翻訳)

Polaris はクラスターにインストールすることも、コマンドラインモードで使用することもできます。ご想像のとおり、Kubernetes マニフェストを静的に分析できるようになります。

コマンドラインモードで実行する場合、セキュリティやベストプラクティス (kube-score と同様) などの領域をカバーする組み込みテストを利用できます。さらに、独自のテストを作成することもできます (config-lint、copper、conftest など)。

言い換えれば、Polaris は、組み込みテストとカスタムテストという両方のカテゴリのツールの利点を組み合わせています。

Polaris をコマンドラインモードでインストールするには、次を使用します。プロジェクトの Web サイトにある手順.

元の記事の執筆時点では、バージョン 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 として実行されます。
メモリと 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 — は次のカテゴリの XNUMX つを示します。 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, ポラリスは正常に完了します。 変更を含むマニフェストはすでに作成されていますリポジトリマニフェストで前のコマンドを確認できるようにします 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 の詳細については、次の Web サイトを参照してください。プロジェクトサイト.

サマリー

Kubernetes YAML ファイルを検査および評価するために利用できるツールは数多くありますが、 テストがどのように設計され実行されるかを明確に理解することが重要です.

たとえば、 Kubernetes マニフェストをパイプライン経由で取得する場合、kubeval がそのようなパイプラインの最初のステップとなる可能性があります。。オブジェクト定義が Kubernetes API スキーマに準拠しているかどうかを監視します。

このようなレビューが完了すると、標準のベストプラクティスや特定のポリシーへの準拠など、より高度なテストに進むことができます。ここで、kube-score と Polaris が役に立ちます。

複雑な要件があり、テストを詳細にカスタマイズする必要がある場合は、Copper、config-lint、conftest が適しています。.

Conftest と config-lint は YAML を使用してカスタムテストを定義し、Copper を使用すると完全なプログラミング言語にアクセスできるため、非常に魅力的な選択肢になります。

一方、これらのツールのいずれかを使用してすべてのテストを手動で作成する価値があるでしょうか。それとも、Polaris を使用して必要なものだけを追加する価値があるのでしょうか? この質問に対する明確な答えはありません.

以下の表に、各ツールの簡単な説明を示します。

ツール
目的
制限事項
ユーザーテスト

クベヴァル
YAML マニフェストを API スキーマの特定のバージョンに対して検証します
CRDでは動作しません
ノー

kube-スコア
ベストプラクティスに照らして YAML マニフェストを分析します
リソースを確認するために Kubernetes API バージョンを選択できません
ノー

銅
YAML マニフェストのカスタム JavaScript テストを作成するための一般的なフレームワーク
組み込みのテストはありません。不十分なドキュメント
はい

構成-lint
YAML に埋め込まれたドメイン固有言語でテストを作成するための一般的なフレームワーク。さまざまな構成フォーマットをサポート (例: Terraform)
既製のテストはありません。組み込みのアサーションと関数では十分ではない可能性があります
はい

コンテスト
Rego (特殊なクエリ言語) を使用して独自のテストを作成するためのフレームワーク。 OCIバンドルを介したポリシーの共有を許可します
組み込みのテストはありません。レゴを学ばなければなりません。ポリシーを公開する場合、Docker Hub はサポートされません
はい

ポラリス
標準のベストプラクティスに照らして YAML マニフェストをレビューします。 JSON スキーマを使用して独自のテストを作成できます
JSON スキーマに基づくテスト機能では十分ではない可能性があります
はい

これらのツールは Kubernetes クラスターへのアクセスに依存しないため、インストールが簡単です。これらを使用すると、ソースファイルをフィルタリングし、プロジェクト内のプルリクエストの作成者に迅速なフィードバックを提供できます。

翻訳者からの追伸

私たちのブログもお読みください:

出所： habr.com

ベスト プラクティスとポリシーに照らして Kubernetes YAML を検証する

デプロイメントの確認

1.クベヴァル

2. キューブスコア

3.Config-lint

4。 銅

5.コンテスト

6。 ポラリス

サマリー

翻訳者からの追伸

コメントを追加します 返信をキャンセル

ベストプラクティスとポリシーに照らして Kubernetes YAML を検証する

4。銅

6。ポラリス

コメントを追加します返信をキャンセル