Folgender Use Case
Aufgrund einer Anfrage wie man Daten aus einer REST API Schnittstelle abrufen kann, musste ich mir überlegen wie ich diesen Fall umsetze. Folgende Voraussetzungen wurden gewünscht:
ich soll die ADF nutzen, möglichst sicher den Token speichern, Daten filtern und anschließend das File oder die Daten im JSON Format in einem Azure Date Lake Storage Gen2 speichern.
Um zu veranschaulichen wie sowas gehen kann, habe ich mir ein Beispiel gesucht. In diesem Fall rufe ich die Subscriptions aus einem Microsoft Tenant ab. Die Datenfilterung werde ich mir hier sparen.
Vorweg möchte ich sagen das dieses ein Weg von vielen sein kann und das es sicher nicht die eierlegende Wollmichsau präsentiert. Hier möchte ich nur meinen Weg beschreiben der grundsätzlich zum Erfolg führte. Der Use Case selbst war noch wesentlich Komplizierter und das hier dient als Einstieg. Weiter ist der Artikel doch etwas länger geworden als gedacht. Mir war wichtig das einmal soweit wie möglich zu dokumentieren.
Erstellen der Azure Services
Dazu habe ich mir überlegt die Komponenten zu nutzen die größtenteils schon vorgegeben waren.
! Ein erster Hinweis von mir!
Sollte es Probleme geben mit dem erstellen des Access Token, empfiehlt es sich als erstes Postman zu nutzen um zu prüfen ob der Key erstellt wird. Das hat den Vorteil das man später nicht immer den Debug Modus aktivieren muss um zu prüfen ob der Token erstellt wird.
Folgende Services werden benötigt
1. Azure Data Factory
2. Azure Key Vault um den Token sicher zu speichern und anschließend abzurufen.
3. Azure Data Lake Storage Gen2
4. Eine Azure Identität die berechtigt ist Daten aus dem Microsoft Tenant abzurufen.
Fangen wir an und legen als erstes den Azure Data Lake Storage Gen2 an. Da es sich hier um ein Testszenario handelt, müssen wir nicht auf Redundanzen achten.
Da ich einen Azure Data Lake Storage Gen2 nutzen möchte, muss auf der nächsten Seite der Haken bei „hierarchical Namespace“ gesetzt werden.
Alle anderen Einstellungen können wir so lassen und klicken weiter bis wir anschließend zur Zusammenfassung kommen. Sofern keine Fehler angezeigt werden klicken wir auf „Create“ und es sollte nur ein paar Minuten dauern bis der ADLSv2 erstellt wurde.
Im nächsten Schritt erstellen wir die Azure Data Factory. Ich wähle hier die Ressourcengruppe die ich im ersten Schritt erstellt habe. Die restlichen Einstellungen auf diesem Tab können so übernommen werden. Anschließend auf „Next“.
Wir können bis zur Zusammenfassung weiterklicken und dann auf „Create“ klicken. Nach wenigen Sekunden/Minuten sollte die Data Factory dann erstellt worden sein.
Im nächsten Schritt nehme ich dann noch eine Einstellung in der Data Factory vor und aktiviere die Managed Identity. Diese werden wir später auch noch für den Zugriff auf den Azure Key Vault benötigen, welchen wir im nächsten Step dann bereitstellen.
Hier die Einstellungen auf der ersten Seite so übernehmen wie auf dem Screenshot zu sehen. Dann auf „Next“.
Auf der nächsten Seite kommen wir dann zu den Permissions. Wir müssen hier die Azure Data Factory zuätzlich eintragen damit wir entsprechende Secrets abrufen können. Wie auf dem Screenshot zu sehen, die entsprechenden Checkboxen anhaken und auf „Next“.
Wir kommen dann zur Auswahl eines Principals. Ich suche nach der Data Factory und wähle diese anschließend aus. Auch hier wieder alles zu sehen auf dem Screenshot. Dann auf „Next“ und die neue Poliy bestätigen.
Hier auf „Next“.
Wir können dann bis zu Review und Create weiterklicken und bekommen dann diese Zusammenfassung.Dann auf „Create“ und der Key Vault wird mit den Einstellungen erstellt.
Nach der Erstellung kontrollieren wir die Access Konfiguration nochmal, um zu prüfen, ob die Data Factory vorhanden ist.
In den Key Vault und Access Poliy wählen.
Als letzten Schritt legen wir noch eine Entra ID (vormals Azure AD) Identität an an und erstellen einen dazugehörigen Secret. Die App werden wir für die Authentifizierung benötigen.
Wir gehen dazu in Microsoft Entra ID und folgen den Schritten wie im Screenshot beschrieben.
Hier vergeben wir einen Namen und gehen dann auf Register. Alle anderen Einstellungen sind für unseren Test nicht entscheidend. Die App sollte dann relativ zeitnah erstellt worden sein.
Jetzt geht es darum noch einen Secret zu erstellen. Einfach den Anweisungen auf dem Screenshot folgen.
Sobald der Secret erstellt worden ist, diesen sofort kopieren und am besten in einem Textdokument abspeichern.
Der Secret wird, sobald wir die APP verlassen, nur noch verschlüsselt angezeigt und ist dann nicht mehr kopierbar.
! Wichtig an dieser Stelle !
Die APP muss noch die nötigen Berechtigungen bekommen um Zugriff auf die einzelnen Subscriptions zu bekommen die wir auslesen wollen. Hier zu habe ich der APP die „Reader“ Rolle zugewiesen.
Im nächsten Schritt werden wir die IDs die wir abgespeichert haben zum Azure Key Vault hinzufügen. Dazu einfach in den Key Vault wechseln und die drei Secrets anlegen über Generate/Import. Ein Name sowie der Secret muss dann entsprechend vergeben bzw. eingegeben werden. Im ersten Screenshot sehen wir die erstellten Secrets. Als nächsten Schritt dann die, so genannten, Identifier jedes Secrets in ein Textdokument kopieren. Diese werden wir später benötigen.
Dies sollte wie folgt aussehen (Hier ein Beispiel):
https://vaultname.vault.azure.net/secrets/
TenantID/4444444444444444444444444444444444
Konfigurieren der Azure Data Factoy
Kümmern wir uns nun also um die Data Factory.
Zuänchst erstellen wir eine neue Pipeline und darin suchen wir nach Web und ziehen uns drei Web Aktivitäten in das rechte Fenster. Diese Pipeline soll dazu dienen, die Secrets abzurufen und später den erstellten Token an die nächste Pipeline zu übergeben. Die nächsten drei Screenshots zeigen was eingestellt werden muss. Die URL ist ensprechend jeder Aktivität reinzukopieren. Am Ende jeder URL muss noch der Zusatz „?api-version=7.0“ hinzugefügt werden.
Hier ein Beispiel (auch in den Screenshots zu sehen):
https://vaultname.vault.azure.net/secrets/
TenantID/4444444444444444444444444444444444?api-version=7.0
Jetzt ist es an der Zeit die Pipeline schon mal zu testen. Einfach über den Debug Button gehen und die Pipeline starten. Wie im Screenshot zu sehen hat dieses einwandfrei funktioniert.
Um die Sicherheit noch etwas zu erhöhen, aktiviere ich bei jeder Web Aktivität das Secure Input und Secure Output. Das hat zur Folge das die Secrets nicht mehr protokolliert werden.
Um nun den Token zu generieren, erstelle ich eine weitere WEB Akivität und verbinde alle drei Webaktivitäten mit dieser. Unter Schritt 2 im folgenden Screenshot diese URL eintragen.
Im zweiten Schritt dann unter BODY folgende Einstellungen setzen. Method sollte POST sein.
Um jetzt weiterzumachen zu können, erstellen wir als erstes eine neue Pipeline. Für diese erstellen wir einen Parameter den ich hier als „token“ bezeichne.
Anschließend gehen wird dann aber zurück in die bereits bestehende Pipeline Get-Tokens (in meinem Fall) und ziehen die „Execute Pipeline“ Aktivität in das Fenster. Anschließend verbinden wir die Aktivität mit der Token erstellen Aktivität.
Im ersten folgenden Screenshot sind die Einstellungen für die „Execute Pipeline“ zu sehen.
Hier der dynmamische Ausdruck:
Soweit so gut.
Kümmern wir uns jetzt um die zweite Pipeline.
Dazu holen wir uns wieder eine Web Aktivität und ziehen diese in das Fenster.
Wie im folgenden Screenshot zu sehen, müssen wir auch hier einen Ausdruck hinterlegen. Als Method stellen wir GET ein. Im unteren Screenshot erstellen wir für den Header die Authorization. Dazu holen wir uns per Parameter aus der vorherigen Pipeline den Token.
Hier der Ausdruck dazu:
Die folgenden Schritte (was die Variable betrifft) sind nicht notwendig. Ich wollte hier nur veranschaulichen, dass wir die Ergebnisse auch erst in eine Variable speichern können und dann weiterverarbeiten. Es besteht jetzt auch die Möglichkeit direkt in den Storage Account zu schreiben!
Erstellen wir trotzdem die Variable in diesem Fall:
Holen wir uns die SET-Variable Aktivität und ziehen diese in das Fenster. Anschließend verbinden wir diese mit der Get-Subscription Unfiltered Aktivität.
Wir wechseln dann in den Reiter Settings.
Bevor wir aber eine Variable – Name auswählen können müssen wir diese noch in der Pipeline erstellen .
Ich habe diese subscriptionsarry benannt vom Typ Array. Unter dem Value tragen wir dann noch folgenden Ausdruck ein.
Damit die Daten nun im ADLSv2 speichern zu können, holen wir uns eine weitere WEB- Aktivität und ziehen diese wieder in das Fenster um sie mit der Variablen zu verbinden.
Wie oben schon erwähnt, können wir diese Aktivität auch direkt mit der Get Subscription Unfiltered Aktivität verbinden um die Ergebnisse zu speichern. Die Variable ist nicht notwendig.
Folgende URL dort eintragen.
https://platzhalterstorageaccountname.blob.core.windows.net/azure/subscriptions/subscriptions.json?resource=file
Kurz zur Erklärung der URL:
Hinter .net/ befindet sich der Pfad, wo wir die Daten speichern möchten.
Meint: der Container hat den Namen „azure“ und der Ordner hat den Namen „subscriptions“. Der Name Subcriptions.json ist der Dateiname.
Weiter gehts…
Wenn ihr die Variable nutzen wollt, tragt ihr folgendes in den Body ein.
Weiter müssen wir einen Container und einen Ordner anlegen. In meinem Fall habe ich den Container „azure“ und den Ordner „subscriptions“ genannt.
Im letzten Schritt testen wir die Pipeline und können dann in den Storage Account gehen. Wie im Screenshot zu sehen, wurde eine Subscriptions.json mit unserem gewünschten Inhalt erstellt.
Wenn ihr die Variable ausgelassen habt, sieht der Inhalt folgendendermaßen aus im zweiten Screenshot.
FAZIT
Jetzt wären wir also schon am Ende diese Blog Artikels, aber oben schon erwähnt, war der Use Case wesentlich komplizierter und dieser Artikel dient als Einstieg/ Idee um damit zu beginnen. Ausserdem sollte eine gewisse Knowledge vorhanden sein um die Azure Services konfigurieren zu können.
Sollte es Fragen oder Anregungen geben, kontaktiert mich gerne oder lasst einen Kommentar da.
Schreibe einen Kommentar