Übersicht: Dynamische Azure Container Apps-Sitzungen

Dynamische Azure Container Apps-Sitzungen bieten schnellen Zugriff auf sichere Sandkastenumgebungen, die sich ideal für die Ausführung von Code oder Anwendungen eignen, die eine starke Isolation von anderen Workloads erfordern.

Sitzungen verfügen über die folgenden Attribute:

• Starke Isolation: Sitzungen sind voneinander und von der Hostumgebung isoliert. Jede Sitzung wird in einer eigenen Hyper-V-Sandbox ausgeführt, die Sicherheit und Isolation auf Unternehmensniveau bietet. Optional können Sie die Netzwerkisolation aktivieren, um die Sicherheit weiter zu verbessern.

• Einfacher Zugriff: Auf Sitzungen wird über eine REST-API zugegriffen. Ein eindeutiger Bezeichner (ID) kennzeichnete jede Sitzung. Wenn eine Sitzung mit einem bestimmten Bezeichner nicht vorhanden ist, wird automatisch eine neue Sitzung zugeordnet.

• Vollständig verwaltet: Der Lebenszyklus von Sitzungen wird vollständig von der Plattform verwaltet. Sitzungen werden automatisch bereinigt, wenn sie nicht mehr verwendet werden.

• Schneller Start: Eine neue Sitzung wird innerhalb von Millisekunden zugeordnet. Schnelle Starts werden erreicht, indem automatisch ein Pool von Sitzungen aufrechterhalten wird, die einsatzbereit, aber nicht zugeordnet sind.

• Skalierbar: Sitzungen können in großem Stil ausgeführt werden. Sie können Hunderte oder Tausende von Sitzungen gleichzeitig ausführen.

Hinweis

Dynamische Azure Container Apps-Sitzungen befinden sich derzeit in der Vorschau.

Sitzungstypen

Azure Container Apps unterstützt zwei Sitzungstypen:

Typ	Beschreibung	Abrechnungsmodell
Codeinterpreter	Vollständig verwalteter Codeinterpreter	Pro Sitzung (Verbrauch)
Benutzerdefinierter Container	Bringen Sie Ihren eigenen Container mit	Dedizierter Container Apps-Plan

Codeinterpreter

Codeinterpretersitzungen ermöglichen Ihnen die Ausführung von Code in einer Sandbox, in der beliebte Bibliotheken vorinstalliert sind. Sie eignen sich ideal zum Ausführen von nicht vertrauenswürdigem Code, z. B. Code, der von Benutzern Ihrer Anwendung bereitgestellt oder von einem großen Sprachmodell (Large Language Model, LLM) generiert wird. Erfahren Sie mehr über Codeinterpretersitzungen.

Benutzerdefinierter Container

Benutzerdefinierte Containersitzungen ermöglichen Ihnen das Ausführen Ihrer eigenen Containerimages in sicheren, isolierten Sandboxes. Sie können sie verwenden, um einen benutzerdefinierten Codeinterpreter für eine Sprache auszuführen, die nicht standardmäßig unterstützt wird, oder um Workloads auszuführen, die eine starke Isolation erfordern. Erfahren Sie mehr über benutzerdefinierte Containersitzungen.

Konzepte

Die wichtigsten Konzepte in Zusammenhang mit dynamischen Azure Container Apps-Sitzungen sind Sitzungspools und Sitzungen.

Sitzungspools

Um Sitzungen in weniger als einer Sekunde bereitzustellen, verwaltet Azure Container Apps einen Pool von Sitzungen, die bereit, aber nicht zugeordnet sind. Wenn Sie eine Anforderung an eine neue Sitzung übermitteln, ordnet die Plattform Ihnen eine Sitzung aus dem Pool zu. Wenn Sitzungen zugeordnet werden, füllt die Plattform den Pool automatisch wieder auf, um eine konstante Anzahl von einsatzbereiten Sitzungen aufrechtzuerhalten.

Sie können Pools konfigurieren, um die maximale Anzahl von Sitzungen, die gleichzeitig zugeordnet werden können, über die maxConcurrentSessions-Eigenschaft festzulegen. Mit der cooldownPeriodInSeconds-Eigenschaft können Sie die Wartezeit nach der letzten Anforderung festlegen, bevor eine Sitzung gelöscht wird. Für benutzerdefinierte Containersitzungen können Sie auch das Containerimage und die Einstellungen angeben, die für die Sitzungen im Pool verwendet werden sollen. Unter anderem können Sie über readySessionInstances die Zielanzahl von Sitzungen festlegen, die im Pool bereit gehalten werden sollen.

Sitzungen

Eine Sitzung ist eine Sandkastenumgebung, in der Ihr Code oder Ihre Anwendung ausgeführt wird. Jede Sitzung ist von anderen Sitzungen und von der Hostumgebung mit einer Hyper-V-Sandbox isoliert. Optional können Sie die Netzwerkisolation aktivieren, um die Sicherheit weiter zu verbessern.

Sitzungs-IDs

Wenn Sie mit Sitzungen in einem Pool interagieren, müssen Sie einen Sitzungsbezeichner (Sitzungs-ID) definieren, um die einzelnen Sitzungen zu verwalten. Die Sitzungs-ID ist eine Freiformzeichenfolge, d. h. Sie können je nach den Anforderungen Ihrer Anwendung eine beliebige ID festlegen. Beim Festlegen des Verhaltens der Sitzung ist dieser Bezeichner ist ein wichtiges Element:

• Wiederverwendung vorhandener Sitzungen: Diese Sitzung wird wiederverwendet, wenn bereits eine ausgeführte Sitzung vorhanden ist, die dem Bezeichner entspricht.
• Zuordnung neuer Sitzungen: Wenn keine ausgeführte Sitzung mit dem Bezeichner übereinstimmt, wird automatisch eine neue Sitzung aus dem Pool zugeordnet.

Die Sitzungs-ID ist eine Zeichenfolge, die Sie definieren und die innerhalb des Sitzungspools eindeutig ist. Wenn Sie eine Webanwendung erstellen, können Sie die ID des Benutzers verwenden. Wenn Sie einen Chatbot erstellen, können Sie die Unterhaltungs-ID verwenden.

Die ID muss eine Zeichenfolge sein, die 4 bis 128 Zeichen lang ist. Sie darf nur alphanumerische Zeichen und folgende Sonderzeichen enthalten: |, -, &, ^, %, $, #, (, ), {, }, [, ], ;, < und >.

Sie übergeben die Sitzungs-ID in einem Abfrageparameter namens identifier in der URL, wenn Sie eine Anforderung an eine Sitzung senden.

Für Codeinterpretersitzungen können Sie auch eine Integration in ein LLM-Framework verwenden. Das Framework verarbeitet die Tokengenerierung und -verwaltung für Sie. Stellen Sie sicher, dass die Anwendung mit einer verwalteten Identität konfiguriert ist, die über die erforderlichen Rollenzuweisungen für den Sitzungspool verfügt.

Schützen von Sitzungsbezeichnern

Der Sitzungsbezeichner ist vertrauliche Information, was einen sicheren Prozess erfordert, während Sie seinen Wert erstellen und verwalten. Um diesen Wert zu schützen, muss Ihre Anwendung sicherstellen, dass jeder Benutzer oder Mandant nur Zugriff auf seine eigenen Sitzungen hat.

Die spezifischen Strategien, die den Missbrauch von Sitzungsbezeichnern verhindern, unterscheiden sich je nach Design und Architektur Ihrer App. Ihre App muss jedoch immer die vollständige Kontrolle über die Erstellung und Verwendung von Sitzungs-IDs haben, damit ein böswilliger Benutzer nicht auf die Sitzung eines anderen Benutzers zugreifen kann.

Beispiele für geeignete Strategien umfassen:

• Eine Sitzung pro Benutzer: Wenn Ihre App eine Sitzung pro Benutzer verwendet, muss jeder Benutzer sicher authentifiziert werden, und Ihre App muss für jeden angemeldeten Benutzer einen eindeutigen Sitzungsbezeichner verwenden.
• Eine Sitzung pro Agentunterhaltung: Wenn Ihre App eine Sitzung pro KI-Agent-Unterhaltung verwendet, stellen Sie sicher, dass Ihre App für jede Unterhaltung, die vom Endbenutzer nicht geändert werden kann, einen eindeutigen Sitzungsbezeichner verwendet.

Wichtig

Wenn Sie den Zugriff auf Sitzungen nicht sichern, kann dies zu Missbrauch oder unbefugtem Zugriff auf Daten führen, die in den Sitzungen Ihrer Benutzer gespeichert sind.

Authentifizierung

Die Authentifizierung erfolgt mithilfe von Microsoft Entra ID-Token (früher Azure Active Directory). Gültige Microsoft Entra-Token werden durch eine Identität mit den Rollen Azure ContainerApps-Sitzungs-Executor und Mitwirkender für den Sitzungspool generiert.

Verwenden Sie die folgenden Azure CLI-Befehle, um einer App die Rollen zuzuweisen:

az role assignment create \
    --role "Azure ContainerApps Session Executor" \
    --assignee <PRINCIPAL_ID> \
    --scope <SESSION_POOL_RESOURCE_ID>

az role assignment create \
    --role "Contributor" \
    --assignee <PRINCIPAL_ID> \
    --scope <SESSION_POOL_RESOURCE_ID>

Wenn Sie eine LLM-Frameworkintegration verwenden, verarbeitet das Framework die Tokengenerierung und -verwaltung für Sie. Stellen Sie sicher, dass die Anwendung mit einer verwalteten Identität mit den erforderlichen Rollenzuweisungen im Sitzungspool konfiguriert ist.

Wenn Sie die API-Verwaltungsendpunkte des Pools direkt verwenden, müssen Sie ein Token generieren und in den Authorization-Header Ihrer HTTP-Anforderungen einschließen. Zusätzlich zu den zuvor erwähnten Rollenzuweisungen muss das Token einen Zielgruppenanspruch (aud) mit dem Wert https://dynamicsessions.io enthalten.

Azure-Befehlszeilenschnittstelle

Führen Sie den folgenden Befehl aus, um mit der Azure CLI ein Token zu generieren:

az account get-access-token --resource https://dynamicsessions.io

C#

In C# können Sie die Azure.Identity-Bibliothek verwenden, um ein Token zu generieren. Installieren Sie zunächst die Bibliothek:

dotnet add package Azure.Identity

Verwenden Sie dann den folgenden Code, um ein Token zu generieren:

using Azure.Identity;

var credential = new DefaultAzureCredential();
var token = credential.GetToken(new TokenRequestContext(new[] { "https://dynamicsessions.io/.default" }));
var accessToken = token.Token;

JavaScript

In JavaScript können Sie die @azure/identity-Bibliothek verwenden, um ein Token zu generieren. Installieren Sie zunächst die Bibliothek:

npm install @azure/identity

Verwenden Sie dann den folgenden Code, um ein Token zu generieren:

const { DefaultAzureCredential } = require("@azure/identity");
const { TokenCredential } = require("@azure/core-auth");

const credential = new DefaultAzureCredential();
const token = await credential.getToken("https://dynamicsessions.io/.default");
const accessToken = token.token;

Python

In Python können Sie die azure-identity-Bibliothek verwenden, um ein Token zu generieren. Installieren Sie zunächst die Bibliothek:

pip install azure-identity

Verwenden Sie dann den folgenden Code, um ein Token zu generieren:

from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()
token = credential.get_token("https://dynamicsessions.io/.default")
access_token = token.token

Wichtig

Ein gültiges Token kann verwendet werden, um eine beliebige Sitzung im Pool zu erstellen und auf diese zuzugreifen. Schützen Sie Ihre Token, und teilen Sie sie nicht mit nicht vertrauenswürdigen Parteien. Endbenutzer sollten nicht direkt, sondern über Ihre Anwendung auf Sitzungen zugreifen.

Lebenszyklus

Die Container Apps-Runtime verwaltet automatisch den Lebenszyklus jeder Sitzung in einem Sitzungspool.

• Ausstehend: Wenn eine Sitzung gestartet wird, befindet sie sich im Status „Ausstehend“. Wie lange eine Sitzung im Status „Ausstehend“ verbleibt, hängt vom Containerimage und von den Einstellungen ab, die Sie für den Sitzungspool angeben. Eine ausstehende Sitzung wird nicht zum Pool einsatzbereiter Sitzungen hinzugefügt.

• Bereit: Wenn eine Sitzung gestartet wurde und bereit ist, wird sie dem Pool hinzugefügt. Die Sitzung ist in diesem Status zur Zuordnung verfügbar. Bei benutzerdefinierten Containersitzungen können Sie die Zielanzahl einsatzbereiter Sitzungen angeben, die im Pool beibehalten werden sollen. Erhöhen Sie diese Anzahl, wenn Sitzungen schneller zugeordnet werden, als der Pool aufgefüllt wird.

• Zugeordnet: Wenn Sie eine Anforderung an eine nicht ausgeführte Sitzung senden, stellt der Pool eine neue Sitzung bereit und versetzt sie in den Status „Zugeordnet“. Nachfolgende Anforderungen mit derselben Sitzungs-ID werden an dieselbe Sitzung weitergeleitet.

• Löschen: Wenn eine Sitzung den Empfang von Anforderungen während des Zeitraums beendet, der mit der Einstellung cooldownPeriodInSeconds festgelegt wurde, werden die Sitzung und die zugehörige Hyper-V-Sandbox vollständig und sicher gelöscht.

Sicherheit

Dynamische Azure Container Apps-Sitzungen sind dafür konzipiert, nicht vertrauenswürdige Codes und Anwendungen in einer sicheren und isolierten Umgebung auszuführen. Obwohl Sitzungen voneinander isoliert sind, sind alle Daten innerhalb einer einzelnen Sitzung (einschließlich Dateien und Umgebungsvariablen) für Benutzer der Sitzung zugänglich. Sie sollten vertrauliche Daten nur dann in einer Sitzung konfigurieren oder hochladen, wenn Sie den Benutzern der Sitzung vertrauen.

Einschränkungen der Vorschau

Dynamische Azure Container Apps-Sitzungen befinden sich derzeit in der Vorschau. Es gelten die folgenden Einschränkungen:

• Die Vorschau ist nur in folgenden Regionen verfügbar:

  Region	Codeinterpreter	Benutzerdefinierter Container
  Asien, Osten	✔	✔
  East US	✔	✔
  Deutschland, Westen-Mitte	✔	✔
  Italien, Norden	✔	✔
  Polen, Mitte	✔	✔
  USA Nord Mitte	✔	-
  Nordeuropa	✔	✔
  USA, Westen 2	✔	✔

• Protokollierung wird nicht unterstützt. Ihre Anwendung kann Anforderungen an die Sitzungspoolverwaltungs-API und deren Antworten protokollieren.

Nächste Schritte

Codeinterpretersitzungen