Um HTML zum PDF zu konvertieren, werden wir...

Read more

Die Logic Apps-Plattform von Microsoft ermöglicht...

Read more

Du bist neugierig auf aktuelle KI-Technologien und...

Read more

Am 27.09. ab 12.30h starten die vierten QUIBIQ...

Read more

"Das Beste von SAP und Microsoft nutzen": auf dem...

Read more

Azure Bicep wird verwendet, um Ressourcen in Azure...

Read more

In einer Welt, die immer digitaler wird, ist es...

Read more

Dieser Artikel beschreibt wie JSON-Dateien anhand...

Read more

Vom 5. bis 7. Juni findet in London wieder die...

Read more

Vom 5. bis 7. Juni findet in London wieder die...

Read more

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.

© QUIBIQ GmbH · Imprint · Data protection