容器安全性在雲端原生環境中至關重要，有助於保護工作負載。 為了增強容器映像整個生命週期的安全性，Microsoft 引進了 容器安全供應鏈 （CSSC） 架構。 在架構的 [部署] 階段中，容器映像會部署至生產環境，例如 Azure Kubernetes Service （AKS） 叢集。
確保安全的生產環境涉及維護容器映像的完整性和真實性。 在建置階段簽署容器映像檔，然後在部署階段驗證它們，有助於確保只部署受信任且未變更的映像檔。
Ratify 是 Microsoft 支援的 雲端原生運算基金會 （CNCF） 沙箱專案。 它是一個強大的驗證引擎，可驗證容器映像的安全元資料，例如簽章。 它只允許部署符合您指定原則的映像。
Scenarios
本文涵蓋在 AKS 上使用 Ratify 實作容器映像簽章驗證的兩個主要案例。 這些案例會根據您管理憑證以進行簽署和驗證的方式而有所不同：使用 Azure 金鑰保存庫進行傳統憑證管理，或使用 Microsoft 信任簽署服務進行零接觸憑證生命週期管理。 選擇符合您目前憑證管理方法和安全需求的案例。
使用 Key Vault 進行憑證管理
映像生產者會在持續整合和持續傳遞 （CI/CD） 管線內建置容器映像並將其推送至 Azure Container Registry。 這些映像適用於映像取用者在 AKS 叢集上部署和執行雲端原生工作負載。
映像產生者會使用 Notary Project (英文) 工具 (特別是 Notation) 在 CI/CD 管線中對 Azure Container Registry 中的容器映像進行簽署。 用於簽署的金鑰和憑證會安全地儲存在金鑰保存庫中。
Notary Project 簽章會在 Azure Container Registry 中建立並儲存，並且這些簽章會參考對應的映像。 映像取用者會在 AKS 叢集上設定 Ratify 和原則，以在部署期間驗證映像的 Notary Project 簽章。 如果原則效果設定為 Deny，則未通過簽章驗證的映像將被拒絕部署。 此設定有助於確保只有受信任且未變更的映像才會部署至 AKS 叢集。
身為映像生產者，您可以遵循下列文章，使用 Key Vault 簽署 Container Registry 中的容器映像：
- 如需透過自簽憑證進行簽署，請參閱 使用 Notation 工具、Azure 金鑰保存庫和自簽憑證簽署容器映像。
- 如需透過由憑證授權機構 (CA) 發行的憑證進行簽署，請參閱 使用 Notation、Azure 金鑰保存庫及 CA 發行的憑證來簽署容器映像檔。
- 如需在 Azure DevOps 管線中登入，請參閱 在 Azure 管線中使用標記法簽署和驗證容器映像。
- 如需在 GitHub 工作流程中簽署，請參閱 使用 GitHub Actions 中的表示法簽署容器映像。
使用信任簽署進行憑證管理
在此案例中，映像生產者會使用信任簽署所管理的憑證，而不是 Key Vault 來簽署容器登錄中的容器映像。 由於信任簽署提供零接觸憑證生命週期管理，因此生產者不再需要處理憑證簽發、輪換或到期。
在取用者端，信任簽署會產生短期憑證。 映像取用者會在驗證期間設定時間戳記，以在憑證到期後維持信任。
此外，會在 AKS 上設定 Ratify 和叢集原則，以在部署時驗證簽章。 如果原則效果設為 Deny，則會封鎖任何未通過驗證的映像檔。 封鎖有助於確保只部署受信任且未變更的映像。
身為映像生產者，您可以遵循下列文章，使用信任簽署來簽署容器映像：
本文會引導您作為映像使用者，在 AKS 叢集上使用 Ratify 和 Azure Policy 來進行容器映像簽章的驗證。
這很重要
如果您偏好使用受控體驗，而不是直接使用開放原始碼 Ratify，您可以改為選擇 AKS 映像完整性原則 （預覽版） ，以協助確保 AKS 叢集上的映像完整性。
簽章驗證概觀
以下是簽名驗證的高階步驟：
設定 Container Registry 的身分識別和存取控制：設定 Ratify 用來存取具有必要角色的 Container Registry 的身分識別。
設定金鑰保存庫的身分識別和存取控制：設定 Ratify 用來使用必要角色存取金鑰保存庫的身分識別。 如果映像是透過信任簽署簽署的，請略過此步驟。
在 AKS 叢集上設定 Ratify：使用 Helm 圖表安裝作為標準 Kubernetes 服務來設定 Ratify。
設定自訂 Azure 原則：建立並指派具有所需原則效果的自訂 Azure 原則：
Deny或Audit。
執行下列步驟之後，您可以開始部署工作負載以觀察結果：
- 使用
Deny策略效果時，只能部署那些已通過簽名驗證的映像。 未簽署或由不受信任的身分簽署的映像會遭到拒絕。 - 使用
Audit原則效果時，可以部署映像，但您的元件會被標示為不符合規範，只能用於稽核目的。
先決條件
- 安裝並設定最新的 Azure CLI 版本，或在 Azure Cloud Shell 中執行命令。
- 安裝 Helm 進行 Ratify 安裝，並安裝 kubectl 進行疑難排解和狀態檢查。
- 遵循在 Azure Kubernetes Service 上建立 OpenID Connect 提供者中的步驟，建立或使用啟用了 OpenID Connect (OIDC) 簽發者的 AKS 群集。 此 AKS 叢集是部署容器映像、安裝 Ratify 以及套用自訂 Azure 原則的位置。
- 請遵循從 Azure Kubernetes Service 向 Azure Container Registry 進行驗證中的步驟，將 Container Registry 連線到 AKS 叢集 （如果尚未連線）。 容器登錄是儲存容器映像以部署至 AKS 叢集的位置。
- 啟用 Azure 原則附加元件。 若要確認已安裝附加元件，或安裝附加元件 （如果尚未安裝），請遵循適用於 AKS 的 Azure 原則附加元件中的步驟。
設定身分識別和存取控制
在 AKS 叢集上安裝 Ratify 之前，您必須建立適當的身分識別和存取控制。 Ratify 需要存取您的容器登錄，才能提取容器映像和簽章。 當您使用 Key Vault 進行憑證管理時，Ratify 也需要存取權來擷取憑證以進行簽章驗證。
身分識別組態涉及：
- 建立使用者指派的受控身分識別，或使用現有的身分識別。
- 設定聯合身分認證以啟用工作負載身分鑑別。
- 授與適當的角色指派以獲得 Azure Container Registry 存取權。
- 設定 Key Vault 存取權限，如果您使用 Key Vault 進行憑證管理。
建立或使用使用者指派的受控識別
如果您還沒有使用者指派的受控識別，請參閱 建立使用者指派的受控識別 以建立受控識別。 Ratify 會使用此身分識別來存取 Azure 資源，例如容器登錄和 （適用時） 金鑰保存庫以進行憑證管理。
為您的身分建立聯合身分憑證
使用下列程式碼設定環境變數。 更新變數 RATIFY_NAMESPACE 的值，以及 RATIFY_SA_NAME 如果您未使用預設值。 請務必在安裝 Ratify Helm 圖表期間使用相同的值。
export AKS_RG=<aks-resource-group-name>
export AKS_NAME=<aks-name>
export AKS_OIDC_ISSUER=$(az aks show -n $AKS_NAME -g $AKS_RG --query "oidcIssuerProfile.issuerUrl" -otsv)
export IDENTITY_RG=<identity-resource-group-name>
export IDENTITY_NAME=<identity-name>
export IDENTITY_CLIENT_ID=$(az identity show --name $IDENTITY_NAME --resource-group $IDENTITY_RG --query 'clientId' -o tsv)
export IDENTITY_OBJECT_ID=$(az identity show --name $IDENTITY_NAME --resource-group $IDENTITY_RG --query 'principalId' -otsv)
export RATIFY_NAMESPACE="gatekeeper-system"
export RATIFY_SA_NAME="ratify-admin"
下列命令會為受控識別建立同盟認證。 此認證允許受控識別使用 OIDC 簽發者所簽發的權杖進行驗證，特別是針對命名空間 RATIFY_SA_NAME 中的 Kubernetes 服務帳戶 RATIFY_NAMESPACE。
az identity federated-credential create \
--name ratify-federated-credential \
--identity-name "$IDENTITY_NAME" \
--resource-group "$IDENTITY_RG" \
--issuer "$AKS_OIDC_ISSUER" \
--subject system:serviceaccount:"$RATIFY_NAMESPACE":"$RATIFY_SA_NAME"
設定對 Container Registry 的存取權
您的身分識別需要 AcrPull 角色，才能提取容器映像的簽章和其他中繼資料。 使用下列程式碼來指派角色：
export ACR_SUB=<acr-subscription-id>
export ACR_RG=<acr-resource-group>
export ACR_NAME=<acr-name>
az role assignment create \
--role acrpull \
--assignee-object-id ${IDENTITY_OBJECT_ID} \
--scope subscriptions/${ACR_SUB}/resourceGroups/${ACR_RG}/providers/Microsoft.ContainerRegistry/registries/${ACR_NAME}
設定金鑰保存庫的存取權
如果您使用信任簽署進行憑證管理，請略過此步驟。
您的身分識別需要 Key Vault Secrets User 角色，才能從金鑰保存庫擷取整個憑證鏈結。 使用下列程式碼來指派角色：
export AKV_SUB=<acr-subscription-id>
export AKV_RG=<acr-resource-group>
export AKV_NAME=<acr-name>
az role assignment create \
--role "Key Vault Secrets User" \
--assignee ${IDENTITY_OBJECT_ID} \
--scope "/subscriptions/${AKV_SUB}/resourceGroups/${AKV_RG}/providers/Microsoft.KeyVault/vaults/${AKV_NAME}"
在已啟用 Azure 原則的 AKS 叢集上設定 Ratify
正確設定身分識別和存取控制後，您現在可以在 AKS 叢集上安裝 Ratify。 Ratify 會與 Azure 原則整合，以強制執行簽章驗證原則。 安裝程序涉及使用 Helm 圖表和特定組態參數來部署 Ratify，這些參數定義了它應該如何驗證容器映像簽章。
以下各節涵蓋 Ratify 設定的兩個關鍵層面：
- 了解憑證管理方法所需的 Helm 圖表參數 （金鑰保存庫或受信任簽署）
- 使用適當的配置安裝 Ratify 以啟用簽名驗證
設定參數會根據您是使用 Key Vault 還是信任簽署進行憑證管理而有所不同。 請務必遵循與您選擇的場景相符的說明。
了解您的 Helm 圖表設定參數
當您安裝 Ratify 的 Helm 圖表時，您需要使用 --set 旗標或提供自訂值檔案，將值傳遞至參數。 這些值用於配置 Ratify 以進行簽章驗證。 如需參數的完整清單，請參閱 Ratify Helm 圖表文件。
您需要配置：
- 您先前為存取 Container Registry 和 Key Vault 設定的身分識別。
- 儲存在金鑰保存庫中以進行簽章驗證的憑證。
- 用於簽名驗證的公證計畫信任政策，包括
registryScopes、trustStores和trustedIdentities。
下表提供參數的詳細資訊：
| 參數 | Description | 價值觀 |
|---|---|---|
azureWorkloadIdentity.clientId |
Azure 工作負載身分識別的用戶端識別碼 | "$IDENTITY_CLIENT_ID" |
oras.authProviders.azureWorkloadIdentityEnabled |
容器登錄驗證的 Azure 工作負載身分識別 （啟用或停用） | true |
azurekeyvault.enabled |
從 Key 保存庫擷取憑證 （啟用或停用） | true |
azurekeyvault.vaultURI |
金鑰保存庫資源的 URI | "https://$AKV_NAME.vault.azure.net" |
azurekeyvault.tenantId |
金鑰保存庫資源的租用戶識別碼 | "$AKV_TENANT_ID" |
azurekeyvault.certificates[0].name |
憑證名稱 | "$CERT_NAME" |
notation.trustPolicies[0].registryScopes[0] |
原則套用的儲存庫 URI | "$REPO_URI" |
notation.trustPolicies[0].trustStores[0] |
信任存儲庫中儲存類型ca或tsa的憑證的位置 |
ca:azurekeyvault |
notation.trustPolicies[0].trustedIdentities[0] |
簽署憑證的主體欄位，前置詞 x509.subject: 指出您信任的內容 |
"x509.subject: $SUBJECT" |
藉由對映像使用時間戳記，您可以確保在憑證到期之前簽署的映像仍可成功驗證。 新增時間戳記授權單位 （TSA） 組態的下列參數：
| 參數 | Description | 價值觀 |
|---|---|---|
notationCerts[0] |
PEM 格式的 TSA 根憑證檔案的檔案路徑 | "$TSA_ROOT_CERT_FILEPATH" |
notation.trustPolicies[0].trustStores[1] |
儲存 TSA 根憑證的另一個信任存放區 | tsa:notationCerts[0] |
如果您有多個憑證用於簽章驗證，請指定額外的參數：
| 參數 | Description | 價值觀 |
|---|---|---|
azurekeyvault.certificates[1].name |
憑證名稱 | "$CERT_NAME_2" |
notation.trustPolicies[0].trustedIdentities[1] |
簽署憑證的另一個主旨欄位，指出您信任的內容 | "x509.subject: $SUBJECT_2" |
安裝具有所需參數和值的 Ratify Helm 圖表
請確定 Ratify Helm 圖表的版本至少是 1.15.0，以安裝 Ratify 1.4.0 版或更新版本。 下列範例使用 Helm chart 版本 1.15.0。
設定其他安裝環境變數：
export CHART_VER="1.15.0"
export REPO_URI="$ACR_NAME.azurecr.io/<namespace>/<repo>"
export SUBJECT="<Subject-of-signing-certificate>"
export AKV_TENANT_ID="$(az account show --query tenantId --output tsv)"
helm repo add ratify https://notaryproject.github.io/ratify
helm repo update
helm install ratify ratify/ratify --atomic --namespace $RATIFY_NAMESPACE --create-namespace --version $CHART_VER --set provider.enableMutation=false --set featureFlags.RATIFY_CERT_ROTATION=true \
--set azureWorkloadIdentity.clientId=$IDENTITY_CLIENT_ID \
--set oras.authProviders.azureWorkloadIdentityEnabled=true \
--set azurekeyvault.enabled=true \
--set azurekeyvault.vaultURI="https://$AKV_NAME.vault.azure.net" \
--set azurekeyvault.certificates[0].name="$CERT_NAME" \
--set azurekeyvault.tenantId="$AKV_TENANT_ID" \
--set notation.trustPolicies[0].registryScopes[0]="$REPO_URI" \
--set notation.trustPolicies[0].trustStores[0]="ca:azurekeyvault" \
--set notation.trustPolicies[0].trustedIdentities[0]="x509.subject: $SUBJECT"
如需時間戳記支援，您需要指定其他參數： --set-file notationCerts[0]="$TSA_ROOT_CERT_FILE" 和 --set notation.trustPolicies[0].trustStores[1]="ca:azurekeyvault"。
這很重要
對於未連結至信任原則的影像，簽章驗證會失敗。 例如，如果映像不在存放庫 $REPO_URI內，則這些映像的簽章驗證會失敗。 您可以指定其他參數來新增多個儲存庫。 例如，若要為信任原則 notation.trustPolicies[0]新增另一個儲存庫，請包含參數 --set notation.trustPolicies[0].registryScopes[1]="$REPO_URI_1"。
設定自訂 Azure 原則
在 AKS 叢集上成功安裝和設定 Ratify 後，最後一個步驟是建立並指派 Azure 原則，以在容器部署期間強制執行簽章驗證。 此原則可作為強制機制，指示叢集在允許部署之前使用 Ratify 來驗證容器映像簽章。
Azure 原則提供兩種強制執行模式：
-
Deny：封鎖未通過簽章驗證的映像的部署，以便只有受信任的映像檔在您的叢集中執行。 -
Audit：允許所有部署，但標示符合規範的資源以供監控和報告。
此 Audit 效果在初始設定或測試階段很有用。 您可以使用它來驗證您的組態，而不會在生產環境中冒服務中斷的風險 （由於設定不正確）。
將新的原則指派給您的 AKS 叢集
建立自訂 Azure 原則以進行簽章驗證：
export CUSTOM_POLICY=$(curl -L https://raw.githubusercontent.com/notaryproject/ratify/refs/tags/v1.4.0/library/default/customazurepolicy.json)
export DEFINITION_NAME="ratify-default-custom-policy"
export DEFINITION_ID=$(az policy definition create --name "$DEFINITION_NAME" --rules "$(echo "$CUSTOM_POLICY" | jq .policyRule)" --params "$(echo "$CUSTOM_POLICY" | jq .parameters)" --mode "Microsoft.Kubernetes.Data" --query id -o tsv)
依預設，原則效果會設定為 Deny。 使用此原則效果時，未通過簽章驗證的映像會被拒絕部署。
或者，您可以將原則效果設定為 Audit。 此原則效果允許部署未通過簽章驗證的映像，同時將 AKS 叢集和相關工作負載標示為符合規範。
將原則指派給您的 AKS 叢集，預設效果 Deny為：
export POLICY_SCOPE=$(az aks show -g "$AKS_RG" -n "$AKS_NAME" --query id -o tsv)
az policy assignment create --policy "$DEFINITION_ID" --name "$DEFINITION_NAME" --scope "$POLICY_SCOPE"
若要將原則效果變更為 Audit，您可以將另一個參數傳遞至 az policy assignment create 指令。 例如：
az policy assignment create --policy "$DEFINITION_ID" --name "$DEFINITION_NAME" --scope "$POLICY_SCOPE" -p "{\"effect\": {\"value\":\"Audit\"}}"
備註
完成作業大約需要 15 分鐘。
使用下列命令來檢查自訂原則狀態：
kubectl get constraintTemplate ratifyverification
以下是成功策略指派的輸出範例：
NAME AGE
ratifyverification 11m
若要變更現有的指派，您必須先刪除現有的指派，進行變更，最後建立新的指派。
部署映像檔並檢查政策效果
現在您已成功設定 Ratify 並將 Azure 原則指派給 AKS 叢集，是時候測試簽章驗證功能了。 下列各節示範原則強制執行在實務中的運作方式，方法是部署不同類型的容器映像檔並觀察結果。
您可以測試三個案例來驗證您的設定：
- 具有受信任憑證的已簽署映像：應該會成功部署。
-
未簽署的影像：應封鎖 （具有
Deny效果） 或標示為符合規範 （具有Audit效果）。 -
使用不受信任的憑證簽署的映像：應該封鎖 （具有效果
Deny） 或標示為符合規範 （具有Audit效果）。
您觀察到的行為取決於您在指派 Azure 原則時選擇的原則效果。 此測試程式有助於確保您的簽章驗證正常運作，並讓您確信您的生產環境中只允許受信任的映像。
使用拒絕策略的效果
使用Deny原則效果時，僅允許部署由受信任身份識別簽署的影像。 您可以開始部署工作負載以觀察效果。 本文說明如何使用命令 kubectl 來部署網繭。 同樣地，您可以使用 Helm 圖表或任何觸發 Helm 安裝的範本來部署工作負載。
設定環境變數：
export IMAGE_SIGNED=<signed-image-reference>
export IMAGE_UNSIGNED=<unsigned-image-reference>
export IMAGE_SIGNED_UNTRUSTED=<signed-untrusted-image-reference>
執行下列命令。 由於 $IMAGE_SIGNED 會參考由受信任身分識別簽署並在 Ratify 中設定的映像，因此能用於部署。
kubectl run demo-signed --image=$IMAGE_SIGNED
以下是成功部署的輸出範例：
pod/demo-signed created
變數 $IMAGE_UNSIGNED 會參考未簽署的影像。 變數 $IMAGE_SIGNED_UNTRUSTED 會參考透過您不信任的不同憑證簽署的映像。 因此，這兩個映像都會被拒絕用於部署。 例如，執行下列命令：
kubectl run demo-unsigned --image=$IMAGE_UNSIGNED
以下是被拒絕的部署的輸出範例：
Error from server (Forbidden): admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-ratifyverification-077bac5b63d37da0bc4a] Subject failed verification: $IMAGE_UNSIGNED
您可以使用下列命令來檢視 Ratify 記錄。 然後，您可以使用文字 verification response for subject $IMAGE_UNSIGNED來搜尋記錄。 檢查欄位 errorReason 以瞭解任何拒絕部署的原因。
kubectl logs <ratify-pod> -n $RATIFY_NAMESPACE
使用稽核原則效果
使用 Audit 原則效果時，允許將未簽署的映像或以未受信任的身分識別簽署的映像用於部署。 不過，AKS 叢集和相關元件會標示為 noncompliant。 如需如何檢視不合規資源並瞭解原因的詳細資訊，請參閱 取得 Azure 資源的合規性資料。
清除
使用下列命令解除安裝 Ratify 並清除 Ratify 自訂資源定義 （CRD）：
helm delete ratify --namespace $RATIFY_NAMESPACE
kubectl delete crd stores.config.ratify.deislabs.io verifiers.config.ratify.deislabs.io certificatestores.config.ratify.deislabs.io policies.config.ratify.deislabs.io keymanagementproviders.config.ratify.deislabs.io namespacedkeymanagementproviders.config.ratify.deislabs.io namespacedpolicies.config.ratify.deislabs.io namespacedstores.config.ratify.deislabs.io namespacedverifiers.config.ratify.deislabs.io
使用下列命令刪除原則指派和定義：
az policy assignment delete --name "$DEFINITION_NAME" --scope "$POLICY_SCOPE"
az policy definition delete --name "$DEFINITION_NAME"
FAQ
如果我無法存取 Key Vault，如何設定簽章驗證憑證？
在某些情況下，映像取用者可能無法存取用於簽章驗證的憑證。 若要驗證簽章，您需要下載 PEM 格式的根 CA 憑證檔案，並指定安裝 Ratify Helm 圖表的相關參數。
下列範例命令類似於先前的安裝命令，但沒有任何與金鑰保存庫憑證相關的參數。 公證專案信任存放區是指以參數 notationCerts[0]傳入的憑證檔案。
helm install ratify ratify/ratify --atomic --namespace $RATIFY_NAMESPACE --create-namespace --version $CHART_VER --set provider.enableMutation=false --set featureFlags.RATIFY_CERT_ROTATION=true \
--set azureWorkloadIdentity.clientId=$IDENTITY_CLIENT_ID \
--set oras.authProviders.azureWorkloadIdentityEnabled=true \
--set-file notationCerts[0]="<root-ca-certifice-filepath>"
--set notation.trustPolicies[0].registryScopes[0]="$REPO_URI" \
--set notation.trustPolicies[0].trustStores[0]="ca:notationCerts[0]" \
--set notation.trustPolicies[0].trustedIdentities[0]="x509.subject: $SUBJECT"
notationCerts[0] 用於根 CA 憑證，因此如果您有額外的憑證檔案用於時間戳記，請確保使用正確的索引。 例如，如果 notationCerts[1] 用於 TSA 根憑證檔案，請使用信任存放區 notation.trustPolicies[0].trustStores[1]"，其值為 "tsa:notationCerts[1]"。
如果在我的 AKS 叢集中停用 Azure 原則，我應該採取哪些步驟？
如果 AKS 叢集中已停用 Azure 原則，您必須先安裝 OPA 閘道管理員 作為原則控制器，才能安裝 Ratify。
備註
Azure 原則應保持停用，因為 Gatekeeper 與 AKS 叢集上的 Azure 原則附加元件衝突。 如果您想要稍後啟用 Azure 原則，您必須解除安裝閘道管理員和 Ratify，然後遵循本文來設定已啟用 Azure 原則的 Ratify。
helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm install gatekeeper/gatekeeper \
--name-template=gatekeeper \
--namespace gatekeeper-system --create-namespace \
--set enableExternalData=true \
--set validatingWebhookTimeoutSeconds=5 \
--set mutatingWebhookTimeoutSeconds=2 \
--set externaldataProviderResponseCacheTTL=10s
然後，按照前面步驟中的說明安裝 Ratify。 安裝之後，請使用下列命令強制執行原則。 依預設，原則效果會設定為 Deny。 您可以參閱 Gatekeeper 違規文檔 來更新 constraint.yaml 檔案，以符合不同的策略效果。
kubectl apply -f https://notaryproject.github.io/ratify/library/default/template.yaml
kubectl apply -f https://notaryproject.github.io/ratify/library/default/samples/constraint.yaml
安裝 Ratify 後，如何更新 Ratify 設定？
批准組態是 Kubernetes 自訂資源。 您可以更新這些資源，而無需重新安裝 Ratify：
- 若要更新 Key Vault 相關設定，請使用 Ratify
KeyManagementProvider類型為azurekeyvault的自訂資源。 若要更新信任簽署相關組態，請使用 RatifyKeyManagementProvider自訂資源，其類型為inline。 請遵循 文件。 - 若要更新公證專案信任原則和存放區，請使用 Ratify
Verifier自訂資源。 請遵循 文件。 - 若要驗證容器登錄 （或其他符合 OCI 規範的登錄） 並與之互動，請使用批准存放區自訂資源。 請遵循 文件。
如果我的容器映像未透過 Notation 工具進行簽署，我應該怎麼辦？
本文適用於在任何可以產生符合公證專案的簽名的工具上獨立驗證公證專案簽名。 Ratify 也支援驗證其他類型的簽章。 如需詳細資訊，請參閱 Ratify 使用者指南。