驗證Kubernetes YAML的最佳實踐和策略

時間 2021-02-16

標籤 node git github web docker express 編程 json api 安全欄目 Git 简体版

原文原文鏈接

本文來自Rancher Labsnode

Kubernetes工做負載最多見的定義是YAML格式的文件。使用YAML所面臨的挑戰之一是，它至關難以表達manifest文件之間的約束或關係。git

若是你想檢查全部部署到集羣中的鏡像是否從受信任的鏡像倉庫中提取應該怎麼作？如何防止沒有PodDisruptionBudgets的部署被提交到集羣？github

集成靜態檢查能夠在接近開發生命週期的時候發現錯誤和策略違規。並且因爲圍繞資源定義的有效性和安全性的保證獲得了改善，你能夠相信生產工做負載是遵循最佳實踐的。web

Kubernetes YAML文件靜態檢查的生態系統能夠分爲如下幾類：docker

API驗證器：這一類工具能夠針對Kubernetes API服務器驗證給定的YAML manifest。express

內置檢查器：這一類工具捆綁了安全、最佳實踐等方面的意見檢查。編程

自定義驗證器：這一類工具容許用幾種語言編寫自定義檢查，如Rego和Javascript。json

在本文中，你將學習並比較六種不一樣的工具：api

Kubeval
Kube-score
Config-lint
Copper
Conftest
Polaris

讓咱們開始吧！安全

驗證Deployment

在開始比較工具以前，你應該設置一個基準。如下manifest並無遵循最佳實踐，可能存在一些問題，你能發現幾個問題呢？

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

咱們將會使用這個YAML文件來對比不一樣的工具。

你能夠在這個git倉庫中找到上面的YAML清單、文件 base-valid.yaml以及文章中提到的其餘manifest：

https://github.com/amitsaha/k...

manifest描述了一個老是在5678端口回覆「Hello World」消息的web應用程序。

你能夠經過如下方式部署該應用程序：

kubectl apply -f hello-world.yaml

你可使用如下命令測試它：

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

你能夠訪問http://localhost:8080 並確認該應用程序可否按照預期運行。可是它是否遵循了最佳實踐呢？

讓咱們往下看。

Kubeval

主頁：https://www.kubeval.com/

Kubeval的前提是，與Kubernetes的任何交互都要經過它的REST API。所以，你可使用API模式來驗證一個給定的YAML輸入是否符合該模式。咱們來看看一個例子。

你能夠按照項目網站上的說明來安裝kubeval，撰寫此文時最新版本是0.15.0。安裝完成以後，讓咱們用前文討論的manifest來運行它：

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

如今，讓咱們使用另外一個manifest來測試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：

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)

# let's check the return value
echo $?
1

資源並無經過驗證。使用app/v1 API版本的Deployment必須包含一個匹配Pod標籤的selector。上面的manifest沒有包含selector，針對manifest運行kubeval報告了一個錯誤和一個非零的退出代碼。

你可能想知道，當你用上面的manifest運行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警告你的錯誤。你能夠經過添加像這樣的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

像kubeval這樣的工具的好處是，你能夠在部署週期的早期發現這樣的錯誤。此外，你不須要訪問集羣來運行檢查——它們能夠離線運行。默認狀況下，kubeval會根據最新的未發佈的Kubernetes API模式驗證資源。然而，在大多數狀況下，你可能但願根據特定的Kubernetes版本運行驗證。你可使用標誌--kubernetes-version來測試特定的API版本：

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

請注意，版本應該是Major.Minor.Patch.的形式。要查看可用於驗證的版本，請查看GitHub上的JSON schema，kubeval使用它來執行驗證。

若是你須要離線運行kubeval，你能夠下載schemas，而後使用--schema-location標誌來使用本地目錄。除了單個YAML文件，你還能夠針對目錄以及標準輸入運行kubeval。你還應該知道，Kubeval易於與你的持續集成流水線集成。若是你想在提交你的manifest到集羣以前包含檢查，那麼kubeval支持三種輸出格式也許可以對你有所幫助。

純文本
JSON
測試任何東西協議(TAP)

並且你可使用其中一種格式來進一步解析輸出，以建立一個自定義的結果摘要。可是，kubeval存在一個侷限性，就是它目前還不能對自定義資源定義（CRD）進行驗證。不過kubeval能夠忽略它們。

儘管Kubeval是檢查和驗證資源的絕佳選擇，但請注意，經過測試的資源並不能保證符合最佳實踐。舉個例子，在容器鏡像中使用最新的標籤被認爲不是最佳實踐。然而，Kubeval並不會將其做爲錯誤報告，它會在沒有警告的狀況下驗證YAML。

若是你想對YAML進行打分，並抓住諸如使用最新的標籤這樣的違規行爲怎麼辦？如何根據最佳實踐檢查你的YAML文件？

Kube-score

主頁：https://github.com/zegl/kube-...

Kube-score分析YAML清單，並根據內置的檢查進行評分。這些檢查是根據安全建議和最佳實踐而選擇的，例如：

以非root用戶身份運行容器。
爲pods指定健康檢查。
定義資源請求和限制。
檢查的結果能夠是OK、WARNING或CRITICAL。

你能夠在線試用kube-score，也能夠在本地安裝。在寫這篇文章時，最新的版本是1.7.0讓咱們試着用以前的manifest 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指出了幾個不足之處。

缺乏了readiness probe
缺乏內存和CPU請求和限制。
缺乏Poddisruptionbudgets
缺乏反親和規則以最大化可用性。
容器以root身份運行。

這些都是你應該解決的有效點，以使你的部署更加健壯和可靠。kube-score命令會輸出一個可讀性高的結果，包含全部的WARNING和CRITICAL違規行爲，這在開發過程當中是很是好的。若是你打算把它做爲持續集成流水線的一部分，你能夠用--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相似，當有一個CRITICAL檢查失敗時，kube-score會返回一個非零的退出代碼，但你配置它在WARNINGs時也會失敗。還有一個內置的檢查來驗證不一樣API版本的資源，相似於kubeval。然而，這些信息是硬編碼在kube-score自己，你不能選擇不一樣的Kubernetes版本。所以，若是你升級你的集羣或你有幾個不一樣的集羣運行不一樣的版本，這可能會限制你使用這一工具。

請注意，有一個open issue能夠實現這個功能。你能夠在官方網站上了解更多關於kube-score的信息：https://github.com/zegl/kube-...

Kube-score檢查是執行最佳實踐的優秀工具，但若是你想自定義，或者添加本身的規則呢？暫時不能夠，Kube-score的設計不是可擴展的，你不能添加或調整政策。若是你想寫自定義檢查來遵照你的組織政策，你可使用接下來的四個選項之——config-lint、copper、conftest或polaris。

Config-lint

Config-lint是一個旨在驗證以YAML、JSON、Terraform、CSV和Kubernetes manifest編寫的配置文件的工具。你可使用項目網站上的說明安裝它：

https://stelligent.github.io/...

在撰寫本文時，最新的版本是1.5.0。

Config-lint沒有內置對Kubernetes manifest的檢查。你必須編寫本身的規則來執行驗證。這些規則被寫成YAML文件，稱爲規則集，具備如下結構：

version: 1
description: Rules for Kubernetes spec files
type: Kubernetes
files:
  - "*.yaml"
rules:
   # list of rules

讓咱們來詳細看看。type字段表示你將用config-lint檢查什麼類型的配置——通常是Kubernetes manifest。

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/"

每條規則必須具備如下屬性。

id——這是對規則的惟一標識。
severity——它必須是FAILURE、WARNING和NON_COMPLIANT中的一個。
message——若是違反了一個規則，這個字符串的內容會被顯示出來。
resource——你但願這個規則被應用到的資源種類。
assertions——將對指定資源進行評估的條件列表。

在上面的規則中，every assertion檢查每一個容器中的Deployment（key:spec.templates.spec.contains）是否使用受信任的鏡像（即以 "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/"

若是你想要測試檢查，你能夠將規則集保存爲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"
  }
]

它失敗了。如今，讓咱們考慮如下manifest和有效的鏡像倉庫：

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

使用以上manifest運行相同的檢查而且將不會報告違規：

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

Config-lint是一個頗有前途的框架，它可讓你使用YAML DSL爲Kubernetes YAML manifest編寫自定義檢查。但若是你想表達更復雜的邏輯和檢查呢？是否是YAML的限制性太大？若是你能用真正的編程語言來表達這些檢查呢？

Copper

主頁：https://github.com/cloud66-os...

Copper V2是一個使用自定義檢查來驗證清單的框架——就像config-lint同樣。然而，Copper並無使用YAML來定義檢查。取而代之的是，測試是用JavaScript編寫的，Copper提供了一個庫，裏面有一些基本的幫助程序來協助讀取Kubernetes對象和報告錯誤。

你能夠按照官方文檔來安裝Copper。在寫這篇文章的時候，最新的版本是2.0.1：

https://github.com/cloud66-os...

與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 manifest運行這項檢查，可使用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 manifest的域名，或者拒絕任何做爲特權運行的Pod。Copper有一些內置的助手:

DockerImage函數讀取指定的輸入文件並建立一個包含如下屬性的對象：

name-包含鏡像名稱
tag-包含鏡像tag
registry-鏡像倉庫
registry_url-包含協議和鏡像倉庫
fqin表明整個徹底合格的鏡像位置。

findByName函數能夠幫助從輸入文件中找到給定kind和name的資源。

findByLabels函數能夠幫助查找資源提供的kind和labels。

你能夠在這裏看到全部可用的幫助程序：

https://github.com/cloud66-os...

默認狀況下，它將整個輸入的YAML文件加載到$$變量中，並使其在你的腳本中可用（若是你過去使用jQuery，你可能會發現這個模式很熟悉）。

除了不用學習自定義語言外，你還可使用整個JavaScript語言來編寫你的檢查，如字符串插值、函數等。值得注意的是，目前的copper版本嵌入了ES5版本的JavaScript引擎，而不是ES6。想要了解更多，能夠訪問項目官網：

https://github.com/cloud66-os...

若是Javascript不是你的首選語言，或者你更喜歡用於查詢和描述策略的語言，你應該看看conftest。

Conftest

Conftest是一個配置數據的測試框架，可用於檢查和驗證Kubernetes manifest。測試使用專門構建的查詢語言Rego編寫。

你能夠按照項目網站上的說明安裝conftest，在撰寫本文時，最新的版本是0.18.2：

https://www.conftest.dev/inst...

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

如今讓咱們運行conftest來驗證manifest base-valid.yaml：

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塊，當爲true時就會評估爲違規。當你有多個deny塊時，conftest會獨立檢查它們，整體結果是任何一個塊的違規都會致使總體違規。

除了默認的輸出格式外，conftest還支持JSON、TAP和經過--output標誌的表格格式，若是你但願將報告與現有的持續集成流水線集成，那麼這些格式將會頗有幫助。爲了幫助調試策略，conftest有一個方便的--trace標誌，它能夠打印conftest如何解析指定策略文件的跟蹤。

Conftest策略能夠做爲artefacts在OCI（Open Container Initiative）倉庫中發佈和共享。命令push和pull容許發佈一個工件和從遠程倉庫中提取一個現有的artefact。

讓咱們看看使用conftest push將上述策略發佈到本地docker倉庫的演示。使用如下命令啓動本地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命令，將上述bundle下載到臨時目錄中：

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

你會看到，在包含以前push的策略文件的臨時目錄中，有一個新的子目錄策略：

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）或運行你的容器倉庫，可能會經過測試。

artefact格式與開放策略代理 (OPA) 綁定使用的格式相同，這使得使用 conftest 從現有的 OPA 綁定中運行測試成爲可能。

你能夠在官方網站上了解更多關於共享策略和conftest的其餘功能：

https://www.conftest.dev/

Polaris

主頁：https://github.com/FairwindsO...

本文將探討的最後一個工具是polaris。Polaris既能夠安裝在集羣內部，也能夠做爲命令行工具靜態地分析Kubernetes manifest。看成爲命令行工具運行時，它包括幾個內置的檢查，涵蓋安全和最佳實踐等領域，相似於kube-score。此外，你還能夠用它來編寫相似config-lint、copper和conftest的自定義檢查。換句話說，polaris結合了兩個類別中最好的：內置和自定義檢查器。

你能夠按照項目網站上的說明安裝polaris命令行工具。在寫這篇文章的時候，最新的版本是1.0.3：

https://github.com/FairwindsO...

安裝完成後，你可使用如下命令針對base-valid.yaml manifest運行polaris:

polaris audit --audit-path base-valid.yam

上述命令將打印一個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": [
    /* long list */
  ]
}

你能夠在下方連接中獲取完整的輸出：

https://github.com/amitsaha/k...

與kube-score相似，polaris也發現了一些manifest未達到建議的最佳實踐的狀況，其中包括：

缺乏健康檢查的pod。
容器鏡像沒有指定標籤。
容器以root身份運行。
沒有設置CPU和內存請求和限制。
每項檢查都被劃分爲警告或危險的嚴重程度。

要了解有關當前內置檢查的更多信息，請參閱文檔：

https://github.com/FairwindsO...

若是你對詳細的結果不感興趣，傳遞標誌--format score會打印一個範圍爲1-100的數字，polaris將其稱爲分數（score）：

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

分數越接近100，符合度越高。若是你檢查polaris audit命令的退出代碼，你會發現它是0。要使polaris審計退出時的代碼是非0，能夠利用另外兩個標誌。

--set-exit-code-below-score標誌接受範圍爲1-100的閾值分數，當分數低於閾值時，將以4的退出代碼退出。當你的基線分數是75分，而你想在分數低於75分時發出警報時，這很是有用。

當任何危險檢查失敗時，--set-exit-code-on-danger標誌將以3的退出代碼退出。

如今讓咱們看看如何爲polaris定義一個自定義檢查，以測試Deployment中的容器鏡像是否來自可信任的鏡像倉庫。自定義檢查以YAML格式定義，測試自己使用JSON Schema描述。下面的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指的是其中一個類別—鏡像、健康檢查、安全、網絡和資源。
target是一個字符串，用於肯定檢查所針對的規範對象，應該是Container、Pod或Controller中的一個。
測試自己是在schema對象中使用JSON模式定義的。這裏的檢查使用模式關鍵字來匹配鏡像是否來自容許的倉庫。

要運行上面定義的檢查，你須要建立一個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/.+$

讓咱們來分析一下這個文件。

check字段指定了檢查和它們的嚴重性。因爲你想在鏡像不受信任時發出警報，因此checkImageRepo被分配了一個danger嚴重程度。
而後在customChecks對象中定義checkImageRepo檢查自己。

你能夠將上面的文件保存爲custom_check.yaml，而後用你想要驗證的YAML manifest運行polaris audit。

你能夠用base-valid.yaml manifest進行測試：

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

你會發現，polaris audit只運行了上面定義的自定義檢查，但沒有成功。若是你將容器鏡像修改成my-company.com/http-echo:1.0，polaris將報告成功。Github倉庫中包含了修改後的manifest，因此你能夠根據image-valid-mycompany.yaml manifest測試前面的命令。

可是如何同時運行內置和自定義檢查呢？上面的配置文件應該更新全部內置的檢查標識符，看起來應該以下：

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/.+$

你能夠在這裏看到一個完整的配置文件的例子：

https://github.com/amitsaha/k...

你能夠用自定義和內置檢查來測試base-valid.yaml manifest：

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

Polaris用你的自定義檢查加強了內置檢查，從而結合了兩種方式的最佳狀態。然而，若是不能使用更強大的語言，如Rego或JavaScript，可能會限制編寫更復雜的檢查。

要了解更多關於polaris的信息，請查看項目網站：

https://github.com/FairwindsO...

總結

雖然有不少工具能夠驗證、打分和精簡Kubernetes YAML文件，但重要的是要有一個心理模型來了解你將如何設計和執行檢查。舉個例子，若是你想讓Kubernetes manifest經過一個流水線，kubeval能夠是這樣一個流水線的第一步，由於它驗證對象定義是否符合Kubernetes API模式。一旦這項檢查成功，也許你能夠繼續進行更詳細的測試，好比標準最佳實踐和自定義策略。Kube-score和polaris在這裏是最優秀的選擇。

若是你有複雜的需求，而且想要自定義檢查的細節，你應該考慮copper、config-lint和conftest。雖然conftest和config-lint都使用了更多的YAML來定義自定義驗證規則，但copper給你提供了一個真正的編程語言，使其至關有吸引力。可是，你應該使用其中的一個，從頭開始寫全部的檢查，仍是應該使用Polaris，只寫額外的自定義檢查？這要根據狀況而定。