Suche

über alle News und Events

 

Alle News

 

Ein Arbeitsplatz ist mehr als nur ein Ort, an dem...

Weiterlesen

Am 01. Oktober ab 12:30 Uhr treffen sich...

Weiterlesen

Die Nutzung des Postman Mock Servers ist einfach...

Weiterlesen

Ein Community-Held feiert seinen Erfolg: „WOW! Ich...

Weiterlesen

Einfach großartig! Die Stimmung war hervorragend....

Weiterlesen

Rules, Rules, RULES!! Dan Toomey, The evolution of...

Weiterlesen

Keynote von Slava Koltovich, Feature: E2E - AIS...

Weiterlesen

Inspirierende Messeerfahrungen auf der 'Zukunft...

Weiterlesen

In diesem Artikel wird beschrieben, wie ihr eure...

Weiterlesen

Messaging mit dem Service Bus ermöglicht die...

Weiterlesen

How-to: Verwendung von IOptions und Azure Key Vault für die sichere Entwicklung in unserer lokalen Entwicklungsumgebung, um konsistente Ergebnisse mit Dependency Injection zu erreichen

Azure Functions benötigen oft einen Connection-String, um sich mit einem Service verbinden zu können. Wir müssen diese Connection-Strings sicher aufbewahren, da es sonst zu hohen Ausführungskosten führen kann, wenn Fremde sich mit unseren Diensten verbinden und diese frei nutzen können.

Bei der Entwicklung in unserer lokalen Entwicklungsumgebung wird von Microsoft empfohlen, mit der Datei local.settings.json zu arbeiten [1]. Es ist wichtig, daran zu denken, diese Datei niemals in einem Repository zu veröffentlichen, da sie viele Secrets enthalten kann, die geändert werden müssen, falls sie öffentlich werden. Außerdem muss man in einem solchen Fall das Repository von der Datei bereinigen.

Man kann Azure Key Vault verwenden, um beliebige Geheimnisse sicher zu speichern. Im Azure-Portal können wir eine neue Ressource erstellen, indem wir "Create a key vault" auswählen, um unseren neuen Azure Key Vault-Dienst zu erstellen. Nachdem unsere Ressource erstellt wurde, können wir zur Seite "Secrets" navigieren, um einen neuen Key zu generieren/importieren.

In der Abbildung oben ist die Seite zum Erstellen eines neuen Secrets zu sehen. Hier können wir unserem Secret einen Namen geben und den Connection-String für unsere Ressource (z. B. Azure Service Bus) eingeben. Auf dieser Seite können wir auch ein Aktivierungs- oder Ablaufdatum für das Secret festlegen. In unserem Beispiel ist dies jedoch vorerst nicht erforderlich. Wir können unsere neue geheime Kennung (engl. Secret Identifier) in die Zwischenablage kopieren, indem wir auf unser neues Key Vault Secret klicken, wie in der Abbildung unten dargestellt wird.

Wenn wir zu unserer Function App zurückkehren, können wir unsere Anwendungseinstellungen im Konfigurationsbereich verwalten. Durch Klicken auf die Schaltfläche "New application setting" können wir unseren Connection-String als Verweis auf einen Key Vault zu unserer Funktionsanwendung hinzufügen. In der Dokumentation wird empfohlen, das folgende Format für solche Werte zu verwenden [2]:

@Microsoft.KeyVault(SecretUri= https://myvault.vault.azure.net/secrets/mysecret/) 

Für die Benennung haben wir uns für das Format FunctionOptions:(Name) entschieden. So können wir das Optionsmuster verwenden, das wir später behandeln werden. Wenn alles richtig eingestellt ist, wird der Wert "Source" von App Service auf Key vault Reference umgestellt, wie in der Abbildung unten dargestellt ist.

In unserer lokalen Entwicklungsumgebung können wir unsere Secrets in der Datei local.settings.json im gleichen Format hinzufügen.

Als Nächstes können wir unsere Datenmodellklasse erstellen, um unsere Optionen zu definieren, wie in der folgenden Abbildung dargestellt ist.

Bevor wir Dependency Injection in unserer Function App verwenden können, sind die folgenden NuGet-Pakete erforderlich [3]:

  • Microsoft.Azure.Functions.Extensions
  • Microsoft.NET.Sdk.Functions (Version >= 1.0.2.8)
  • Microsoft.Extensions.DependencyInjection

Jetzt können wir eine Startup-Klasse zu unserem Function App-Projekt hinzufügen, die als Einstiegspunkt für unsere Anwendung dient. Diese Klasse erbt von der Klasse FunctionsStartup und hat das folgende Attribut am Anfang der Datei vor dem Namespace deklariert:

[assembly: FunctionsStartup(typeof(Startup))]

Nun kann die Configure-Methode der Basisklasse überschrieben werden und Dienste können in dieser Methode registriert werden. In der folgenden Abbildung wird gezeigt, wie die Secrets aus der Datei local.settings.json oder aus der Konfiguration im Azure Portal gelesen werden können. Die Secrets werden aus der Datei ausgelesen und der FunctionOptions-Klasse zugeordnet, die wir in der Klasse Startup erstellt haben. Die Schnittstelle IOptions<FunctionOptions> kann in jede beliebige Dienstklasse durch Dependency Injection hinzugefügt werden. Options sind Teil des NuGetPakets Microsoft.Extensions.Options.

In der folgenden Abbildung wird beispielhaft die IOptions-Schnittstelle in einen Service injiziert, um den Connection-String für einen Blob Client Service festzulegen.

Literaturverzeichnis

[1] Microsoft, „Code and test Azure Functions locally,“ 11 07 2022. [Online]. Available:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-develop-local

[2] Microsoft, „Use Key Vault references for App Service and Azure Functions,“ 23 11 2022. [Online].
Available: https://learn.microsoft.com/en-us/azure/app-service/app-service-key-vaultreferences?tabs=azure-cli

[3] Microsoft, „Prerequisites - Use dependency injection in .NET Azure Functions,“ 11 07 2022.
[Online]. Available: https://learn.microsoft.com/en-us/azure/azure-functions/functions-dotnetdependency-injection#prerequisites

Dieser quiTeq-Tipp kommt aus Berlin von Sinan Tutan.

Ihre Kontaktmöglichkeiten

Sie haben eine konkrete Frage an uns


 

Bleiben Sie immer auf dem Laufenden


 

Mit meinem "Ja" erkläre ich mich mit der Verarbeitung meiner Daten zur Zusendung von Informationen einverstanden. Ich weiß, dass ich diese Erklärung jederzeit durch einfache Mitteilung widerrufen kann. Bei einem Nein an dieser Stelle erhalte ich zukünftig keine Informationen mehr.

© QUIBIQ GmbH · Impressum · Datenschutz