Azure Logic Apps-deployment stroomlijnen met Managed Identity in Azure DevOps: een IaC-aanpak

In het dynamische cloud-computinglandschap van vandaag is het efficiënt en veilig deployen van applicaties van groot belang. Azure Logic Apps springen hierin in het oog en vragen om een unieke aanpak die flexibiliteit met robuustheid in balans brengt. Deze blogpost verkent een gespecialiseerde methode die Azure DevOps en Azure Managed Identities naadloos integreert, specifiek ontworpen voor de deployment van Azure Logic Apps.

De focus ligt hier op het aanpassen en optimaliseren van de deployment van Azure Logic Apps. We lopen door hoe Azure DevOps de ontwikkelcyclus stroomlijnt, terwijl Azure Managed Identities de beveiliging versterken en het handmatig beheren van credentials overbodig maken. Deze combinatie biedt een krachtige toolkit voor developers die Azure Logic Apps efficiënt en veilig willen deployen.

In deze blog verkennen we hoe je DevOps en Managed Identity effectief inzet voor het deployen van Logic Apps. We behandelen:

• Voordelen van Managed Identity
• Infrastructure as Code voor Logic Apps
• API Connection en App Roles

Voordelen van Managed Identity

In de wereld van Azure-cloudservices vormen Service Principals van oudsher een hoeksteen voor het beheren van applicatierechten en toegangscontrole. Deze aanpak kent echter zijn beveiligingsrisico’s, met name rond het beheer van secrets en de integratie met Azure KeyVault.

Ze brengen verschillende beveiligingsuitdagingen met zich mee:

• het beheren van secrets of credentials voor authenticatie is vereist, wat een complexe en veiligheidsgevoelige taak kan zijn.
• zelfs met tools als Azure KeyVault bestaat de kans op onbedoelde blootstelling, met name in geautomatiseerde scripts of wanneer secrets in environment variables worden opgeslagen.
• het regelmatig updaten van secrets is essentieel voor de beveiliging, maar wordt vaak over het hoofd gezien of bemoeilijkt, wat tot potentiële risico’s leidt.
• het handmatige proces van het beheren van deze credentials kan tot fouten en daaropvolgende beveiligingsincidenten leiden.

Managed Identities

Om de uitdagingen rond traditionele Service Principals aan te pakken, heeft Azure Managed Identities geïntroduceerd, een feature die is ontworpen om de beveiliging te versterken en het authenticatieproces te stroomlijnen. Zo pakken Managed Identities deze uitdagingen aan:

• managed Identities maken handmatig secret-beheer overbodig en vereenvoudigen daarmee het authenticatieproces.
• azure neemt de volledige levenscyclus van Managed Identities over, inclusief het aanmaken, beheren en roteren ervan.
• managed Identities stellen developers in staat zich op de ontwikkeling te concentreren, terwijl Azure de complexiteit van veilige authenticatie afhandelt.
• deze aanpak sluit aan op de principes van Infrastructure as Code (IaC) en integreert naadloos in DevOps-workflows, waarmee de beveiliging en efficiëntie van cloudgebaseerd applicatiebeheer worden versterkt.

Infrastructure as Code voor Logic Apps

Bij het aanmaken van een Azure Logic App die gebruikmaakt van Managed Identities kiezen we voor een modulaire aanpak met Bicep-bestanden, die elk een specifiek doel dienen in het deploymentproces. Door de deployment op te splitsen in afzonderlijke Bicep-modules creëren we een schone en onderhoudbare codebase. Zo past elke module in het grotere geheel:

ManagedIdentity.bicep

Deze module is verantwoordelijk voor het aanmaken van de Managed Identity zelf. De Managed Identity fungeert als een veilige principal voor onze Logic App, waarmee deze kan authenticeren bij Azure-services zonder credentials in code op te slaan. Dit is wat de ManagedIdentity.bicep-module doet:

De hoofdmodule van het aangeleverde Azure Bicep-bestand definieert en zet een Microsoft Azure Logic App-workflow op. Deze Logic App is geconfigureerd om automatisch wekelijks te triggeren. Belangrijke componenten zijn onder meer:

Logic App Workflow Definition: er wordt een resource van het type Microsoft.Logic/workflows gedeclareerd, wat de aanmaak van een Logic App aangeeft.

User-Assigned Managed Identity: aan de Logic App wordt een user-defined managed identity toegewezen, waarmee deze veilig kan interacteren met andere Azure-resources. Daarnaar verwezen we in onze Managed Identity.Bicep

Onze derde module, ‘api connection.bicep’, is bedoeld om een API connection-resource voor Office 365 aan te maken. Deze stap is cruciaal, omdat we in dit scenario een logic app gebruiken om Microsoft 365-licenties te monitoren.

API Connection en App Roles

App Roles zijn als de sleutels tot het koninkrijk: ze bepalen wie wat mag doen binnen je applicatie. Je specificeert de rechten die voor verschillende acties vereist zijn en wijst ze toe aan verschillende rollen. Je kunt bijvoorbeeld rollen hebben zoals “ReadUserData” of “WriteCalendarEvents”.

Laten we nu eens kijken hoe dit alles in elkaar past wanneer je applicatie toegang wil tot de Microsoft Graph API:

Je applicatie moet een geauthenticeerd verzoek doen aan de Microsoft Graph API. In plaats van met secrets of credentials te werken, gebruikt deze het identity endpoint van de Managed Identity om een access token te verkrijgen. Dit access token fungeert als het gouden ticket, waarmee je applicatie verzoeken (in dit geval) aan de Microsoft Graph API kan authenticeren.

Maar hoe zorg je ervoor dat de App Roles correct aan je Managed Identity worden toegewezen? Daar komt wat scripting bij kijken. Zo werkt het:

Je haalt de Microsoft Graph Application ID (Graph ID) op. Deze ID is uniek voor Microsoft Graph en identificeert de applicatie.

Met de Graph ID query je de Microsoft Graph API om de lijst met beschikbare App Roles voor je applicatie op te halen.

$graphId = "00000003-0000-0000-c000-000000000000"
$graphversion = "v1.0"
$url = "https://graph.microsoft.com"
$endpoint = "servicePrincipals?`$filter="
$filter = "appId eq '$graphId'"
$uri = "$url/$graphversion/$endpoint$filter"

$graphResource = (az rest --method get --uri $uri | ConvertFrom-Json).value

Vervolgens haal je de specifieke App Role-ID’s op die je applicatie nodig heeft. Je hebt bijvoorbeeld de rol “Organization.Read.All” nodig.

$orgReadAll = az ad sp show --id $graphId --query "appRoles[?value=='Organization.Read.All'].id | [0]" -o tsv

Ten slotte zorg je ervoor dat de Managed Identity deze rollen toegewezen heeft gekregen. Zo niet, dan voeg je de role assignments toe.

foreach ($appRoleId in $appRoleIds) {
    $roleMatch = $currentRoles -match $appRoleId
    if ($roleMatch.Length -eq 0) {
        $body = "{'principalId':'$principalId','resourceId':'$graphResourceId','appRoleId':'$appRoleId'}"
        az rest --method post --uri https://graph.microsoft.com/v1.0/servicePrincipals/$principalId/appRoleAssignments --body $body --headers Content-Type=application/json 
    }
}

Pipeline

We verleggen onze aandacht nu naar de orchestratie van het deploymentproces. Nu we drie cruciale Bicep-modules hebben gemaakt, elk met een specifieke rol—het opzetten van de Managed Identity, het definiëren van de workflow van de Logic App en het inrichten van de API connections—komen we bij de cruciale stap van deployment-automatisering. Om dit te faciliteren benutten we de kracht van YAML-pipelines in Azure DevOps. YAML, een door mensen leesbare data-serialisatiestandaard, gebruiken we hier om onze Continuous Integration/Continuous Deployment (CI/CD)-pipeline te definiëren. Deze YAML-pipeline fungeert als de blauwdruk die Azure DevOps volgt om onze resources te deployen. Hij roept onze Bicep-modules sequentieel aan en zorgt zo dat elke resource correct wordt gedeployt en dependencies worden gerespecteerd.

trigger:
- main

stages:
- stage: Deploy
  jobs:
  - job: DeployBicepModules
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - checkout: self
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'YourAzureServiceConnection' # Replace with your Azure service connection name
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group create --resource-group $(ResourceGroupName) \
            --template-file ./Bicep/ManagedIdentity.bicep \
            --parameters managedIdentityName=$(ManagedIdentityName) resourceLocation=$(ResourceLocation)

          az deployment group create --resource-group $(ResourceGroupName) \
            --template-file ./Bicep/LogicAppWorkflow.bicep \
            --parameters workflowName=$(LogicAppName) resourceLocation=$(ResourceLocation)

          az deployment group create --resource-group $(ResourceGroupName) \
            --template-file ./Bicep/APIConnection.bicep \
            --parameters apiConnectionName=$(APIConnectionName) resourceLocation=$(ResourceLocation)

Deze YAML-pipeline triggert op wijzigingen in de main-branch en gebruikt een Ubuntu latest image-pool om Azure CLI-taken uit te voeren. Elke taak deployt een bijbehorende Bicep-module door het az deployment group create-commando van de Azure CLI aan te roepen, dat resources naar een resource group in Azure deployt.

Met de geconfigureerde YAML-pipeline hebben we nu een geautomatiseerd pad opgezet dat onze Bicep-modules van code naar cloud brengt, waarmee de cyclus van een volledig geautomatiseerde Infrastructure as Code met Managed Identities compleet is.

Eenmaal gedeployt zou het er zo uit moeten zien:

Conclusie

Tot slot hebben we met succes een Logic App met een user-managed identity gedeployt, wat een nieuw tijdperk inluidt van veilige en efficiënte applicatie-deployment. We hebben afscheid genomen van de oude Service Principal-methode en de noodzaak van Azure KeyVault geëlimineerd, waarmee we onze automatiseringsprocessen drastisch hebben gestroomlijnd. Dit versterkt niet alleen de beveiliging, maar maakt ook de weg vrij voor toekomstige applicaties om naadloos managed identities te benutten, wat onze reis naar wendbaardere en veiligere cloudoplossingen versnelt.