詢問 Gemini 後得知 Cloud Build 和 Cloud Run 的執行權限可以分開設定，因此將兩者的帳號分開管理，並重新記錄。

紀錄使用到的權限

這次開啟的 Audit Logs 有這些：

Cloud Build 會用到的權限有：

method: "Docker-FinishUpload",
method: "Docker-GetManifest",
method: "Docker-HeadBlob",
method: "Docker-PutManifest",
method: "Docker-StartUpload",
method: "google.cloud.run.v1.Services.GetService",
method: "google.cloud.run.v1.Services.ReplaceService",
method: "iam.serviceAccounts.actAs",

Cloud Run 跑服務時用到的權限有：

method: "google.cloud.aiplatform.v1.ReasoningEngineExecutionService.QueryReasoningEngine",
method: "google.cloud.aiplatform.v1.ReasoningEngineExecutionService.StreamQueryReasoningEngine",
method: "google.cloud.aiplatform.v1.ReasoningEngineService.GetReasoningEngine",

其實就是把 aiplatform 的 get 與 query 權限從 Cloud Build 移去 Cloud Run 就可以了，所以要新增一個有 Agent 存取權限的角色：

- aiplatform.reasoningEngines.query
- aiplatform.reasoningEngines.get

接著建立一個專供 Cloud Run 使用的 Service Account，並指派上述角色以執行服務。

自訂角色

總結一下目前設定角色，用於部屬 API Server 的 Cloud Run Deployer and Log Manager (另外加了 Log 的權限才能存記錄到 Cloud Build)：

title: "Cloud Run Deployer and Log Manager"
description: "Custom role for deploying Cloud Run, managing Artifacts, and handling basic logging."
stage: "GA"
includedPermissions:
- artifactregistry.repositories.uploadArtifacts
- artifactregistry.repositories.downloadArtifacts
- run.services.get
- run.services.update
- iam.serviceAccounts.actAs
- logging.logEntries.create
- logging.logEntries.route

運行 API Server 的 Reasoning Engine Viewer and Querier ：

title: "Reasoning Engine Viewer and Querier"
description: "Custom role for viewing and querying Vertex AI Reasoning Engines."
stage: "GA"
includedPermissions:
- aiplatform.reasoningEngines.query
- aiplatform.reasoningEngines.get

以及部屬 Vertex AI Agent Engine 的 Reasoning Engine and Storage Accessor ：

title: "Reasoning Engine and Storage Accessor"
description: "Custom role for getting/updating Reasoning Engines and managing Storage objects."
stage: "GA"
includedPermissions:
- aiplatform.reasoningEngines.get
- aiplatform.reasoningEngines.update
- storage.buckets.get
- storage.objects.create
- storage.objects.get

分別建立與設定 Service Account ：

權限設計總結

這樣的權限設計就合理多了，只有編譯和部屬的時候可以有較高的權限，而用來接收使用者資料的 API Server 僅具備對 Agent 請求的權限，這麼一來就算 API Server 存在漏洞，被駭客拿下控制權，也能將控制範圍限制在容器內，避免整個 Google Cloud 專案遭到全面掌控。