„Reverse engineering“ der Azure REST API

Die Azure REST API ist grundsätzlich gut dokumentiert und dank des REST API Browsers lässt sich auch auf die schnelle etwas ausprobieren. Jedoch gibt es Momente im Azure Portal die zu verwunderten Gesichtern führen und in diesen Fällen helfen die „Developer tools“ von Chrome um Licht ins Dunkel zu bringen.

Das Szenario

Einem Benutzer mit „Read Only“ Rechten auf der Subscription soll es möglich sein zu sehen ob und wohin eine virtuelle Maschine gesichert wird. Die virtuelle Maschine kann der Benutzer noch ohne Probleme sehen, jedoch erscheint nach dem Klick auf „Backup“ die Aufforderung dieses einzurichten.

Für den geneigten Anwender wird also diese virtuelle Maschine nicht gesichert.

Lösungssuche

Mehr Berechtigungen

Mehr ist immer besser und „Read Only“ reicht bei vielen Diensten (z.B. Storage Accounts) nicht aus um mehr als nur die Ressource zu sehen. Was sich in der Ressource befindet ist für den Benutzer unsichtbar.

Also kurzerhand den Benutzer in die Gruppe „Backup Reader“ aufgenommen und geprüft ob man auf den Backup Vault zugreifen kann.

Funktioniert einwandfrei … zurück bei der virtuellen Maschine auf den Backup Reiter geklickt und es erscheint dieselbe Fehlermeldung wie zuvor. Denn beim Backup Vault reicht auch „Reader“ um die einzelnen Protected Items zu erkennen. Zurück ans Reißbrett.

Der Blick unter die Haube

Auf die Übersichtsseite der virtuellen Maschinen zurück und mittels „STRG + SHIFT + I“ die Chrome „Developer tools“ aktivieren.

Dort dann auf die Seite „Network“ wechseln und bei Filter nur XMLHttpRequest (XHR) mitschneiden. Außerdem darauf achten, dass das Log nicht verloren geht (Preserve log)

Jetzt folgt ein Klick auf Backup und die zwei rote „403 – Forbidden“ Fehlermeldungen fallen sofort ins Auge.

Genaueres erfährt man, wenn der betreffenen Request ausgewählt wird. Die Header zeigen an  das hier, anders als erwartet, kein GET durchgeführt wurde, sondern ein POST.

Ganz unten findet sich auch der aufgerufene Request

Unter „Preview“ lässt sich sich der geparsten JSON Output anzeigen und dieser gibt noch mehr Aufschluss über die durchgeführte Aktion „Microsoft.RecoveryServices/locations/backupStatus/action“.

In der RBAC Dokumentation von Microsoft findet sich diese Aktion mit der Beschreibung „Check Backup Status for Recovery Services Vaults“

Die Lösung

Custom RBAC Role

Die Lösung ist schnell implementiert. Da die RBAC Dokumentation sehr aufschlussreich war, erstelle ich eine eigene Rolle mit denselben Rechten wie die „Reader“ Rolle plus der Aktion „Microsoft.RecoveryServices/locations/backupStatus/action“

Jetzt noch die neue Rolle im Azure Portal erstellen und dem Benutzer / der Benutzergruppe zuweisen.

Das Ergebnis

Kann sich sehen lassen. Kein 403 Fehler mehr und der Benutzer sieht sofort das seine virtuelle Maschine gesichert wird. Wiederherstellen darf er aber nichts, dazu fehlen Ihm weitere Rechte.

Bonus

Beim Prüfen der ausgeführten REST Requests fiel mir folgender Request in Auge

Der eigentliche GET Request ist dokumentiert, nicht jedoch der verwendete Filter

Durch diesen wird aus der normalen Antwort …

… eine etwas ausführlichere.

Hilfreich sind dabei z.B. die Werte „oldestRecoveryPoint“ und „recoveryPointCount“ um verwaiste und nicht mehr benötigte Protected Items zu finden. Dazu später mehr.

Ich arbeite als IT Consultant bei Aequitas Integration und habe einen Fokus auf die Microsoft Enterprise Produktpalette.
Jedoch beschäftige ich mich schon lange auch mit Linux und finde auch die unteren OSI Schichten interessant.