Service Principals & Workload Identities Service Principals & Workload Identities

Referenz zu Service Principals, Managed Identities und Workload Identity Federation in Entra ID und Azure. Reference for service principals, managed identities, and workload identity federation in Entra ID and Azure.

Service Principal Typen Service principal types

Ein Service Principal repräsentiert eine Anwendung oder einen Workload innerhalb eines Tenants. Er besitzt Anmeldeinformationen, Rollen und eine Sicherheitsidentität für Tokens und Richtlinien. A service principal represents an application or workload inside a tenant. It owns credentials, roles, and a security identity for tokens and policies.

Managed Identities Managed identities

Managed Identities delegieren die Verwaltung von Credentials an Azure. Eine system-assigned identity ist an genau eine Ressource gebunden, während eine user-assigned identity separat erstellt und mehreren Ressourcen zugewiesen werden kann. Managed identities delegate credential management to Azure. A system-assigned identity is bound to exactly one resource, whereas a user-assigned identity is created separately and can be attached to multiple resources.

            
                # User-assigned managed identity anlegen
                $mi = New-AzUserAssignedIdentity `
                  -Name "uami-contoso-deploy" `
                  -ResourceGroupName "rg-identity" `
                  -Location "westeurope"
                
                # App Service mit der Identity verbinden
                Set-AzWebApp `
                  -Name "contoso-api-prod" `
                  -ResourceGroupName "rg-apps" `
                  -AssignIdentity $true `
                  -UserAssignedIdentityId $mi.Id
                        
            
        

Workload Identity Federation Workload identity federation

Workload Identity Federation ersetzt gespeicherte Secrets durch Vertrauensstellungen auf OIDC-Token. Besonders wertvoll ist das für GitHub Actions, Kubernetes und andere CI/CD-Systeme, die kurzlebige Identitätsnachweise ausstellen können. Workload identity federation replaces stored secrets with trust relationships based on OIDC tokens. It is especially valuable for GitHub Actions, Kubernetes, and other CI/CD systems that can issue short-lived identity assertions.

Federation Credential Konfiguration Federation credential configuration

            
                $app = Get-MgApplication -Filter "displayName eq 'contoso-deploy'"
                
                $body = @{
                  name = "github-main"
                  issuer = "https://token.actions.githubusercontent.com"
                  subject = "repo:contoso/api:ref:refs/heads/main"
                  audiences = @("api://AzureADTokenExchange")
                  description = "GitHub Actions deployment from main"
                } | ConvertTo-Json
                
                Invoke-MgGraphRequest -Method POST `
                  -Uri "https://graph.microsoft.com/beta/applications/$($app.Id)/federatedIdentityCredentials" `
                  -Body $body `
                  -ContentType "application/json"
                        
            
        

Berechtigungen für Managed Identities Assign permissions to managed identities

Für Azure-Ressourcen nutzt du Azure RBAC, etwa Reader, Key Vault Secrets User oder Storage Blob Data Contributor. Für Microsoft Graph oder eigene APIs arbeitest du mit App Roles auf dem Service Principal der Managed Identity. For Azure resources, use Azure RBAC roles such as Reader, Key Vault Secrets User, or Storage Blob Data Contributor. For Microsoft Graph or custom APIs, work with app roles on the managed identity's service principal.

• Control Plane: Rollen auf Subscription, Resource Group oder Resource Level. Control plane: roles on subscription, resource group, or resource level.
• Data Plane: z. B. Blob Data Reader oder Key Vault Secrets User. Data plane: e.g. Blob Data Reader or Key Vault Secrets User.
• Graph/API: App Role Assignment gegen den Resource Service Principal. Graph/API: app role assignment against the resource service principal.

            
                # Azure RBAC
                New-AzRoleAssignment `
                  -ObjectId $mi.PrincipalId `
                  -RoleDefinitionName "Key Vault Secrets User" `
                  -Scope "/subscriptions/<subId>/resourceGroups/rg-sec/providers/Microsoft.KeyVault/vaults/kv-prod"
                
                # Graph App Role Assignment (Beispiel)
                $graphSp = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"
                $role = $graphSp.AppRoles | Where-Object Value -eq "User.Read.All"
                $miSp = Get-MgServicePrincipal -Filter "displayName eq 'uami-contoso-deploy'"
                
                New-MgServicePrincipalAppRoleAssignment `
                  -ServicePrincipalId $miSp.Id `
                  -PrincipalId $miSp.Id `
                  -ResourceId $graphSp.Id `
                  -AppRoleId $role.Id
                        
            
        

SP Credential Management SP credential management

Wo Managed Identity oder Federation nicht möglich sind, verwalte Secrets und Zertifikate strikt nach Laufzeit, Scope und Besitzer. Inventarisierung, Ablaufmonitoring und Rotation sind Pflicht. Where managed identity or federation is not possible, manage secrets and certificates strictly by lifetime, scope, and owner. Inventory, expiry monitoring, and rotation are mandatory.

PowerShell + Graph PowerShell + Graph

            
                # Service Principals inventarisieren
                Get-MgServicePrincipal -All |
                  Select-Object DisplayName, Id, AppId, ServicePrincipalType, AccountEnabled
                
                # Federated Credentials lesen
                Invoke-MgGraphRequest -Method GET `
                  -Uri "https://graph.microsoft.com/beta/applications/$($app.Id)/federatedIdentityCredentials"
                
                # Nicht mehr benötigtes Secret entfernen
                Remove-MgApplicationPassword `
                  -ApplicationId $app.Id `
                  -KeyId "<key-guid>"
                        
            
        

Workload Identity Federation KomplettreferenzComplete workload identity federation reference

Workload Identity Federation ersetzt langlebige Secrets durch vertrauensbasierte OIDC- oder Tokenaustauschbeziehungen. Besonders wertvoll ist das für GitHub Actions, Kubernetes, Google Cloud, AWS und generische OIDC-Issuer.Workload identity federation replaces long-lived secrets with trust-based OIDC or token exchange relationships. It is especially valuable for GitHub Actions, Kubernetes, Google Cloud, AWS, and generic OIDC issuers.

GitHub Subject Claim FormateGitHub subject claim formats

Kubernetes, AKS und externe ClusterKubernetes, AKS, and external clusters

• AKS mit Workload Identity verwendet einen OIDC Issuer pro Cluster und projected service account tokens pro Pod.AKS with workload identity uses an OIDC issuer per cluster and projected service account tokens per pod.
• Der Container erhält den Pfad über AZURE_FEDERATED_TOKEN_FILE und die Ziel-Client-ID über AZURE_CLIENT_ID.The container receives the token path through AZURE_FEDERATED_TOKEN_FILE and the target client ID through AZURE_CLIENT_ID.
• Für externe Cluster gelten dieselben Claims; entscheidend ist, dass iss, aud und sub exakt mit der federatedIdentityCredential in Entra übereinstimmen.External clusters follow the same claim rules; the key is that iss, aud, and sub exactly match the federatedIdentityCredential in Entra.

name: deploy-with-federation

on:
  push:
    branches:
      - main
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: prod
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Azure login via OIDC
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      - name: Show caller
        run: az account show

      - name: Deploy Bicep
        run: |
          az deployment group create \
            --resource-group rg-prod-contoso \
            --template-file infra/main.bicep \
            --parameters environment=prod

      - name: Read Graph token audience
        run: az account get-access-token --resource-type ms-graph

      - name: Logout
        run: az logout

az aks update \
  --name aks-prod \
  --resource-group rg-aks \
  --enable-oidc-issuer \
  --enable-workload-identity

az identity create \
  --name id-orders-api \
  --resource-group rg-aks

az identity federated-credential create \
  --name fic-orders-api \
  --identity-name id-orders-api \
  --resource-group rg-aks \
  --issuer $(az aks show -g rg-aks -n aks-prod --query oidcIssuerProfile.issuerUrl -o tsv) \
  --subject system:serviceaccount:orders:orders-api \
  --audience api://AzureADTokenExchange

kubectl create namespace orders
kubectl create serviceaccount orders-api -n orders
kubectl annotate serviceaccount orders-api -n orders azure.workload.identity/client-id=<managed-identity-client-id>
kubectl label serviceaccount orders-api -n orders azure.workload.identity/use=true

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:contoso/api:ref:refs/heads/main"
        }
      }
    }
  ]
}

Managed Identity Unterstützung nach DienstManaged identity support by service

Die folgende Übersicht fasst häufig genutzte Azure-Dienste zusammen. Die Angaben beziehen sich auf die übliche Ressourcenkonfiguration; einzelne Unterressourcen oder Alt-SKUs können abweichen.The following overview summarizes commonly used Azure services. The values reflect the usual resource configuration; individual sub-resources or older SKUs can differ.