疑難排解 Google Cloud 服務的常見 VPC Service Controls 問題

本頁面提供解決方案，協助您解決使用 VPC Service Controls perimeter 內的Google Cloud 服務時可能遇到的問題。

Cloud Build 問題

在 VPC Service Controls perimeter 內使用 Cloud Build 資源時，會受到一些已知限制。詳情請參閱「搭配 Cloud Build 使用 VPC Service Controls 的限制」。

Cloud Build 服務帳戶無法存取受保護的資源

Cloud Build 會使用 Cloud Build 服務帳戶代表您執行建構作業。根據預設，在 Cloud Build 上執行建構作業時，建構作業會在專案外部的租戶專案中執行。

即使專案位於 perimeter 內部，產生建構輸出內容的 Cloud Build worker VM 仍位於 VPC Service Controls perimeter 外部。因此，如要讓建構作業存取 perimeter 內的資源，您必須將 Cloud Build 服務帳戶新增至存取層級或輸入規則，藉此授予該帳戶 VPC Service Controls perimeter 的存取權。

詳情請參閱「授予 Cloud Build 服務帳戶 VPC Service Controls perimeter 存取權」。

Cloud Storage 問題

以不存在的 Logging Cloud Storage bucket 為目標時遭到拒絕

如果指定的記錄檔 bucket 不存在，VPC Service Controls 會拒絕存取，並顯示 RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER 違規事項原因。

您可以使用 VPC Service Controls 專屬 ID (vpcServiceControlUniqueIdentifier) 查看存取遭拒的記錄。以下是記錄範例，其中包含 RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER 違規事項原因：

"serviceName": "storage.googleapis.com",
"methodName": "google.storage.buckets.update",
"resourceName": "projects/325183452875",
"metadata": {
  "violationReason": "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER",
  ...
  "egressViolations": [
    {
      "sourceType": "Resource",
      "targetResource": "projects/0/buckets/this-bucket-does-not-exist",
      "source": "projects/325183452875/buckets/bucket-in-same-project",
      "servicePerimeter": "accessPolicies/875573620132/servicePerimeters/prod_perimeter"
    }]}

如果 egressViolations 物件中的 targetResource 欄位顯示含有 projects/0/buckets 的目標，則系統一律會觸發拒絕，因為 projects/0 不存在，且視為超出 service perimeter。

存取 Google 自有公開 Cloud Storage bucket 時遭到拒絕

Service perimeter 不得包含不同組織的專案。Perimeter 只能包含上層組織的專案。如要從位於不同機構的 VPC Service Controls perimeter 內專案存取 Cloud Storage bucket，會受到某些限制。

常見範例是存取 Google 自有 Cloud Storage bucket。由於您的專案和包含目標 bucket 的 Google 自有專案不在同一個 perimeter 內，VPC Service Controls 會拒絕要求，並顯示 RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER 違規事項原因。

如要解決這個問題，可以建立輸入和輸出規則。

從 perimeter 內存取可公開存取的 Cloud Storage bucket

如果您嘗試從 service perimeter 內存取可公開存取的 Cloud Storage bucket，VPC Service Controls 可能會擲回輸出違規事項，藉此封鎖您的要求。

為確保能視需要持續成功存取物件，我們應將輸出規則套用至受影響的 service perimeter。

Security Command Center 問題

本節列出您在使用 VPC Service Controls perimeter 內部的 Security Command Center 資源時，可能會遇到的問題。

Security Command Center 無法傳送通知至 Pub/Sub

嘗試將 Security Command Center 通知發布至 VPC Service Controls perimeter 內部的 Pub/Sub 主題時，會因 RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER 違規事項而失敗。

建議您在組織層級啟用 Security Command Center。VPC Service Controls 不會將上層組織視為子項專案 perimeter 的一部分。如要這麼做，您必須授予 Security Command Center perimeter 存取權。

如要解決這個問題，請採取下列任一做法：

使用不在 service perimeter 內的專案中的 Pub/Sub 主題。
在完成通知設定前，請從 service perimeter 中移除 Pub/Sub API。

如要進一步瞭解如何啟用傳送至 Pub/Sub 主題的 Security Command Center 通知，請參閱「啟用 Pub/Sub 發現項目通知」。

Security Command Center 無法掃描 perimeter 內部的 Compute Engine 資源

Security Command Center 會使用每個產品和每個專案的服務帳戶 (P4SA) service-{project_number}@gcp-sa-computescanning.iam.gserviceaccount.com，掃描專案中的 Compute Engine 資源。如要讓 Security Command Center 存取 perimeter 內部的資源，請將 P4SA 新增至存取層級或輸入規則。否則可能會看到 NO_MATCHING_ACCESS_LEVEL 錯誤。

Security Command Center 無法掃描 service perimeter 內部的資源

安全狀態分析會使用 P4SA (每個產品和每個專案的服務帳戶) service-org-ORGANIZATION_ID@security-center-api.iam.gserviceaccount.com 掃描專案中的資源。如要讓 Security Command Center 存取 perimeter 內部的資源，請將 P4SA 帳戶新增至存取層級或輸入規則。否則會看到 NO_MATCHING_ACCESS_LEVEL 錯誤。

Google Kubernetes Engine 問題

本節列出使用 VPC Service Controls perimeter 內部的 Google Kubernetes Engine 資源時，可能會遇到的問題。

在啟用可存取服務和受限制服務的 perimeter 中，自動配置器無法運作

autoscaling.googleapis.com 未與 VPC Service Controls 整合，因此無法新增至受限制服務，也無法新增至可存取的服務。無法在可存取的服務中允許 autoscaling.googleapis.com API。因此，如果 perimeter 啟用可存取的服務，叢集自動配置器可能無法運作。

建議不要使用可存取的服務。使用受限制虛擬 IP (VIP) 時，請為 autoscaling.googleapis.com 建立例外狀況，以便在含有自動調度資源叢集的 perimeter 中前往私人 VIP。

BigQuery 問題

本節列出您在使用 VPC Service Controls perimeter 內部的 BigQuery 資源時，可能會遇到的問題。

VPC Service Controls perimeter 限制不適用於 BigQuery 查詢結果匯出作業

如果您嘗試限制從 BigQuery 匯出受保護資料至 Google 雲端硬碟、Google 試算表或 Looker Studio，可能會發現實際行為與預期不符。從 BigQuery UI 執行查詢時，結果會儲存在電腦的本機記憶體中，例如瀏覽器快取。這表示結果現在位於 VPC Service Controls 外部，因此您可能會將結果儲存為 CSV 檔案或儲存至 Google 雲端硬碟。

在此情境中，由於結果是從 service perimeter 外部的本機電腦匯出，因此 VPC Service Controls 的運作方式符合預期，但 BigQuery 資料的整體限制遭到規避。

如要解決這個問題，請移除 bigquery.tables.export 權限，限制使用者的 IAM 權限。請注意，這麼做會停用所有匯出選項。

GKE Enterprise 問題

本節列出使用 VPC Service Controls perimeter 內部的 GKE Enterprise 資源時，可能會遇到的問題。

如要疑難排解使用 VPC Service Controls 和 Cloud Service Mesh 時發生的錯誤，請參閱「疑難排解代管型 Cloud Service Mesh 的 VPC Service Controls 問題」。

GKE Enterprise Config Controller 設定產生輸出違規事項

如果在 perimeter 外部的專案中沒有允許使用 google.containers.registry.read 方法存取 containerregistry.googleapis.com 的輸出設定，設定 GKE Enterprise Config Controller 時，預期會失敗。

如要解決這項錯誤，請建立下列輸出規則：

From:
  Identities:ANY_IDENTITY
To:
  Projects =
    NNNNNNNNNNNN
  Service =
  Service name: containerregistry.googleapis.com
  Service methods:
    containers.registry.read

將規則新增至違規的 perimeter 後，輸出違規事項就會消失。

Container Registry 問題

本節列出您在使用 VPC Service Controls perimeter 內部的 Container Registry 資源時，可能會遇到的問題。

VPC Service Controls 封鎖 Container Registry API 要求，即使輸入或輸出規則允許也不例外

如果您使用輸入規則允許存取 Container Registry，且 identity_type 欄位設為 ANY_USER_ACCOUNT 或 ANY_SERVICE_ACCOUNT，VPC Service Controls 會封鎖存取權。

如要解決這個問題，請將 identity_type 欄位更新為輸入或輸出規則中的 ANY_IDENTITY。

服務代理程式在將 Artifact Registry 擁有的 Docker 映像檔複製到 perimeter 內的專案時發生輸出錯誤

嘗試將 Artifact Registry 擁有的映像檔複製到 VPC Service Controls perimeter 內的專案時，服務代理程式 cloud-cicd-artifact-registry-copier@system.gserviceaccount.com 的記錄中可能會出現輸出錯誤。如果 perimeter 政策處於模擬測試模式，通常會發生這類輸出錯誤。

如要解決這個問題，請建立輸出規則，允許服務代理程式 cloud-cicd-artifact-registry-copier@system.gserviceaccount.com 存取 VPC Service Controls 錯誤記錄中提及的專案內 storage.googleapis.com 服務。

Vertex AI 問題

本節列出在 VPC Service Controls perimeter 內使用 Vertex AI 資源時，可能會遇到的問題。

VPC Service Controls 封鎖使用者代管的 Notebooks API 要求，即使輸入或輸出規則允許也不例外

如果您已使用輸入政策允許存取使用者代管的 Notebooks API，並將 identity_type 設為 ANY_USER_ACCOUNT 或 ANY_SERVICE_ACCOUNT，VPC Service Controls 會封鎖對該 API 的存取權。