共用方式為


使用 Azure CLI 來建立 Azure 服務主體

使用 Azure 服務的自動化工具應一律具有限制的許可權,以確保 Azure 資源安全。 因此,Azure 提供服務主體,而不是讓應用程式以完全特殊許可權的使用者身分登入。 Azure 服務主體是用來搭配應用程式、託管服務和自動化工具使用的身分識別。 此身分識別可用來存取資源。

在本教學課程中,您會了解如何:

  • 建立服務主體
  • 使用服務主體和密碼登入
  • 使用服務主體和憑證登入
  • 管理服務主體角色
  • 使用服務主體建立 Azure 資源
  • 重設服務主體認證

必要條件

  • 在訂用帳戶中,您必須擁有 User Access Administrator 或許可權或 Role Based Access Control Administrator 更高許可權,才能建立服務主體。 如需 Azure 角色型存取控制可用的角色清單(Azure RBAC),請參閱 Azure 內建角色

建立服務主體

使用 az ad sp create-for-rbac Azure CLI 參考命令來建立服務主體。 此範例不會指定 --name 參數,因此會自動建立包含時間戳的名稱。

az ad sp create-for-rbac

輸出主控台:

{
  "appId": "myAppId",
  "displayName": "myServicePrincipalName",
  "password": "myServicePrincipalPassword",
  "tenant": "myTentantId"
}

如果您未遵守資源命名慣例,並計劃稍後為新的服務主體建立角色和範圍,則不含參數的 az ad sp create-for-rbac 命令是可接受的解決方案。 不過,如果沒有角色和範圍,新的服務主體就無法存取資源。 它只是存在。

當您建立不含參數的服務主體時,也請完成下列步驟:

注意

如果您的帳戶沒有建立服務主體的許可權, az ad sp create-for-rbac 則傳回包含「許可權不足而無法完成作業」的錯誤訊息。 請連絡 Microsoft Entra 系統管理員以建立服務主體。

在使用者設定 [使用者可以註冊應用程式 ] 設定為 [否] 的 Microsoft Entra ID 目錄中,您必須是下列其中一個 Microsoft Entra ID 內建角色的成員(其具有動作: microsoft.directory/applications/createAsOwnermicrosoft.directory/applications/create):

如需 Microsoft Entra ID 中使用者設定的詳細資訊,請參閱 限制誰可以建立應用程式

使用角色和範圍建立服務主體

最佳做法是一律指派特定 --role--scopes 建立服務主體時。 執行下列步驟:

  1. 判斷正確的角色。

    判斷角色時,請一律使用最低許可權原則。 例如,如果服務主體只需要存取資源群組內的 Azure 記憶體,請勿將服務主體 contributor 許可權授與訂用帳戶。 請考慮特定角色,例如 記憶體 Blob 數據參與者。 如需 Azure RBAC 中可用角色的完整清單,請參閱 Azure 內建角色

  2. 取得 scopes 參數的值。

    尋找並複製 Azure 資源的資源識別碼 ,新服務主體需要存取。 此資訊通常位於每個資源的 Azure 入口網站 的 [屬性] 或 [端點] 頁面中。 以下是常見的 --scopes 範例,但 依賴您的 資源標識符 來取得實際的格式和值

    範圍 範例
    訂用帳戶 /subscriptions/mySubscriptionID
    資源群組 /subscriptions/mySubscriptionID/resourceGroups/myResourceGroupName
    虛擬機器 /subscriptions/mySubscriptionID/resourceGroups/myResourceGroupName/providers/Microsoft.Compute/virtualMachines/myVMname
    儲存體 帳戶檔案服務 /subscriptions/mySubscriptionID/resourceGroups/myResourceGroupName/providers/Microsoft.Storage/storageAccounts/myStorageAccountName/fileServices/default
    資料處理站 /subscriptions/mySubscriptionID/resourceGroups/myResourceGroupName/providers/Microsoft.DataFactory/factories/myDataFactoryName

    如需更多範圍範例,請參閱 瞭解 Azure RBAC 的範圍。

  3. 建立服務主體。

    在此範例中,會建立名為 myServicePrincipalName1 的新服務主體,並具有資源群組 RG1 中所有資源的讀取者許可權。

    # Bash script
    az ad sp create-for-rbac --name myServicePrincipalName1 \
                             --role reader \
                             --scopes /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myRG1
    

    參數 --scopes 接受以空格分隔的範圍清單。 在此範例中,會建立名為 myServicePrincipalName2 的新服務主體,並具有資源群組 myRG1 中所有資源的讀取者許可權。 此服務主體也會獲授與 myRG2myVM讀取者許可權。

    # Bash script
    az ad sp create-for-rbac --name myServicePrincipalName2 \
                             --role reader \
                             --scopes /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myRG1 /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myRG2/providers/Microsoft.Compute/virtualMachines/myVM
    

如果您決定授與太多許可權給新的服務主體,請藉由 管理服務主體角色來改變許可權。

使用變數建立服務主體

您也可以使用變數建立服務主體:

# Bash script
let "randomIdentifier=$RANDOM*$RANDOM"
servicePrincipalName="msdocs-sp-$randomIdentifier"
roleName="azureRoleName"
subscriptionID=$(az account show --query id --output tsv)
# Verify the ID of the active subscription
echo "Using subscription ID $subscriptionID"
resourceGroup="myResourceGroupName"

echo "Creating SP for RBAC with name $servicePrincipalName, with role $roleName and in scopes /subscriptions/$subscriptionID/resourceGroups/$resourceGroup"
az ad sp create-for-rbac --name $servicePrincipalName \
                         --role $roleName \
                         --scopes /subscriptions/$subscriptionID/resourceGroups/$resourceGroup

如需服務主體屬性的完整清單,請使用 az ad sp list ,並參閱 取得現有的服務主體

警告

當您使用 az ad sp create-for-rbac 命令建立 Azure 服務主體時,輸出會包含您必須保護的認證。 請務必不要在程式碼中包含這些認證,或是將認證簽入原始檔控制中。 或者,如果有的話,請考慮使用 受控識別 ,以避免需要使用認證。

後續步驟

既然您已瞭解如何建立 Azure 服務主體,請繼續進行下一個步驟,瞭解如何使用服務主體搭配密碼型驗證。