Programmatisch Azure resources beheren via de Azure Resource Manager (ARM)

Terwijl ik dit schrijf, is Microsoft hard aan het werk om de transitie van de Azure Service Management (ASM) API’s naar de Azure Resource Management (ARM) API’s af te ronden. Beide API’s bieden de mogelijkheid om je Azure resources te beheren en zijn de REST API’s achter Azure Powershell en de Azure portal.

De oudere, ASM API wordt niet voor niks vervangen. Het grote nadeel van deze API is, dat hij niet de mogelijkheid biedt tot fine-grained autorisaties. De enige manier om toegang tot resources te beheren is op het niveau van de subscription. Je kunt niet per resource bepalen wie waar bij mag. In elke organisatie met meer dan een paar resources is dit volledig onacceptabel.

De ARM API is op dit punt een grote stap vooruit. Met ARM kun je Azure Service Management (ASM) APIs to the per resource bepalen wie er bij kan en zelfs regelen wat men precies mag.

Maar dat is niet alles. Naast personen zijn er soms ook applicaties of systemen die toegang nodig hebben tot een of meer Azure resources. Via ASM kon dit door het gebruik van zogenaamde management certificates. De houder van zo’n certificaat had dan volledige controle over een subscription. Met ARM is het mogelijk om ook applicaties gericht toegang te geven tot een subset van je resources. Het is echter niet erg duidelijk hoe dit werkt. In dit blog zal ik dan ook laten zien hoe je een applicatie toegang kan geven tot Azure resources volgnes het principle of least privilege. Voor autorisatie zal ik daarvoor gebruik maken van certificaten, een veiligere methodiek dan wachtwoorden.

Iedereen die, via ARM, toegang tot een subscription heeft moet bekend zijn in de Azure Active Directory (AAD) die bij die subscription hoort. Dit geld niet alleen voor personen, maar ook voor applicaties. Het registreren van een applicatie in de AAD kan helaas nog niet in de nieuwe portal. We moeten dus terug naar de oude portal of gebruik maken van Powershell. Nadat de applicatie geregistreerd is in de AAD, moet deze ook nog geautoriseerd worden op een resourcegroup. Dit kan echter weer alleen in de nieuwe portal of via Powershell. Om die reden kies ik voor Powershell zodat ik niet heen en weer hoef tussen portals.

Om verbinding te maken met de AAD vanuit Powershell is er een specifieke Powershell module (MSOL) nodig, die je hier vindt.

Allereerst registreren we de applicatie:

Nu voegen we authenticatie op basis van een certificaat toe:

Tenslotte moeten we de applicatie rechten geven op een resource. Voor dit doel heb ik een resourcegroup ‘poc’ aangemaakt:

De applicatie schrijven

Nu dat we een applicatie in de AAD geregistreerd hebben, kunnen we de applicatie zelf schrijven. Hieronder vind je een minimaal voorbeeld voor authenticatie en het opvragen van een lijst van alle storage accounts in een rsource group:

Er zijn twee NuGET packages die je moet installeren om deze code te draaien: Microsoft.IdentityModel.Clients.ActiveDirectory and Microsoft.Azure.Management.Storage

En hier het eindresultaat: Een overzicht van alle storage accounts in de resource group. Andere acties, zoals het toevoegen of verwijderen van storage accounts zijn natuurlijk ook mogelijk..

ARMCertificateAuth

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *