Overzicht van dynamische sessies in Azure Container Apps

Dynamische sessies in Azure Container Apps bieden snelle toegang tot beveiligde sandboxomgevingen die ideaal zijn voor het uitvoeren van code of toepassingen waarvoor een sterke isolatie van andere workloads is vereist.

Sessies hebben de volgende kenmerken:

• Sterke isolatie: sessies worden van elkaar en van de hostomgeving geïsoleerd. Elke sessie wordt uitgevoerd in een eigen Hyper-V-sandbox en biedt beveiliging en isolatie op bedrijfsniveau. U kunt eventueel netwerkisolatie inschakelen om de beveiliging verder te verbeteren.

• Eenvoudige toegang: sessies worden geopend via een REST API. Een unieke id markeert elke sessie. Als er geen sessie met een bepaalde id bestaat, wordt automatisch een nieuwe sessie toegewezen.

• Volledig beheerd: het platform beheert de levenscyclus van een sessie volledig. Sessies worden automatisch opgeschoond wanneer ze niet meer in gebruik zijn.

• Snel opstarten: er wordt een nieuwe sessie toegewezen in milliseconden. Snelle start-ups worden bereikt door automatisch een pool met kant-en-klare, maar niet-toegewezen sessies te onderhouden.

• Schaalbaar: sessies kunnen op grote schaal worden uitgevoerd. U kunt honderden of duizenden sessies gelijktijdig uitvoeren.

Sessietypen

Azure Container Apps ondersteunt twee typen sessies:

Type	Description	Factureringsmodel
Code-interpreter	Volledig beheerde code-interpreter	Per sessie (verbruik)
Aangepaste container	Bring Your Own Container	Toegewezen abonnement voor Container Apps

Code-interpreter

Met code-interpretersessies kunt u code uitvoeren in een sandbox die vooraf is geïnstalleerd met populaire bibliotheken. Ze zijn ideaal voor het uitvoeren van niet-vertrouwde code, zoals code die wordt geleverd door gebruikers van uw toepassing of code die is gegenereerd door een groot taalmodel (LLM). Meer informatie over code-interpretersessies.

Aangepaste container

Met aangepaste containersessies kunt u uw eigen containerinstallatiekopieën uitvoeren in beveiligde, geïsoleerde sandboxes. U kunt deze gebruiken om een aangepaste code-interpreter uit te voeren voor een taal die niet standaard wordt ondersteund of om workloads uit te voeren waarvoor een sterke isolatie is vereist. Meer informatie over aangepaste containersessies.

Concepten

De belangrijkste concepten in dynamische sessies van Azure Container Apps zijn sessiegroepen en sessies.

Sessiegroepen

Om sub-tweede sessietoewijzingstijden te bieden, onderhoudt Azure Container Apps een pool met kant-en-klare, maar niet-toegewezen sessies. Wanneer u een aanvraag indient bij een nieuwe sessie, wijst het platform een sessie van de pool aan u toe. Wanneer sessies worden toegewezen, vult het platform de pool automatisch aan om een constant aantal kant-en-klare sessies te onderhouden.

U kunt pools configureren om het maximum aantal sessies in te stellen dat gelijktijdig kan worden toegewezen via de maxConcurrentSessions eigenschap. U kunt de wachttijd van de laatste aanvraag instellen voordat een sessie wordt verwijderd.cooldownPeriodInSeconds Voor aangepaste containersessies kunt u ook de containerinstallatiekopieën en -instellingen opgeven die moeten worden gebruikt voor de sessies in de pool, inclusief het doelaantal sessies om gereed te blijven in de pool via readySessionInstances.

Sessies

Een sessie is een sandbox-omgeving waarmee uw code of toepassing wordt uitgevoerd. Elke sessie is geïsoleerd van andere sessies en van de hostomgeving met een Hyper-V-sandbox . U kunt eventueel netwerkisolatie inschakelen om de beveiliging verder te verbeteren.

U communiceert met sessies in een sessiegroep door HTTP-aanvragen te verzenden. Elke sessiegroep heeft een uniek eindpunt voor poolbeheer.

Voor code-interpretersessies kunt u ook een integratie met een LLM-framework gebruiken.

Sessie-id's

Als u een HTTP-aanvraag naar een sessie wilt verzenden, moet u een sessie-id opgeven in de aanvraag. U geeft de sessie-id door in een queryparameter met de naam identifier in de URL wanneer u een aanvraag indient voor een sessie.

• Als er al een sessie met de id bestaat, wordt de aanvraag verzonden naar de bestaande sessie.
• Als er geen sessie met de id bestaat, wordt automatisch een nieuwe sessie toegewezen voordat de aanvraag naar de sessie wordt verzonden.

Id-indeling

De sessie-id is een vrije tekenreeks, wat betekent dat u deze op elke manier kunt definiëren die aansluit bij de behoeften van uw toepassing.

De sessie-id is een tekenreeks die u definieert die uniek is binnen de sessiegroep. Als u een webtoepassing bouwt, kunt u de gebruikers-id als sessie-id gebruiken. Als u een chatbot bouwt, kunt u de gespreks-id gebruiken.

De id moet een tekenreeks van 4 tot 128 tekens lang zijn en mag alleen alfanumerieke tekens en speciale tekens uit deze lijst bevatten: |, , , -^&$%, ()#][{}, ;, en . <>

Sessie-id's beveiligen

De sessie-id is gevoelige informatie die u veilig moet beheren. Uw toepassing moet ervoor zorgen dat elke gebruiker of tenant alleen toegang heeft tot hun eigen sessies.

De specifieke strategieën die misbruik van sessie-id's voorkomen, verschillen afhankelijk van het ontwerp en de architectuur van uw app. Uw app moet echter altijd volledige controle hebben over het maken en gebruiken van sessie-id's, zodat een kwaadwillende gebruiker geen toegang heeft tot de sessie van een andere gebruiker.

Voorbeelden van strategieën zijn:

• Eén sessie per gebruiker: als uw app één sessie per gebruiker gebruikt, moet elke gebruiker veilig worden geverifieerd en moet uw app een unieke sessie-id gebruiken voor elke aangemelde gebruiker.
• Eén sessie per agentgesprek: als uw app één sessie per AI-agentgesprek gebruikt, moet u ervoor zorgen dat uw app een unieke sessie-id gebruikt voor elk gesprek dat niet kan worden gewijzigd door de eindgebruiker.

Belangrijk

Als u de toegang tot sessies niet kunt beveiligen, kan dit leiden tot misbruik of onbevoegde toegang tot gegevens die zijn opgeslagen in de sessies van uw gebruikers.

Verificatie en autorisatie

Wanneer u aanvragen verzendt naar een sessie met behulp van de poolbeheer-API, wordt verificatie afgehandeld met behulp van Microsoft Entra-tokens (voorheen Azure Active Directory). Alleen Microsoft Entra-tokens van een identiteit die deel uitmaakt van de Azure ContainerApps Session Executor-rol in de sessiegroep, zijn gemachtigd om de poolbeheer-API aan te roepen.

Gebruik de volgende Azure CLI-opdracht om de rol toe te wijzen aan een identiteit:

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

Als u een LLM-frameworkintegratie gebruikt, verwerkt het framework het genereren en beheren van tokens voor u. Zorg ervoor dat de toepassing is geconfigureerd met een beheerde identiteit met de benodigde roltoewijzingen in de sessiegroep.

Als u rechtstreeks de beheer-API-eindpunten van de pool gebruikt, moet u een token genereren en opnemen in de Authorization header van uw HTTP-aanvragen. Naast de eerder genoemde roltoewijzingen moet het token een doelgroep (aud) claim met de waarde https://dynamicsessions.iobevatten.

Azure-CLI

Voer de volgende opdracht uit om een token te genereren met behulp van de Azure CLI:

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

C#

In C# kunt u de Azure.Identity bibliotheek gebruiken om een token te genereren. Installeer eerst de bibliotheek:

dotnet add package Azure.Identity

Gebruik vervolgens de volgende code om een token te genereren:

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 kunt u de @azure/identity bibliotheek gebruiken om een token te genereren. Installeer eerst de bibliotheek:

npm install @azure/identity

Gebruik vervolgens de volgende code om een token te genereren:

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 kunt u de azure-identity bibliotheek gebruiken om een token te genereren. Installeer eerst de bibliotheek:

pip install azure-identity

Gebruik vervolgens de volgende code om een token te genereren:

from azure.identity import DefaultAzureCredential

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

Belangrijk

Een geldig token kan worden gebruikt om een sessie in de pool te maken en te openen. Houd uw tokens veilig en deel ze niet met niet-vertrouwde partijen. Eindgebruikers moeten toegang krijgen tot sessies via uw toepassing, niet rechtstreeks. Ze mogen nooit toegang hebben tot de tokens die worden gebruikt voor het verifiëren van aanvragen voor de sessiegroep.

Levenscyclus

De Container Apps-runtime beheert automatisch de levenscyclus voor elke sessie in een sessiegroep.

• In behandeling: Wanneer een sessie wordt gestart, heeft deze de status In behandeling. De hoeveelheid tijd die een sessie in behandeling heeft, is afhankelijk van de containerinstallatiekopieën en instellingen die u opgeeft voor de sessiegroep. Een sessie die in behandeling is, wordt niet toegevoegd aan de pool met gereede sessies.

• Gereed: Wanneer een sessie is gestart en klaar is, wordt deze toegevoegd aan de pool. De sessie is beschikbaar in deze status voor toewijzing. Voor aangepaste containersessies kunt u het doelaantal gereede sessies opgeven dat in de pool moet worden bewaard. Verhoog dit aantal als sessies sneller worden toegewezen dan de pool wordt aangevuld.

• Toegewezen: Wanneer u een aanvraag verzendt naar een niet-actieve sessie, biedt de pool een nieuwe sessie en plaatst deze in een toegewezen status. Volgende aanvragen met dezelfde sessie-id worden doorgestuurd naar dezelfde sessie.

• Verwijderen: wanneer een sessie geen aanvragen meer ontvangt tijdens de tijd die is gedefinieerd door de cooldownPeriodInSeconds instelling, worden de sessie en de Bijbehorende Hyper-V-sandbox volledig en veilig verwijderd.

Beveiliging

Dynamische sessies van Azure Container Apps zijn gebouwd om niet-vertrouwde code en toepassingen uit te voeren in een beveiligde en geïsoleerde omgeving. Hoewel sessies van elkaar zijn geïsoleerd, is alles binnen één sessie, inclusief bestanden en omgevingsvariabelen, toegankelijk voor gebruikers van de sessie. U moet alleen gevoelige gegevens configureren of uploaden naar een sessie als u de gebruikers van de sessie vertrouwt.

Standaard worden sessies voorkomen dat uitgaande netwerkaanvragen worden ingediend. U kunt netwerktoegang beheren door de netwerkstatusinstellingen in de sessiegroep te configureren.

Volg bovendien de richtlijnen in de sectie verificatie en autorisatie om ervoor te zorgen dat alleen geautoriseerde gebruikers toegang hebben tot sessies en in de sectie sessie-id's beveiligen om ervoor te zorgen dat sessie-id's veilig zijn.

Regionale beschikbaarheid

Dynamische sessies zijn beschikbaar in de volgende regio's:

Regio	Code-interpreter	Aangepaste container
Australië - oost	✔	✔
VS - centraal EUAP	✔	✔
VS - oost 2 EUAP	✔	✔
VS - oost	✔	✔
Azië - oost	✔	✔
Duitsland - west-centraal	✔	✔
Italië - noord	✔	✔
VS - noord-centraal	✔	-
Polen - centraal	✔	✔
Zwitserland - noord	✔	✔
VS - west-centraal	✔	✔
VS - west 2	✔	✔

Volgende stappen

Code-interpretersessies