持續驗證總覽

二進位授權的持續驗證 (CV) 功能可搭配檢查式平台政策，監控在 Google Kubernetes Engine (GKE) 上執行的 Pod，確保相關聯的容器映像檔持續符合您指定的二進位授權檢查式平台政策。

如果 CV 判斷 Pod 違反平台政策，就會將違規事項記錄到 Cloud Logging。

CV 搭配平台政策會取代舊版持續驗證 (已淘汰)。

為什麼要使用 CV？

雖然二進位授權強制執行功能會在您部署容器映像檔時，提供一次性的映像檔驗證，但 CV 會持續監控與執行中 Pod 相關聯的映像檔是否持續符合政策規定。

因此，同時啟用二進位授權強制執行和 CV (搭配以檢查為準的政策) 時，可確保在整個協調生命週期中驗證政策一致性。

CV 適用於下列情境：

  • 政策異動：更新二進位授權專案單例強制執行政策後，二進位授權只會驗證更新後部署的映像檔。已執行的 Pod 不受影響。即使二進位授權使用更新後的政策，會禁止部署相同映像檔，這些映像檔仍會繼續執行。

    因此，更新 Binary Authorization 專案單例政策時，建議您也建立或更新 CV 平台政策，與專案單例政策相符。這樣一來，CV 就會通知您有執行中的 Pod 違反更新後的政策。

  • 監控圖片中繼資料：CV 會針對圖片中繼資料的變更進行特定檢查，包括：

    • 認證：當 Pod 圖片上的認證失效時，CV 記錄會顯示。
    • 新鮮度：CV 會在偵測到 Pod 的圖片不再新鮮時記錄。
    • 出處：CV 可以檢查 Pod 的映像檔是否使用可信任的建構工具建構，以及建構設定是否位於可信任的來源存放區。
    • Sigstore 簽章：當 Pod 映像檔缺少有效的 Sigstore 簽章時，CV 記錄會顯示。
    • 信任的目錄：當 Pod 的映像檔位於平台政策未列出的存放區目錄時，CV 記錄檔會顯示這項違規情形。
    • 安全漏洞：在 Pod 的映像檔中發現安全漏洞時，CV 會記錄相關資訊。

  • 模擬測試監控：啟用模擬測試後，二進位授權會允許部署所有映像檔。啟用 CV 時，如果平台政策與專案單例政策相符，CV 就會定期記錄違反平台政策的圖片。

  • 緊急情況監控：使用 breakglass 部署 Pod 時，二進位授權會略過專案單例政策強制執行作業，並將單一事件記錄到 Cloud 稽核記錄。不過，如果使用相符的平台政策，CV 仍會定期記錄違反政策的 Pod，包括使用緊急情況例外程序部署的 Pod。

CV 的運作方式

如要使用 CV，您必須在 GKE 叢集上啟用這項功能。

在叢集上部署映像檔後，CV 會監控相關聯的 Pod，確保這些 Pod 符合以檢查為基礎的平台政策。

CV 不支援圖片代碼，但豁免圖片中指定的圖片除外。

CV 會定期檢查正在執行的 Pod

如要監控執行中的 Pod，請至少每 24 小時檢查一次與每個 Pod 相關聯的 CV 審查圖片。CV 也會監控 init 容器和暫時性容器。

在每次審查期間，CV 會擷取與每個 Pod 相關聯的圖片清單。CV 接著會驗證圖片資訊是否符合平台政策。

CV 記錄檔違反平台政策

如果 CV 判定圖片違反平台政策，系統會將違規事項和其他發現記錄到 Cloud Logging。如果每個 Pod 違反平台政策，系統會為每個 Pod 寫入個別的記錄項目。

當 CV 使用平台政策評估 Pod 的圖片時，圖片可能通過部分檢查，但違反其他檢查。只要 Pod 的任何圖片違反任何檢查，CV 就會產生記錄項目。記錄檔項目只會列出違反平台政策的 Pod 映像檔。如果所有圖片都通過所有檢查，系統就不會產生記錄項目。

在含有不符政策圖片的 Pod 終止前，CV 會持續記錄政策違規事項。如果系統在驗證間隔期間終止不符合政策的 Pod，最終 CV 產生的記錄檔項目可能會在終止後，於下一次 CV 評估期間顯示。

即使是生命週期較短的 Pod，也應至少記錄一次不符合政策的 Pod。

CV 不會終止執行中的 Pod。

CV 使用動態饋給資源

如要擷取 GKE 叢集上執行的 Pod 相關資訊，CV 會建立名為 binauthz-cv-cai-feed 的動態饋給資源。

CV 平台政策

如要使用 CV，請先設定平台政策。

平台政策與舊版二進位授權政策 (也稱為專案單例政策) 不同。雖然部署專案只能有一項舊版專案單例政策，但您可以設定多項平台政策。每項平台政策可位於一或多個專案中。

平台政策僅適用於 CV，不支援二進位授權強制執行。因此，我們建議您建立專案單例政策來強制執行，並建立平台政策來監控，以便同時使用 Binary Authorization 強制執行和 CV 監控。

舉例來說，假設您想設定二進位授權，強制規定映像檔必須具備認證才能部署，同時確保執行中的 Pod 也符合相同規定。如要執行這項操作，請使用驗證者設定專案單例強制執行政策。接著，您會建立平台政策，並進行簡單的簽署認證檢查，其中包含的驗證器與驗證者採用相同的附註和公開金鑰。

平台政策適用於特定平台。系統僅支援 GKE。

您可以在平台政策中設定檢查。檢查會分組為一或多個檢查集。每個檢查集可指定一或多項檢查。

平台政策可豁免圖片，讓電腦視覺模型不必評估這些圖片。

所需權限

如要列出或說明平台政策，您必須具備 binaryauthorization.policyViewer 角色。如要建立、修改及刪除平台政策，您需要 binaryauthorization.policyEditor 角色。詳情請參閱「管理平台政策」。

政策更新

更新平台政策會使用 YAML 檔案中提供的政策描述元，覆寫現有政策。如要將新檢查項目新增至現有平台政策，建議您說明現有政策，將其儲存至 YAML 檔案，新增檢查項目，然後使用更新後的檔案更新政策。

多項平台政策

您可以在與叢集相同的專案中建立平台政策 (本機平台政策)，也可以在任何其他專案中建立。

由於您可以設定多項平台政策，因此請為每項政策指定不重複的資源名稱。執行 gcloud CLI 指令時，您會使用 ID 參照本機平台政策。在其他專案中參照平台政策時，請使用資源名稱，格式如下：projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID

您可以選擇要將哪個平台政策與每個 GKE 叢集建立關聯，無論是本機平台政策還是其他專案中的政策都可以。

每個平台政策的多項檢查

您可以在政策的 checks 區塊中新增多項檢查，為每個平台政策設定多項檢查。如要進一步瞭解可設定的特定檢查，請參閱「檢查」。

如果 CV 平台政策指定多項檢查，系統會繼續使用其他檢查評估圖片。

除非映像檔符合豁免映像檔許可清單模式，否則二進位授權會評估每個映像檔的平台政策中設定的所有檢查。詳情請參閱「豁免圖片」。

單一專案設定

您可以在單一專案中設定 CV。

在單一專案設定中，二進位授權會自動在二進位授權服務代理中設定必要角色。

如果 GKE 叢集、繫結至叢集的平台政策，以及檢查所需的中繼資料都位於同一個專案中，則不需要額外的 Identity and Access Management (IAM) 角色。

如要進一步瞭解如何設定多專案，以提升安全性，請參閱「關注事項分離」。

多專案設定

使用平台政策設定多專案 CV 時，平台政策、映像檔、GKE 叢集和其他 CV 相關資源可分別位於不同專案。

在多專案設定中，請務必瞭解每個專案的用途，以及 CV 需要存取的資源，並據此設定必要的 IAM 角色和權限。

如何使用 CV

如要使用 CV，通常需要執行下列操作：

  1. 決定要使用的檢查項目。
  2. 使用政策 YAML 檔案撰寫一或多項平台政策。這個檔案會指定要使用的檢查。
  3. 建立平台政策。 政策可以儲存在您選擇的專案中。
  4. 選擇要在個別叢集或機群上啟用 CV。
  5. 在 Logging 中查看 CV 記錄，瞭解相關事件。
  6. 查看記錄並更新建構和其他程序，以產生符合檢查條件的圖片。

支票

本節說明 CV 提供的具體檢查。

以檢查為準的政策採用下列標準格式：

gkePolicy:
  checkSets:
  - checks:
    - CHECK_TYPE1:
        CHECK_TYPE1_PARAMETERS
      displayName: CHECK_TYPE1_DISPLAY_NAME
    - CHECK_TYPE2:
        CHECK_TYPE2_PARAMETERS
      displayName: CHECK_TYPE2_DISPLAY_NAME
    displayName: CHECK_SET_DISPLAY_NAME

checks 和 checkSets 中的 displayName 欄位為選填欄位。只有在 CV 記錄違反政策的情形時，才會使用這項設定。本指南稍後的某些範例會省略這項屬性。

一律拒絕檢查

一律拒絕檢查可確保所有接受這項檢查的圖片都無法通過評估。每次 CV 透過這項檢查審查執行中的 Pod 時，都會為每個 Pod 產生記錄項目。

您可以將一律拒絕檢查與允許清單或多個檢查集結合，確保 Binary Authorization 一律會在特定情況下產生 Pod 的記錄。

如要使用一律拒絕檢查，請在 checks 區塊中新增 alwaysDeny: true，如下所示：

gkePolicy:
  checkSets:
    - displayName: "My check set"
      checks:
        - alwaysDeny: true

alwaysDeny 的值無法設為 false。請改為移除勾選記號。

如需如何使用一律拒絕檢查的範例，請參閱「使用多個檢查集」。

檢查圖片更新頻率

圖片新鮮度檢查會計算圖片的執行時間，並在時間超過門檻時記錄 maxUploadAgeDays。

在下列平台政策 YAML 範例中，CV 記錄檔 Pod 的映像檔上傳至存放區的時間超過 30 天，且這些映像檔是從該存放區部署。

gkePolicy:
  checkSets:
    checks:
    - imageFreshnessCheck:
        maxUploadAgeDays: 30
      displayName: "My image freshness check"
    displayName: "My check set"

簡單的簽署認證檢查

您可以使用 CV 簡單簽署認證檢查，確認 Pod 的每個映像檔都有有效的簽署認證。

這項檢查等同於二進位授權強制執行政策中的認證評估。您可以使用驗證者中使用的相同附註和金鑰，設定這項檢查。建議您使用這項檢查，而非舊版持續驗證 (已淘汰)。

以下是平台政策的範例，其中包含簡單的簽署認證檢查：

gkePolicy:
  checkSets:
    checks:
      simpleSigningAttestationCheck:
        containerAnalysisAttestationProjects:
        - "projects/my-attestation-project1"
        - "projects/my-attestation-project2"
        attestationAuthenticators:
          pkixPublicKeySet:
            pkixPublicKeys:
              publicKeyPem: |
                -----BEGIN PUBLIC KEY-----
                MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
                -----END PUBLIC KEY-----
              signatureAlgorithm: ECDSA_P256_SHA256

CV 認證檢查會使用「驗證者」，而不是「二進位授權驗證者」。您可以在 attestationAuthenticators 區塊中，直接在政策中指定驗證器。

在平台政策中，simpleSigningAttestationCheck可以有多個 attestationAuthenticators，且每個 pkixPublicKeySet 中可以有多個鍵。當每個 Pod 的映像檔都有以任何驗證器 任何金鑰簽署的有效認證時，即滿足檢查條件。pkixPublicKeySet

CV 平台政策與專案單例強制執行政策的差異如下：

  • 系統不支援 PGP 金鑰。
  • 不需要驗證者。您必須手動建立金鑰，然後說明平台政策，以擷取金鑰 ID，再使用該 ID 建立認證。
  • 您需要手動建立及簽署酬載、建立認證 JSON 檔案，並使用 Artifact Analysis API 建立認證。
  • 您仍可建立構件分析附註，但不必在政策中指定附註。CV 會改為在 containerAnalysisAttestationProjects 欄位列出的每個專案中尋找認證。
  • 認證仍會儲存在 Artifact Analysis 發生項目中，但可儲存在多個專案中。
  • 您必須使用資源名稱 projects/ATTESTATION_PROJECT_ID，明確指定一或多個含有認證的專案。

CV 不支援圖片代碼，但豁免圖片中指定的代碼除外。

如果部署映像檔時使用映像檔標記而非摘要，CV 會先根據豁免映像檔進行評估，因為允許清單可以包含標記。如果映像檔未獲豁免，CV 會嘗試尋找映像檔摘要。由於沒有這類圖片，因此圖片違反檢查規定。

SLSA 檢查

SLSA 檢查會檢查 Pod 映像檔的 SLSA 指定出處。

以下是 CV 平台政策 YAML 設定的範例：

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
        allowPattern: "gcr.io/my-images/not-built-by-GCB/**"
    - slsaCheck:
        rules:
          trustedBuilder: GOOGLE_CLOUD_BUILD
          attestationSource:
          - containerAnalysisAttestationProjects: "projects/attestation-project1"
          - containerAnalysisAttestationProjects: "projects/attestation-project2"
          # Require that images were built using a checked-in top-level config file.
          configBasedBuildRequired: true
          # Which repos the config file can be from.
          trustedSourceRepoPatterns:
          - "source.cloud.google.com/my-project/my-source-repo"
          - "github.com/my-github-user/*"
      displayName: "My SLSA check"
    displayName: "My check set"

電腦視覺技術依據這項平台政策審查圖片時，會檢查下列項目：

  • 映像檔必須由受信任的建構工具建構。 SLSA 檢查只支援 Cloud Build 這個受信任的建構工具。

  • Cloud Build 必須在 attestation-project1 或 attestation-project2 中產生認證。

  • 映像檔必須使用下列任一受信任存放區的頂層設定檔建構：

    • 存放區 source.cloud.google.com/my-project/my-source-repo/
    • github.com/my-github-user/ 中的任何存放區

  • gcr.io/my-images/not-built-by-GCB/ 或其子目錄中的圖片 (並非由 Cloud Build 建構) 不會受到檢查，因為這些圖片會違反檢查規定。

Sigstore 簽章檢查

Sigstore 簽章檢查會驗證映像檔是否已使用 Sigstore 簽章簽署。

這項檢查僅支援 Artifact Registry 中託管的映像檔。系統會檢查政策中的任何金鑰，是否能成功驗證從 Artifact Registry 擷取的任何簽章。

下列平台政策範例說明如何設定 Sigstore 簽章檢查：

  gkePolicy:
    checkSets:
    - checks:
      - displayName: sigstore-signature-check
        sigstoreSignatureCheck:
          sigstoreAuthorities:
          - displayName: sigstore-authority
            publicKeySet:
              publicKeys:
                publicKeyPem: |
                  -----BEGIN PUBLIC KEY-----
                  MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
                  -----END PUBLIC KEY-----

在平台政策中，sigstoreSignatureCheck可以有多個 sigstoreAuthorities，且每個 publicKeySet 中可以有多個鍵。sigstoreSignatureChecksigstoreAuthoritiespublicKeySet當每個 Pod 的映像檔都有以任何驗證器 publicKeySet 中的任何金鑰簽署的有效認證時，即符合檢查條件。

檢查信任的目錄

可信目錄檢查會確認 Pod 的映像檔是否位於您在平台政策中指定的可信目錄。

使用這項檢查時，建議您也保護政策中列為信任目錄的存放區，避免未經授權的存取活動。

以下平台政策範例說明如何設定信任目錄檢查：

gkePolicy:
  checkSets:
    checks:
      trustedDirectoryCheck:
        trustedDirPatterns:
        - "gcr.io/my-project/gcr-directory"
        - "us-central1-docker.pkg.dev/my-project/ar-directory"
        displayName: "My trusted directory check"
    displayName: "My check set"

在範例平台政策中，trustedDirPatterns 列出受信任的目錄。如果所有 Pod 的圖片都位於所列目錄中，即符合政策規定。如果 Pod 的圖片不在列出的目錄中，就會違反政策，CV 會記錄違規事項。

安全漏洞檢查

安全漏洞檢查會使用 Artifact Analysis 安全漏洞掃描功能，檢查 Pod 的映像檔是否含有安全漏洞。包括 Pod 部署後，安全漏洞掃描功能發現的新安全漏洞。在安全漏洞檢查中，您可以設定安全漏洞嚴重程度門檻和特定安全漏洞 (以 CVE 形式)。如果映像檔的安全漏洞違反安全漏洞檢查，系統會將相關記錄寫入 Logging。

如要使用這項檢查，請先在構件分析中啟用安全漏洞掃描。

下列平台政策設定範例包含安全漏洞檢查：

gkePolicy:
  checkSets:
    - displayName: "Default check set"
      checks:
        - vulnerabilityCheck:
           maximumFixableSeverity: MEDIUM
           maximumUnfixableSeverity: HIGH
           allowedCves:
             - "CVE-2022-11111"
             - "CVE-2022-22222"
           blockedCves:
             - "CVE-2022-33333"
             - "CVE-2022-44444"
           containerAnalysisVulnerabilityProjects: "projects/my-project"

在範例中，maximumUnfixableSeverity 和 maximumFixableSeverity 定義了與 Artifact Analysis 可識別的任何安全漏洞相關聯的「一般安全漏洞評分系統」(CVSS) 嚴重性等級。此外，blockedCves 也會列出特定的常見安全漏洞與揭露 (CVE)。如果發現的安全漏洞超過指定嚴重程度等級，或與 blockedCves 中列出的 CVE 之一相符，且不符合 allowedCves 中列出的任何 CVE，則 CV 會在 Logging 中記錄項目。

驗證更新後的政策

更新 CV 平台政策後，強烈建議您驗證二進位授權和 CV 是否繼續正常運作。

驗證設定

如要檢查設定，請同時檢查二進位授權專案單例政策和 CV 平台政策。

驗證作業

如要驗證 Binary Authorization 和 CV 是否正常運作，您可以部署測試 Pod，然後檢查 Logging 中的 Binary Authorization 項目。

使用許可清單豁免圖片

建立平台政策時，您可以將圖片網址加入許可清單，豁免檢查。政策層級的允許清單會將圖片從整項政策中排除。檢查集層級的允許清單會排除檢查集，且只會在評估該檢查集時套用。檢查中的許可清單只會讓圖片免於該項檢查。

許可清單模式是指符合一或多個圖片網址的模式。許可清單模式可以是下列其中一種：

  • 圖片名稱前置字元，結尾為萬用字元 * 或 **。
  • 只有映像檔名稱，沒有標記或摘要。
  • 含標記的圖片名稱 (或含萬用字元 * 的標記前置字串)。
  • 含有摘要的圖片名稱。
  • 同時包含標記和摘要的圖片名稱。

以下是允許清單模式的範例：

  • us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c 與確切的映像檔名稱、標記和摘要相符。
  • us-central1.pkg.dev/my-project/my-image:latest 符合名稱和標記，且含有任何摘要 (或沒有摘要)。
  • us-central1.pkg.dev/my-image:foo* 符合名稱和標記前置字串 (例如 myimage:foo 和 myimage:foobar)，以及任何摘要 (或沒有摘要)。
  • us-central1.pkg.dev/my-project/my-image@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c 與名稱和摘要相符，且可有任何標記 (或沒有標記)。
  • us-central1.pkg.dev/my-project/my-image 用於比對名稱，以及任何標記和/或摘要。

萬用字元 * 和 ** 可用於比對具有特定前置字元的任何名稱。* 會比對不含 / 的後置字元。** 會比對後置字元，包括 /，但 ** 只能在 / 後使用。請注意，* 和 ** 無法與標記或摘要搭配使用。

例如：

  • us-central1.pkg.dev/my-project/my-image* 會比對 us-central1.pkg.dev/myproject/my-image、us-central1.pkg.dev/myproject/my-image1 和 us-central1.pkg.dev/myproject/my-image2，以及任何標記和/或摘要。
  • us-central1.pkg.dev/my-project/** 與 us-central1.pkg.dev/myproject/my-image 和 us-central1.pkg.dev/my-project/some-directory/other-image 相符，且包含任何標記和/或摘要。

請注意，名稱前置字串和代碼前置字串不得留空。因此，單獨使用 * 或 ** 並非有效模式，us-central1.pkg.dev/my-image:* 也是如此。

gkePolicy 層級的豁免

以下範例說明如何豁免平台政策層級的圖片。exempt-images1 和 exempt-images2 目錄及其子目錄中的所有圖片都會排除在 CV 監控範圍外。

gkePolicy:
  imageAllowlist:
  - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
  - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
  checkSets:
      checks:
        ...

根據這項政策，imageAllowlist 下列出的圖片可免除 gkePolicy 下列出的所有檢查集 (checkSets)。

checkSet-level exemption

以下範例說明如何在檢查集層級豁免圖片：

gkePolicy:
  checkSets:
    imageAllowlist:
    - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
    - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
    checks:
      ...

政策中，imageAllowlist 下列出的圖片可免除 checkSets 下列出的所有檢查。

支票層級豁免

以下範例說明如何在檢查層級豁免圖片：

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
      - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
      - allowPattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
      ...

使用多個檢查集

以 CV 檢查為依據的政策可以包含多個檢查集。 CV 每次評估政策時，都會評估一組檢查項目。您可以將檢查集視為應在不同情況下評估的子政策。舉例來說，如果您想在開發環境中套用與實際工作環境不同的檢查，可以將各環境的檢查放在不同的檢查集中，一個只在開發環境中評估，另一個則在實際工作環境中評估。

每個檢查集都會限定在 Kubernetes 命名空間或 Kubernetes 服務帳戶中。範圍會決定檢查集適用的 Pod。

如果檢查集設定了範圍，就只會套用至該範圍內執行的 Pod。

如果檢查集沒有範圍，則稱為「預設檢查集」，這表示檢查會套用至所有 Pod，無論其 Kubernetes 命名空間或服務帳戶範圍為何。

CV 指南中的大部分範例政策只會使用預設檢查集。

下列範例政策設定會設定三組檢查：

gkePolicy:
  checkSets:
    - displayName: "Prod check set"
      scope:
        kubernetesNamespace: "prod-namespace"
      checks:
        - trustedDirectoryCheck:
            trustedDirPatterns: "gcr.io/my-project/prod-images"
        - imageFreshnessCheck:
            maxUploadAgeDays: 30
    - displayName: "Dev check set"
      scope:
        kubernetesNamespace: "dev-namespace"
      checks:
        - trustedDirectoryCheck:
            trustedDirPatterns: "gcr.io/my-project/dev-images"
    - displayName: "Default check set"
      checks:
        - alwaysDeny: true

在範例設定中，第一個檢查集的作用範圍是 prod-namespace，因此檢查只會影響在該範圍內執行的 Pod。第二個檢查集的作用範圍為 dev-namespace，因此檢查只會影響該範圍內執行的 Pod。第三個檢查集是預設檢查集。這項檢查適用於叢集中所有在 prod-namespace 和 dev-namespace 範圍外執行的 Pod。

當 CV 評估名為 Prod check set 的檢查集時，會檢查在 prod-namespace Kubernetes 命名空間中執行的 Pod 映像檔是否符合下列條件：

  • 圖片會儲存在受信任的 prod-images 目錄中。
  • 圖片是在過去 30 天內上傳。

當 CV 評估名為 Dev check set 的檢查集時，會評估 dev-namespace Kubernetes 命名空間中執行的 Pod，檢查 Pod 中的映像檔是否來自 dev-images 目錄。

預設檢查集會做為全方位檢查。一律拒絕檢查可確保 CV 記錄在任何其他命名空間中執行的所有 Pod。

如要使用 Kubernetes 服務帳戶做為檢查集範圍，請將範例中的 kubernetesNamespace 鍵替換為 kubernetesServiceAccount。該值的格式為 my-namespace:my-service-account。

確認設定的範圍符合下列規則：

  • 平台政策的每個範圍只能有一個檢查集。

  • 如果政策同時包含命名空間範圍和服務帳戶範圍的檢查集，則必須先列出服務帳戶範圍的檢查集，再列出命名空間範圍的檢查集。

  • 只能有一個預設檢查集，且必須列在最後。

如果平台政策包含任何檢查集，則必須至少包含預設檢查集。允許使用沒有檢查集的平台政策，但由於沒有違反的檢查，CV 不會產生任何記錄項目。

舊版履歷

本節說明舊版 CV 政策。如果您不熟悉 CV，建議改用以檢查為準的政策 CV。

為支援舊版 CV 使用者，您可以在執行 GKE 的專案上啟用 CV。接著，CV 會使用二進位授權強制執行政策，檢查專案中所有叢集上執行的所有 Pod，包括未啟用二進位授權強制執行的叢集。

瞭解如何使用舊版 CV (已淘汰)，以及在 Cloud Logging 中查看舊版 CV 事件。

後續步驟