🥇根據最佳實踐和政策驗證 Kubernetes YAML

筆記。翻譯。：隨著K8s環境的YAML配置越來越多，對其自動化驗證的需求變得越來越迫切。本次評測的作者不僅選擇了用於此任務的現有解決方案，而且還以 Deployment 為例來了解它們是如何運作的。事實證明，對於那些對此主題感興趣的人來說，這是非常有用的。

TL博士：本文比較了六種靜態工具，用於根據最佳實踐和要求驗證和評估 Kubernetes YAML 檔案。

Kubernetes 工作負載通常以 YAML 文件的形式定義。 YAML 的問題之一是難以指定清單檔案之間的約束或關係。

如果我們需要確保部署到叢集的所有映像都來自受信任的註冊表呢？

如何防止沒有 PodDisruptionBudgets 的 Deployment 被傳送到叢集？

靜態測試的整合可讓您在開發階段識別錯誤和策略違規。這提高了資源定義正確和安全的保證，並使生產工作負載更有可能遵循最佳實務。

Kubernetes靜態YAML檔案檢查生態系統可以分為以下幾類：

API驗證器。此類別中的工具會根據 Kubernetes API 伺服器的要求檢查 YAML 清單。
準備好測試人員。此類工具附帶現成的安全性測試、最佳實務合規性測試等。
自訂驗證器。此類別的代表可讓您使用各種語言建立自訂測試，例如 Rego 和 Javascript。

在本文中，我們將描述和比較六種不同的工具：

庫貝瓦爾；
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 儲存庫.

該清單描述了一個 Web 應用程序，其主要任務是向連接埠 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，必須包含與 pod 標籤相符的選擇器。上面的清單不包含選擇器，因此 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 支援三種輸出格式：

純文字;
JSON；
測試一切協定 (TAP)。

任何格式都可用於進一步解析輸出，以產生所需類型的結果摘要。

kubeval 的缺點之一是它目前無法檢查是否符合自訂資源定義 (CRD)。 但是，可以配置 kubeval 別理他們.

Kubeval 是一個檢查和評估資源的好工具；但是，應該強調的是，通過測試並不能保證資源符合最佳實務。

例如，使用標籤 latest 在容器中不遵循最佳實務。然而，kubeval 並不認為這是一個錯誤，也不會報告它。也就是說，此類 YAML 的驗證將在沒有警告的情況下完成。

但是，如果您想評估 YAML 並識別標籤之類的違規行為該怎麼辦 latest？如何根據最佳實務檢查 YAML 檔案？

2. Kube-分數

Kube-分數解析 YAML 清單並根據內建測試進行評估。這些測試是根據安全準則和最佳實踐選擇的，例如：

不以 root 身分執行容器。
Pod 健康檢查的可用性。
設定資源請求和限制。

根據測試結果，給出三個結果： 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 資源和記憶體沒有請求或限制。
未指定 Pod 中斷預算。
沒有分離的規則 （反親和力） 以最大限度地提高可用性。
容器以 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.配置-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

很明顯，在 Copper 的幫助下，您可以執行更複雜的測試 - 例如，檢查 Ingress 清單中的網域或拒絕在特權模式下執行的 pod。

Copper 內建了各種實用功能：

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（開放容器倡議）註冊表中發布和共享。

命令 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 其他功能的更多資訊：項目官方網站.

6。北極星

本文將討論的最後一個工具是 Polaris. （他去年的聲明我們已經翻譯了 - 約。翻譯)

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 可以識別清單不符合最佳實踐的區域中的問題：

沒有對 Pod 進行健康檢查。
未指定容器鏡像的標籤。
容器以 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 您可以使用兩個標誌終止非零代碼的工作：

旗 --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，北極星將成功完成。 包含這些變化的宣言已經在儲存庫這樣你就可以檢查清單上的上一個指令 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）可能成為阻止創建更複雜測試的限制因素。

有關北極星的更多信息，請訪問項目網站.

總結

雖然有許多工具可用於檢查和評估 Kubernetes YAML 文件， 清楚了解如何設計和執行測試非常重要.

例如， 如果您透過管道取得 Kubernetes 清單，那麼 kubeval 可能是此類管道中的第一步。它將監視物件定義是否符合 Kubernetes API 架構。

一旦完成這樣的審查，就可以進行更複雜的測試，例如是否符合標準最佳實踐和特定政策。這就是 kube-score 和 Polaris 派上用場的地方。

對於有複雜需求並需要詳細客製化測試的人，copper、config-lint 和 conftest 會比較合適.

Conftest 和 config-lint 使用 YAML 定義自訂測試，而 Copper 使您可以存取完整的程式語言，這使其成為一個非常有吸引力的選擇。

另一方面，是否值得使用其中一個工具並因此手動創建所有測試，或者更喜歡 Polaris 並僅添加需要的內容？ 這個問題沒有明確的答案.

下表提供了每個工具的簡要說明：

工具
命運
限制
用戶測試

庫貝瓦爾
根據特定版本的 API 架構驗證 YAML 清單
無法與 CRD 一起使用
沒有

kube-分數
根據最佳實踐分析 YAML 清單
無法選擇您的 Kubernetes API 版本來檢查資源
沒有

銅
用於為 YAML 清單建立自訂 JavaScript 測試的通用框架
沒有內建測試。文件不完善
Да

配置-lint
用於使用嵌入在 YAML 中的特定於網域的語言建立測試的通用框架。支援各種配置格式（例如 Terraform）
沒有現成的測試。內建斷言和函數可能還不夠
Да

會議測試
使用 Rego（一種專門的查詢語言）建立您自己的測試的框架。允許透過 OCI 捆綁共享策略
沒有內建測試。我得學習雷戈。發布策略時不支援 Docker Hub
Да

Polaris
根據標準最佳實踐審查 YAML 清單。允許您使用 JSON Schema 建立自己的測試
基於 JSON Schema 的測試能力可能還不夠
Да

由於這些工具不依賴對 Kubernetes 叢集的訪問，因此它們很容易安裝。它們允許您過濾原始檔案並向專案中拉取請求的作者提供快速回饋。

譯者PS

另請閱讀我們的博客：

來源： www.habr.com

根據最佳實踐和策略驗證 Kubernetes YAML

檢查部署

1.庫貝瓦爾

2. Kube-分數

3.配置-lint

4.銅

5.競賽

6。北極星

總結

譯者PS

添加評論取消回复

根據最佳實踐和策略驗證 Kubernetes YAML

檢查部署

1.庫貝瓦爾

2. Kube-分數

3.配置-lint

4.銅

5.競賽

6。 北極星

總結

譯者PS

添加評論 取消回复

6。北極星

添加評論取消回复