這個錯誤訊息代表你目前的帳號雖然可以建立資源，但沒有權限指派角色（Role Assignment）。
Error message:
(AuthorizationFailed) The client '[email protected]' with object id '7a85725f' does not have authorization to perform action 'Microsoft.Authorization/roleAssignments/write' over scope '/subscriptions/XXX/resourceGroups/rg-pr-stg-jpe-001/providers/Microsoft.ContainerRegistry/registries/arcprstgjpe001/providers/Microsoft.Authorization/roleAssignments/be44c8b3' or the scope is invalid. If access was recently granted, please refresh your credentials.
Code: AuthorizationFailed
在 Azure 的權限體系中，建立資源只需要 Contributor (參與者) 權限，但指派權限（RBAC）則需要 Owner (擁有者) 或 User Access Administrator (使用者存取管理員) 權限。
核心問題：權限不足
你的帳號在該 Subscription 或 Resource Group 層級缺少 Microsoft.Authorization/roleAssignments/write 這個權限。
解決方法
聯繫管理員提升權限
你需要請該訂用帳戶的管理者，將你的帳號權限提升。
- 目標角色：Owner 或 User Access Administrator。
- 範圍：建議在資源群組
rg-pr-stg-jpe-001層級設定即可。
檢查目前的權限
你可以執行以下指令，看看自己在該資源群組下到底有什麼角色：
PowerShell
az role assignment list --assignee [email protected] --resource-group rg-pr-stg-jpe-001 --output table
暫時繞過方法：使用 Admin User (不推薦用於正式環境)
如果你急著測試 App Service 能否抓到影像，可以先避開 RBAC，直接開啟 ACR 的管理員帳號密碼：
PowerShell
# 1. 開啟 ACR 管理員功能
az acr update --name arcprstgjpe001 --admin-enabled true
# 2. 取得帳號密碼
az acr credential show --name arcprstgjpe001
開啟後，你可以直接在 App Service 的部署設定中使用這組帳密，而不需要執行 az role assignment。
長期來看，要在 CI/CD 流程中自動化設定權限，你必須具備 Owner 角色。如果是公司內部的 PoC 環境，通常會直接給予開發負責人 Owner 權限以利測試。
這兩個角色都擁有指派權限的能力，但它們在 對資源的操作權限 上有本質的區別。
Owner (擁有者)
這是權限最高的角色。
- 完全控制權：擁有者可以對該範圍（訂閱或資源群組）內的所有資源進行任何操作，包括建立、讀取、修改、刪除資源。
- 權限管理：可以指派或移除其他人的 RBAC 角色。
- 適用場景：通常給予專案負責人或系統管理員，因為他們需要處理資源的生命週期（如建立資料庫、刪除伺服器）以及團隊成員的權限。
User Access Administrator (使用者存取管理員)
這是一個專注於 安全與合規 的角色。
- 無資源操作權：這個角色不能建立、啟動或刪除資源（如虛擬機、資料庫、ACR）。如果一個帳號只有這個角色，他連建立一個 Resource Group 都辦不到。
- 權限管理：他唯一能做的就是管理角色指派。
- 適用場景：通常給予公司的資安人員或稽核人員。他們負責審核與發放權限，但不會去動到工程師的資源配置，符合最小權限原則（Principle of Least Privilege）。
比較表
| 功能 | Owner (擁有者) | User Access Administrator |
| 管理角色指派 (RBAC) | 可以 | 可以 |
| 建立/刪除 Azure 資源 | 可以 | 不可以 |
| 查看/讀取 資源內容 | 可以 | 不可以 |
| 角色性質 | 全能管理 | 純權限管理 |
針對你目前的問題
你目前遇到 AuthorizationFailed，是因為你目前的身分（可能是 Contributor）雖然可以建立 ACR，但無權指派 acrpull 權限。
- 如果你希望以後能 一條龍處理到底（建資源 + 設權限），你應該請管理員給你 Owner。
- 如果公司規範較嚴，不希望你擁有刪除所有東西的權限，但又要你能設權限，管理員則會給你 Contributor + User Access Administrator 的組合。
Q: 如果要讓 resource group 下的 Contributor role 也可以 deploy local image to azure, 需要額外的權限?
需要額外權限。 Azure Contributor 角色可以管理 Azure 資源，但通常不包含推送影像到 ACR 的資料存取權（ Data-plane ）。要讓擁有 Contributor 權限的使用者從本機推送影像，需要補足以下相關權限：
- 容器鏡像推送：需要在 ACR acrooostgjpe001 範圍加上 AcrPush 角色。如果使用 az acr login 或管理員憑證，還需要讀取憑證的權限，建議改用 az acr login –expose-token 或直接指派 AcrPush 給個人或服務主體。
- 部署容器服務：更新 Container Apps 只需原本的 Contributor 權限即可。但如果過程中需要建立 Role Assignment 或修改 Key Vault Access Policy ，則不在 Contributor 範圍內，需要 User Access Administrator 或 Owner 角色。
- 金鑰與資料庫存取：讀取 Key Vault Secret 另需 Key Vault Secrets User 角色（ RBAC 模式）或 Access Policy ； SQL Database 的 Managed Identity 權限則必須在 SQL 資料庫內部另行授予， Contributor 並不等於資料庫本身的存取權限。
已完成權限設定。參與者原本在 rg-ooo-stg-jpe-001 已具有 Contributor ；現在也都已在 ACR acrooostgjpe001 scope 增加 AcrPush ，可從 local 執行 Docker image push。Azure RBAC 可能需要幾分鐘傳播，之後可重新登入 Azure/ACR 再測試 az acr login 與 docker push 。
情境一：從本機執行 docker push 到 ACR
只需要在 ACR acr-demo 具有 AcrPush 權限，就可以登入並推送影像。
指令範例：
az acr login –name acr-demo
docker push acr-demo.azurecr.io/my-image:latest
AcrPush 包含兩項關鍵動作：
- Microsoft.ContainerRegistry/registries/pull/read
- Microsoft.ContainerRegistry/registries/push/write
這個步驟只需 ACR 權限，不需要 Container App 環境的權限。
情境二：執行腳本更新 Container App
更新 Container App 影像時，腳本會執行：
az containerapp update –name app-demo –resource-group rg-app-demo –image my-image:latest
因此帳號需要以下權限：
- Microsoft.App/containerApps/read
- Microsoft.App/containerApps/write
如果部署腳本設定如下：
- Resource Group 為 rg-app-demo
- Container App 環境為 cae-demo
當帳號擁有 rg-app-demo 的 Contributor 權限，加上 ACR 的 AcrPush 權限，就能完成打包、推送與更新。
情境三：部署至共用環境
當 Container App 與共用環境 cae-shared 分屬不同 Resource Group 時，權限劃分如下：
- ACR acr-demo：需具備 AcrPush 權限
- 應用程式 Resource Group (rg-app-demo)：需具備 Container App 更新權限
- 共用環境 Resource Group (rg-shared-demo)：需具備共用環境讀取或連接權限
若缺乏共用環境權限，執行部署時可能會出現 AuthorizationFailed 錯誤，提示缺少以下權限：
- Microsoft.App/managedEnvironments/read
- Microsoft.App/managedEnvironments/join/action
權限規劃建議
建議採用最小權限原則進行設定：
- ACR acr-demo：指派 AcrPush
- 應用程式 Resource Group (rg-app-demo)：指派 Contributor 或自訂更新角色
- 共用環境 Resource Group (rg-shared-demo)：指派 Reader 權限，必要時再補充 join 動作權限
如果 Container App 與其執行的環境位在相同的 Resource Group 內，現有的 Contributor 與 AcrPush 設定即可順利運作。