Section purpose

This section maps the five major Azure automation platforms to their security properties, authentication requirements, and appropriate use cases. The goal is to help you choose the right tool for a scenario, configure it with the strongest available credential pattern, and connect it to the right trigger type. By the end of this section you should be able to evaluate an existing automation workload and identify whether it is using the best available authentication and design.

Learning Objectives

• How to select the right Azure automation platform for a given scenario
• How to migrate Automation Accounts from Run As Account to managed identity
• How to configure Workload Identity Federation for GitHub Actions and Azure DevOps
• Why Logic App connection objects are a credential governance concern
• How to apply vNet integration and Private Endpoints for network security
• How to match trigger types to business events

Automation platform overview

Azure Automation Accounts

Azure Automation Accounts are the most IT-admin-friendly Azure automation platform. They support PowerShell 5.1, PowerShell 7.x, and Python 3 runbooks, and they run on a Microsoft-managed infrastructure. Key use cases include scheduled administrative tasks, event-driven Azure resource management, and hybrid on-premises automation via Hybrid Runbook Workers.

Run As Account retirement

The Run As Account was a certificate-backed service principal that Automation Accounts used to authenticate to Azure. Microsoft retired it on September 30, 2023. Any Automation Account still using a Run As Account must migrate to managed identity. There is no supported path forward that restores Run As Account functionality.

Managed identity for Automation Accounts

Automation Accounts support both system-assigned and user-assigned managed identities:

• Use system-assigned managed identity for a 1:1 relationship between the Automation Account and its identity.
• Use user-assigned managed identity when the same identity is shared across multiple Automation Accounts or when the identity must persist independently.

In a runbook, authenticate using the Connect-AzAccount -Identity pattern:

Connect-AzAccount -Identity
# For user-assigned, add: -AccountId "<client-id>"

$secret = Get-AzKeyVaultSecret `
  -VaultName "my-keyvault" `
  -Name "my-secret" `
  -AsPlainText

PowerShell 7 source control limitation

Automation Account native source control sync has incomplete support for PowerShell 7.x runbooks. Teams using PS7 should use a CI/CD pipeline (GitHub Actions or Azure DevOps) to deploy runbooks rather than relying on the built-in sync. This limitation does not affect PS 5.1 runbooks.

Hybrid Runbook Workers

Hybrid Runbook Workers allow Automation Account runbooks to execute on machines in your on-premises network, in other clouds, or in Azure virtual networks. This enables managing on-premises Active Directory, SQL Server, or other resources that are not reachable from the public internet. Hybrid workers use the Azure Arc agent for connectivity and do not require opening inbound firewall ports.

Azure Logic Apps

Logic Apps provide low-code workflow orchestration with hundreds of managed connectors for services like Exchange Online, SharePoint Online, Teams, ServiceNow, and many others. They are the primary platform for Microsoft Sentinel playbooks.

Two hosting models exist:

• Consumption: serverless, per-execution billing, limited runtime options.
• Standard: runs on App Service infrastructure, supports vNet integration, better fit for enterprise workloads with network security requirements.

Connection objects as hidden credential stores

Most built-in Azure connectors (Blob Storage, Key Vault, Service Bus) support managed identity. The Standard Logic App tier enables system-assigned managed identity by default.

Logic App managed identity pattern

For connectors that support it, configure authentication at the connection level to use the Logic App's managed identity rather than a stored user credential. This eliminates OAuth token expiry failures and removes the dependency on a specific user account.

Azure Function Apps

Function Apps are code-based serverless compute that supports C#, Python, JavaScript, and PowerShell. They are the best choice when Logic App connectors do not cover the required integration or when complex data transformation is needed.

Hosting plans:

• Consumption: lowest cost, cold starts acceptable, no vNet support.
• Premium: pre-warmed instances, vNet integration available.
• Dedicated (App Service Plan): most control, vNet integration, consistent performance.

Managed identity and Application Insights

All Function App hosting plans support managed identity. Enable Application Insights on every Function App used for security automation. Application Insights provides execution telemetry, error tracking, dependency tracing, and performance metrics that are essential for monitoring automation health.

# PowerShell Function App: retrieve secret using managed identity
using namespace System.Net

param($Request, $TriggerMetadata)

Connect-AzAccount -Identity | Out-Null

$secret = Get-AzKeyVaultSecret `
  -VaultName $env:KEY_VAULT_NAME `
  -Name "api-key" `
  -AsPlainText

Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = [HttpStatusCode]::OK
    Body       = "Retrieved successfully"
})

Azure DevOps Pipelines

Azure DevOps Pipelines is a CI/CD platform for deploying code and infrastructure. Service connections to Azure use Workload Identity Federation as the default and recommended pattern. WIF-based service connections issue OIDC tokens per pipeline run with no stored secret in Azure DevOps.

Use YAML pipelines for all new work. Classic pipelines cannot be stored in source control, reviewed as code, or audited through normal pull request processes.

Managed identity service connections are also available for self-hosted agents running on Azure VMs or Arc-enabled machines.

GitHub Actions

GitHub Actions is a CI/CD and automation platform. Workload Identity Federation with Entra via OIDC is the modern authentication approach.

The flow:

1. A GitHub Actions workflow requests an OIDC token from GitHub's identity provider (https://token.actions.githubusercontent.com/).
2. The token contains claims including sub (subject), repository, ref, and environment.
3. Entra validates the token against the federated credential configuration on the app registration.
4. If the claims match, Entra issues an access token.
5. The workflow uses the access token for Azure API calls.

Workflow configuration (no secrets stored in GitHub):

permissions:
  id-token: write
  contents: read

steps:
  - uses: azure/login@v3
    with:
      client-id: ${{ vars.AZURE_CLIENT_ID }}
      tenant-id: ${{ vars.AZURE_TENANT_ID }}
      subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

WIF subject claim security

Good subject claim examples:

• repo:contoso/security-automation:ref:refs/heads/main - only the main branch of one specific repo
• repo:contoso/security-automation:environment:production - only the production environment of one specific repo

Bad subject claim example:

• repo:org/*:ref:* - any branch in any repo under the organization (overly broad)

Choosing the right tool

Use this decision framework:

• Need scheduled or on-demand PowerShell/Python runbooks, or on-premises access via Hybrid Runbook Workers? Use Azure Automation Account.
• Need low-code orchestration with managed connectors, or building a Sentinel playbook? Use Logic Apps.
• Need custom code logic, complex data transformation, or integration beyond available connectors? Use Function Apps.
• Automation is tied to code or infrastructure changes (deploy runbooks, Bicep templates, policy configs)? Use Azure DevOps Pipelines or GitHub Actions.
• Avoid using Logic Apps for heavy data processing; avoid using Automation Accounts for high-frequency event-driven workloads; avoid using CI/CD pipelines for tasks triggered by non-developers.

Authentication and authorization best practices

• Always prefer managed identity for workloads running in Azure.
• For CI/CD pipelines, always use Workload Identity Federation. Never store service principal client secrets in pipeline variables or secrets stores when WIF is available.
• Grant only the permissions the automation task requires. Assign Azure RBAC roles at the narrowest scope (resource or resource group, not subscription).
• Use Graph application permissions that are scoped: prefer Sites.Selected over Sites.ReadWrite.All.
• Set expiry on all service principal secrets and certificates. Monitor for approaching expiry.
• Store any required secrets in Azure Key Vault and access them via managed identity RBAC, not hardcoded values.

Network security controls

Defense-in-depth applies at the network layer in addition to identity controls.

• vNet integration: Standard Logic Apps and Premium and Dedicated Function Apps support outbound vNet integration. This routes automation outbound traffic through your private network rather than the public internet.
• Private Endpoints: Key Vault, Storage Accounts, Service Bus, and other Azure services support Private Endpoints. When a Private Endpoint is configured, access from outside the private network is blocked. Automation workloads in the same vNet reach these services over private addresses.
• Automation Account Hybrid Runbook Workers: restrict outbound internet access on Hybrid Worker VMs and use the Azure Arc agent for connectivity.
• Workload ID Premium Conditional Access: add IP-based sign-in restrictions to service principal authentication as a second layer of defense if a credential is stolen.

Trigger types

Match the trigger to the business event:

• Scheduled: regular reports, cleanup jobs, compliance scans, daily sync. Supported by Automation Account schedules, Logic App recurrence, Function App timer triggers, and GitHub Actions scheduled workflows.
• Alert and incident: Azure Monitor action groups → Logic Apps or Automation Account webhooks. Sentinel automation rules → Logic App playbooks. Near-real-time (NRT) Sentinel analytics rules can trigger playbooks within minutes.
• Event-driven: Azure Event Grid delivers events from Key Vault (secret expiry), Storage (blob created), Entra (audit events via Microsoft Defender for Cloud Apps), and other sources to Logic Apps or Function Apps. Graph API change notifications deliver near-real-time Entra object changes for user lifecycle automation.
• CI/CD: code push, pull request merge, tag creation in GitHub or Azure DevOps.
• HTTP/webhook: Logic App HTTP trigger or Function App HTTP trigger. Protect with managed identity, API key stored in Key Vault, or IP restrictions. Use these for ITSM integrations, admin consent workflow callbacks, or external ticketing systems.

Lab readiness notes

Guided lab

Lab goal

Configure Workload Identity Federation for a GitHub Actions workflow, deploy an HTTP-triggered Logic App you can wire to Entra audit events, and publish a Function App that retrieves a Key Vault secret using managed identity.

Prerequisites

• Application Administrator or Global Administrator in the training tenant
• Contributor on the lab resource group in the lab subscription
• GitHub account (personal or organizational) with ability to create a repository
• Azure CLI or PowerShell Az module available
• GitHub CLI (gh) optional but helpful

Task 1: Configure WIF for a GitHub Actions workflow

Use one repository throughout this task. The commands below were validated against a disposable private GitHub repository and a disposable Entra application.

Entra Portal:

Create the app registration and federated credential

1. Go to Identity > Applications > App registrations > New registration.
2. Name the app Lab4-GitHubWIF-<initials> and choose Accounts in this organizational directory only.
3. After the app is created, go to Certificates & secrets > Federated credentials.
4. Choose GitHub Actions deploying Azure resources, set your GitHub owner and repository, and scope the subject to the main branch.
5. Record the application (client) ID and tenant ID for GitHub Actions variables.

Graph PowerShell:

Create the Entra objects with Invoke-MgGraphRequest

Connect-MgGraph -Scopes "Application.ReadWrite.All","Application.Read.All","AppRoleAssignment.ReadWrite.All"

$repoOwner = "<github-owner>"
$repoName = "<repo-name>"
$displayName = "Lab4-GitHubWIF-$(Get-Date -Format 'yyyyMMddHHmmss')"

$app = Invoke-MgGraphRequest `
  -Method POST `
  -Uri "https://graph.microsoft.com/v1.0/applications" `
  -Body @{ displayName = $displayName; signInAudience = "AzureADMyOrg" }

$servicePrincipal = Invoke-MgGraphRequest `
  -Method POST `
  -Uri "https://graph.microsoft.com/v1.0/servicePrincipals" `
  -Body @{ appId = $app.appId }

Invoke-MgGraphRequest `
  -Method POST `
  -Uri "https://graph.microsoft.com/v1.0/applications/$($app.id)/federatedIdentityCredentials" `
  -Body @{
    name        = "github-main"
    issuer      = "https://token.actions.githubusercontent.com"
    subject     = "repo:$repoOwner/$repoName:ref:refs/heads/main"
    audiences   = @("api://AzureADTokenExchange")
    description = "GitHub Actions WIF for main branch"
  }

$graphSp = Invoke-MgGraphRequest `
  -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/servicePrincipals?`$filter=appId eq '00000003-0000-0000-c000-000000000000'&`$select=id,appRoles"

$organizationReadAllRoleId = ($graphSp.value[0].appRoles | Where-Object {
  $_.value -eq "Organization.Read.All" -and $_.allowedMemberTypes -contains "Application"
} | Select-Object -First 1).id

Invoke-MgGraphRequest `
  -Method POST `
  -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/$($servicePrincipal.id)/appRoleAssignments" `
  -Body @{
    principalId = $servicePrincipal.id
    resourceId  = $graphSp.value[0].id
    appRoleId   = $organizationReadAllRoleId
  }

Az CLI:

Create the same trust and seed GitHub Actions variables

$repoOwner = "<github-owner>"
$repoName = "<repo-name>"
$resourceGroupName = "<resource-group>"

$displayName = "Lab4-GitHubWIF-$(Get-Date -Format 'yyyyMMddHHmmss')"
$app = az ad app create --display-name $displayName --sign-in-audience AzureADMyOrg | ConvertFrom-Json
$servicePrincipal = az ad sp create --id $app.appId | ConvertFrom-Json

$federatedCredentialBodyPath = Join-Path $env:TEMP "section4-federated-credential.json"
(@{
    name        = "github-main"
    issuer      = "https://token.actions.githubusercontent.com"
    subject     = "repo:$repoOwner/$repoName:ref:refs/heads/main"
    audiences   = @("api://AzureADTokenExchange")
    description = "GitHub Actions WIF for main branch"
} | ConvertTo-Json -Depth 5) | Set-Content -Path $federatedCredentialBodyPath -Encoding ascii

az ad app federated-credential create --id $app.id --parameters "@$federatedCredentialBodyPath" | Out-Null

$resourceGroupId = az group show --name $resourceGroupName --query id -o tsv
az role assignment create `
  --assignee-object-id $servicePrincipal.id `
  --assignee-principal-type ServicePrincipal `
  --role Reader `
  --scope $resourceGroupId | Out-Null

$graphSpId = az ad sp list `
  --filter "appId eq '00000003-0000-0000-c000-000000000000'" `
  --query "[0].id" `
  -o tsv

$organizationReadAllRoleId = az rest `
  --method get `
  --uri "https://graph.microsoft.com/v1.0/servicePrincipals/$graphSpId/appRoles?`$select=id,value,allowedMemberTypes" `
  --query "value[?value=='Organization.Read.All' && contains(allowedMemberTypes, 'Application')].id | [0]" `
  --output tsv

$appRoleAssignmentBodyPath = Join-Path $env:TEMP "section4-org-read-all.json"
(@{
    principalId = $servicePrincipal.id
    resourceId  = $graphSpId
    appRoleId   = $organizationReadAllRoleId
} | ConvertTo-Json -Compress) | Set-Content -Path $appRoleAssignmentBodyPath -Encoding ascii

az rest `
  --method post `
  --uri "https://graph.microsoft.com/v1.0/servicePrincipals/$($servicePrincipal.id)/appRoleAssignments" `
  --headers "Content-Type=application/json" `
  --body "@$appRoleAssignmentBodyPath" | Out-Null

$tenantId = az account show --query tenantId -o tsv
$subscriptionId = az account show --query id -o tsv

gh secret set AZURE_CLIENT_ID --repo "$repoOwner/$repoName" --body $app.appId
gh secret set AZURE_TENANT_ID --repo "$repoOwner/$repoName" --body $tenantId
gh secret set AZURE_SUBSCRIPTION_ID --repo "$repoOwner/$repoName" --body $subscriptionId

GitHub Actions:

Validate Azure login and a Graph organization read with no client secret

name: oidc-validation

on:
  workflow_dispatch:
  push:
    branches:
      - main

jobs:
  validate:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - 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 Azure context
        run: az account show --query '{subscription:name, tenant:tenantId, user:user.name}' -o json
      - name: Read organization from Microsoft Graph
        shell: bash
        run: |
          graph_token=$(az account get-access-token --resource-type ms-graph --query accessToken -o tsv)
          curl -sS -H "Authorization: Bearer ${graph_token}" "https://graph.microsoft.com/v1.0/organization?\$select=id,displayName" | jq .

Expected outcomes:
- The workflow authenticates through OIDC with no stored client secret
- az account show succeeds in GitHub Actions
- The Graph organization read returns tenant details

Task 2: Build a Logic App with an Entra audit log trigger

Azure Portal:

Create the workflow and point Entra diagnostics at the callback URL

1. Create a Logic App (Consumption) in the lab resource group.
2. Use When a HTTP request is received as the trigger and add a response or compose action so you can inspect the payload.
3. Save the workflow and copy the generated callback URL.
4. In Entra, go to Monitoring > Diagnostic settings and send AuditLogs to that callback URL.

Native PowerShell:

Deploy a disposable HTTP-triggered Logic App through ARM

$resourceGroupName = "<resource-group>"
$logicAppName = "Lab4-AuditLogApp-$(Get-Date -Format 'MMddHHmm')"
$location = "<location>"

$logicDefinition = @'
{
  "location": "<location>",
  "properties": {
    "state": "Enabled",
    "definition": {
      "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
      "contentVersion": "1.0.0.0",
      "parameters": {},
      "triggers": {
        "manual": {
          "type": "Request",
          "kind": "Http",
          "inputs": {
            "schema": {
              "type": "object",
              "properties": {
                "event": {
                  "type": "string"
                }
              }
            }
          }
        }
      },
      "actions": {
        "response": {
          "type": "Response",
          "kind": "Http",
          "runAfter": {},
          "inputs": {
            "statusCode": 200,
            "body": {
              "receivedEvent": "@triggerBody()?['event']"
            }
          }
        }
      },
      "outputs": {}
    },
    "parameters": {}
  }
}
'@.Replace('<location>', $location)

$logicDefinitionPath = Join-Path $env:TEMP "section4-logic-app.json"
$logicDefinition | Set-Content -Path $logicDefinitionPath -Encoding utf8

az resource create `
  --resource-group $resourceGroupName `
  --resource-type Microsoft.Logic/workflows `
  --name $logicAppName `
  --is-full-object `
  --properties "@$logicDefinitionPath"

Az CLI:

Get the callback URL and post a sample event

$subscriptionId = az account show --query id -o tsv
$callbackUrl = az rest `
  --method post `
  --uri "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/<resource-group>/providers/Microsoft.Logic/workflows/<logic-app-name>/triggers/manual/listCallbackUrl?api-version=2019-05-01" `
  --query value `
  --output tsv

Invoke-RestMethod `
  -Method Post `
  -Uri $callbackUrl `
  -Body '{"event":"AuditEvent"}' `
  -ContentType "application/json"

Expected outcomes:
- The workflow can be created and tested without the Logic App CLI extension
- The callback URL accepts a sample event immediately
- After you wire Entra diagnostics to the same callback, audit log payloads follow the same path

Task 3: Function App with managed identity calling Key Vault

Azure Portal:

Create the Key Vault secret and assign the Function App identity

1. Create the Key Vault and the Function App.
2. Enable the Function App system-assigned managed identity.
3. If the vault uses RBAC, grant yourself Key Vault Secrets Officer or Key Vault Administrator before creating the first secret.
4. Grant the Function App managed identity Key Vault Secrets User on the vault.

Az CLI:

Provision the storage account, Key Vault, secret, and Function App identity

$resourceGroupName = "<resource-group>"
$location = "<location>"
$storageAccountName = "<storage-account>"
$keyVaultName = "<key-vault-name>"
$functionAppName = "<function-app-name>"

az storage account create `
  --name $storageAccountName `
  --resource-group $resourceGroupName `
  --location $location `
  --sku Standard_LRS `
  --kind StorageV2

az keyvault create `
  --name $keyVaultName `
  --resource-group $resourceGroupName `
  --location $location `
  --enable-rbac-authorization true

az keyvault secret set `
  --vault-name $keyVaultName `
  --name DemoSecret `
  --value "SuperSecretValue123"

az functionapp create `
  --name $functionAppName `
  --resource-group $resourceGroupName `
  --storage-account $storageAccountName `
  --consumption-plan-location $location `
  --os-type Windows `
  --runtime powershell `
  --functions-version 4 `
  --assign-identity [system] `
  --disable-app-insights true

$functionPrincipalId = az functionapp identity show `
  --name $functionAppName `
  --resource-group $resourceGroupName `
  --query principalId `
  -o tsv

$keyVaultId = az keyvault show --name $keyVaultName --query id -o tsv
az role assignment create `
  --assignee-object-id $functionPrincipalId `
  --assignee-principal-type ServicePrincipal `
  --role "Key Vault Secrets User" `
  --scope $keyVaultId

Native PowerShell:

Package, deploy, and test the PowerShell function

$functionAppName = "<function-app-name>"
$resourceGroupName = "<resource-group>"
$keyVaultName = "<key-vault-name>"

$tempRoot = Join-Path $env:TEMP "section4-functionapp"
Remove-Item $tempRoot -Recurse -Force -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Path (Join-Path $tempRoot "GetSecret") -Force | Out-Null

@'
{
  "version": "2.0"
}
'@ | Set-Content -Path (Join-Path $tempRoot "host.json") -Encoding utf8

@'
{
  "bindings": [
    {
      "authLevel": "anonymous",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": ["get"]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}
'@ | Set-Content -Path (Join-Path $tempRoot "GetSecret\function.json") -Encoding utf8

@'
param($Request)

$tokenResponse = Invoke-RestMethod -Method GET -Uri "$($env:IDENTITY_ENDPOINT)?resource=https://vault.azure.net&api-version=2019-08-01" -Headers @{ 'X-IDENTITY-HEADER' = $env:IDENTITY_HEADER }
$secretResponse = Invoke-RestMethod -Method GET -Uri "https://$($env:KEY_VAULT_NAME).vault.azure.net/secrets/$($env:SECRET_NAME)?api-version=7.4" -Headers @{ Authorization = "Bearer $($tokenResponse.access_token)" }

Push-OutputBinding -Name Response -Value ([HttpResponseContext]@{
    StatusCode = 200
    Body = @{
        secretName = $env:SECRET_NAME
        secretLength = $secretResponse.value.Length
    }
})
'@ | Set-Content -Path (Join-Path $tempRoot "GetSecret\run.ps1") -Encoding utf8

$zipPath = Join-Path $env:TEMP "section4-functionapp.zip"
Remove-Item $zipPath -Force -ErrorAction SilentlyContinue
Compress-Archive -Path (Join-Path $tempRoot '*') -DestinationPath $zipPath

az functionapp config appsettings set `
  --name $functionAppName `
  --resource-group $resourceGroupName `
  --settings KEY_VAULT_NAME=$keyVaultName SECRET_NAME=DemoSecret WEBSITE_RUN_FROM_PACKAGE=1 | Out-Null

az functionapp deployment source config-zip `
  --name $functionAppName `
  --resource-group $resourceGroupName `
  --src $zipPath

Invoke-RestMethod -Method Get -Uri "https://$functionAppName.azurewebsites.net/api/GetSecret"

Expected outcomes:
- The Function App retrieves the secret through managed identity
- No client secret or Key Vault secret value is stored in configuration
- The HTTP response shows the secret name and length, not the secret itself

Common pitfalls

• WIF subject claim mismatch: the GitHub branch in the federated credential must match the branch that actually runs the workflow.
• GitHub workflow permissions must include id-token: write or OIDC login fails even when the federated credential is correct.
• Logic App callback URLs change if you delete and recreate the workflow. Update the Entra diagnostic setting if you redeploy the Logic App.
• Key Vault RBAC propagation can take a few minutes. A 403 immediately after role assignment usually means the role has not propagated yet.
• Resource group Contributor is not enough to create the first Key Vault secret when the vault uses RBAC. You need a data-plane role such as Key Vault Secrets Officer.

Admin takeaways

Quick recap questions

1. Why was the Automation Account Run As Account retired and what should replace it?
2. What is the security risk of an overly permissive WIF subject claim?
3. Where do Logic App connection objects store credentials and why is this a governance concern?
4. What two network controls can restrict outbound traffic from a Function App to only private network paths?
5. Which trigger type is most appropriate for a Sentinel playbook that responds to security alerts?
6. When should you choose an Automation Account over a Function App?

Key reminders

• Run As Account is retired - migrate to managed identity.
• WIF removes stored secrets from CI/CD - but subject claims must be scoped tightly.
• Logic App connections run as a user unless explicitly changed to service principal or managed identity.
• Network controls (vNet integration, Private Endpoints) complement identity controls - use both.
• Application Insights is the monitoring layer for Function Apps - enable it on every security automation Function App.

References Appendix

All links below were reviewed on 2026-03-10.

Azure Automation Accounts

• Azure Automation overview
• Migrate from Run As accounts to managed identities
• Use a system-assigned managed identity for an Azure Automation account
• Azure Automation source control integration
• Hybrid Runbook Worker overview

Azure Logic Apps

• Azure Logic Apps overview
• Single-tenant vs. multi-tenant and integration service environment for Azure Logic Apps
• Authenticate access to Azure resources with managed identities in Azure Logic Apps
• Set up virtual network integration for Standard logic app workflows

Azure Function Apps

• Azure Functions overview
• Azure Functions hosting options
• Use managed identity for Azure Functions
• Monitor Azure Functions with Application Insights
• Configure Azure Functions networking options

Workload Identity Federation

• Workload identity federation overview
• Configure a GitHub Actions workflow to get an access token
• GitHub Actions: Configuring OpenID Connect in Azure
• Use workload identity federation with Azure DevOps service connections

Azure DevOps Pipelines

• Azure Pipelines documentation
• YAML schema reference for Azure Pipelines
• Use service connections in Azure Pipelines

Triggers and event-driven automation

• Azure Event Grid overview
• Microsoft Graph change notifications overview
• Azure Monitor action groups
• Microsoft Sentinel automation rules

Network security

• Azure Private Endpoint overview
• Integrate your app with an Azure virtual network