Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

18Feb/202

Azure – RBAC Custom Role für das starten und stoppen von VMs

Weil es die Tage bei einem meiner Kunden wieder mal ein Thema war, möchte ich es hier nun mal im Detail beleuchten. Und zwar geht es um die Anforderung, Virtuelle Maschinen in Azure starten und stoppen zu können, ohne beispielsweise die VM löschen zu können oder ihre SKU zu verändern. Natürlich gibt es den "Virtual Machine Contributor" als built-in Role, aber diese darf eben deutlich zu viel.

Wie geht man nun an das Thema heran? Zunächst muss man zwei Dinge in Erfahrung bringen:

  • Den Namen des Resource-Providers um den es geht
  • Die Operationen auf diesem Provider, die man erlauben oder verbieten möchte

Dazu kann man sich in den Microsoft Docs informieren:

Für den Fall der Virtual Machine finden wir dazu also:

  • Der Resource Provider heisst "Microsoft.Compute"
  • Auf diesem sind u.a. folgende Aktionen vorgesehen:
    • Microsoft.Compute/virtualMachines/powerOff/action
      • Powers off the virtual machine. Note that the virtual machine will continue to be billed.
    • Microsoft.Compute/virtualMachines/read
      • Get the properties of a virtual machine
    • Microsoft.Compute/virtualMachines/restart/action
      • Restarts the virtual machine
    • Microsoft.Compute/virtualMachines/start/action
      • Starts the virtual machine

Die Liste der möglichen Aktionen auf einem Resource Provider kann man auch via PowerShell bekommen, z.B.:

1
Get-AzProviderOperation "Microsoft.Compute/*" | FT Operation, Description -AutoSize

Man muss allerdings berücksichtigen, dass es zum Starten einer VM auch erstmal nötig ist, die VM überhaupt sehen zu dürfen...

Als nächstes muss man die Rollen-Definition im JSON-Format schreiben. Dazu kann man sich auch vorab eine bereits existierende Rollendefinition herunterladen, z.B. mit

1
Get-AzRoleDefinition -Name "Virtual Machine Contributor" | ConvertTo-Json

Nun passt man sich das JSON so an, dass die gewünschten Aktionen abgedeckt sind. Dabei wird die "ID" Zeile entfernt und "IsCustom" auf "true" gesetzt. Außerdem muss der AssignableScope gesetzt werden. In unserem Fall führt das in etwa zu dieser Definition:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
  "Name": "Virtual Machine Starter-Stopper",
  "IsCustom": true,
  "Description": "Lets you see, start, restart and stop Virtual Machines.",
  "Actions": [
	"Microsoft.Resources/subscriptions/resourceGroups/read",
    "Microsoft.Compute/virtualMachines/read",
	"Microsoft.Compute/virtualMachines/start/action",
	"Microsoft.Compute/virtualMachines/restart/action",
	"Microsoft.Compute/virtualMachines/powerOff/action",
	"Microsoft.Compute/virtualMachines/deallocate/action"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/00000000-1234-5678-91234-000000000000"
  ]
}

Diese Definition kann man z.B. mit vi in der Azure Cloud Shell in ein File schreiben. Diese kann man dann wiederum mit

1
New-AzRoleDefinition -InputFile myRole.json

in eine neue Rolle schreiben lassen.

Nun kann man die Rolle bspw. über das Azure Portal zuweisen:

Und damit kann der Benutzer dann genau die definierten Rechte wahrnehmen - und nicht mehr!

Viel Spaß beim Ausprobieren!

6Feb/200

Azure – Account Failover für Storage Accounts in der Preview

Wie Microsoft in seinem Blog-Artikel angekündigt hat, ist das "Account Failover" Feature für den Storage Account nun in der Public Preview. Aber worum handelt es sich hier überhaupt?

Schon seit Längerem bieten Storage Accounts die Möglichkeit, die Daten georedundant vorzuhalten. Dabei werden in den Optionen ZRS, GRS und RA-GRS (und neuerdings auch GZRS) die Daten (die am primären Speicherort schon 3-fach vorgehalten werden) in ein anderes Azure Rechenzentrum in der selben Region (ZRS) oder in einer anderen Region gespiegelt. Dies geschieht allerdings asynchron, d.h., bei einem Ausfall in der Ursprungsregion kann es sein, dass nicht alle Daten vollständig gespiegelt worden, somit kann es zu Datenverlust kommen.

Clients write data to the storage account in the primary region

In der Option RA-GRS (Read-access geo-redundant Storage) gibt es die Option, die Daten auch am sekundären Speicherort zu nutzen, aber nur lesend! Das heisst: Kommt es zu einem Ausfall des primären Datacenters, sind meine Daten zwar nach wie vor vorhanden, allerdings komme ich nicht oder nur lesend an diese ran. Das dürfte für die meisten Anwendungsfälle, bei denen die Daten nicht nur als Archiv abgelegt sondern permanent genutzt werden ein Problem sein.

Diesem begegnet Microsoft jetzt mit einem tollen Feature: Account Failover.

Damit kann man nun den Failover (manuell) einleiten, wenn der primäre Endpunkt nicht verfügbar ist. Dadurch wird der bisherige sekundäre Endpunkt zum primären und andersherum. Und das wiederum hat zur Folge, dass man die Daten eben von dort weiterhin lesend und auch schreibend nutzen kann. Allerdings dauert dieser Failover laut Microsoft etwa eine Stunde - eine Dienstunterbrechung kann man damit also im Regelfall nicht vermeiden. Der Failover biegt die DNS-Einträge und Service Endpoints auf den sekundären Endpunkt um.

Customer initiates account failover to secondary endpoint

Allerdings wird der Storage Account dadurch zu einem LRS Account (also ohne zonenübergreifende Redundanz). Wenn gewünscht kann man ihn aber dann wieder in einen georedundanten Storage Account umwandeln - dies ist dann aber mit einer vollständigen (Neu)Replikation und den damit einhergehenden Kosten verbunden! Allerdings scheint das aktuell der einzige Weg für ein Failback zu sein - hier muss man aber dann warten, bis die vollständige Replikation abgeschlossen ist. Microsoft warnt hier vor sonst möglicherweise auftretenden gravierenden Datenverlusten!

Die Preview ist leider nur in diesen Regionen verfügbar:

  • Asia East
  • Asia Southeast
  • Australia East
  • Australia Southeast
  • US Central
  • US East 2
  • US West Central
  • US West 2

Wie bei Previews üblich sind diese nicht für produktive Workloads gedacht und es gibt auch keinen SLA!

Hier findet sich die komplette Doku zu diesem Feature:

https://docs.microsoft.com/en-us/azure/storage/common/storage-disaster-recovery-guidance