Panoramica delle sessioni dinamiche di App contenitore di Azure

Le sessioni dinamiche delle app Contenitore di Azure offrono accesso rapido agli ambienti sandbox sicuri, ideali per l'esecuzione di codice o applicazioni che richiedono un isolamento sicuro da altri carichi di lavoro.

Le sessioni hanno gli attributi seguenti:

• Isolamento sicuro: le sessioni sono isolate l'una dall'altra e dall'ambiente host. Ogni sessione viene eseguita nella propria sandbox Hyper-V, fornendo così sicurezza e isolamento di grado Enterprise. Facoltativamente, è possibile abilitare l'isolamento rete per migliorare ulteriormente la sicurezza.

• Accesso semplice: le sessioni sono accessibili tramite un'API REST. Un identificatore univoco contrassegna ogni sessione. Se non esiste una sessione con un identificatore specificato, ne viene allocata automaticamente una nuova.

• Completamente gestito: la piattaforma gestisce completamente il ciclo di vita di una sessione. Le sessioni vengono pulite automaticamente quando non sono più in uso.

• Avvio rapido: una nuova sessione viene allocata in millisecondi. Gli avvi rapidi si ottengono mantenendo automaticamente un pool di sessioni pronte ma non allocate.

• Scalabile: le sessioni possono essere eseguite su larga scala. È possibile eseguire centinaia o migliaia di sessioni contemporaneamente.

Nota

Le sessioni dinamiche di App contenitore di Azure sono attualmente in anteprima.

Tipi di sessione

App contenitore di Azure supporta due tipi di sessioni:

Tipo	Descrizione	Modello di fatturazione
Interprete del codice	Interprete di codice completamente gestito	Per sessione (consumo)
Contenitore personalizzato	Usare un contenitore personalizzato	Piano dedicato per App contenitore

Interprete del codice

Le sessioni dell'interprete del codice consentono di eseguire il codice in una sandbox preinstallata con librerie comuni. Sono ideali per l'esecuzione di codice non attendibile, ad esempio quello fornito dagli utenti dell'applicazione o quello generato da un modello di linguaggio di grandi dimensioni (LLM). Altre informazioni sulle sessioni dell'interprete di codice.

Contenitore personalizzato

Le sessioni di contenitori personalizzate consentono di eseguire immagini del contenitore personalizzate in sandbox sicure e isolate. È possibile usarli per eseguire un interprete di codice personalizzato per un linguaggio non supportato per impostazione predefinita o per eseguire carichi di lavoro che richiedono un isolamento sicuro. Altre informazioni sulle sessioni di contenitori personalizzate.

Concetti

I concetti chiave nelle sessioni dinamiche di App contenitore di Azure sono pool di sessioni e sessioni.

Pool di sessioni

Per fornire tempi di allocazione di sessioni secondarie al secondo, Appc contenitore di Azure gestisce un pool di sessioni pronte ma non allocate. Quando si invia una richiesta a una nuova sessione, la piattaforma alloca una sessione dal pool. Quando le sessioni vengono allocate, la piattaforma ricostituisce automaticamente il pool per mantenere un numero costante di sessioni pronte.

È possibile configurare i pool per impostare il numero massimo di sessioni che possono essere allocate simultaneamente tramite la proprietà maxConcurrentSessions. È possibile impostare la durata di attesa dell'ultima richiesta prima che una sessione venga eliminata dalla proprietà cooldownPeriodInSeconds. Per le sessioni di contenitori personalizzate, è anche possibile specificare l'immagine e le impostazioni del contenitore da usare per le sessioni nel pool, incluso il numero di sessioni di destinazione da preparare nel pool tramite readySessionInstances.

Sessioni

Una sessione è un ambiente in modalità sandbox che esegue il codice o l'applicazione. Ogni sessione è isolata da altre sessioni e dall'ambiente host con una sandbox Hyper-V. Facoltativamente, è possibile abilitare l'isolamento rete per migliorare ulteriormente la sicurezza.

Identificatori di sessione

Quando si interagisce con le sessioni in un pool, è necessario definire un identificatore di sessione per gestire ogni sessione. L'identificatore di sessione è una stringa in formato libero, ovvero è possibile definirla in qualsiasi modo che sia adatto alle esigenze dell'applicazione. Questo identificatore è un elemento chiave per determinare il comportamento della sessione:

• Riutilizzo delle sessioni esistenti: questa sessione viene riutilizzata se è già presente una sessione in esecuzione che corrisponde all'identificatore.
• Allocazione di nuove sessioni: se nessuna sessione in esecuzione corrisponde all'identificatore, viene allocata automaticamente una nuova sessione dal pool.

L'identificatore di sessione è una stringa definita dall'utente univoca all'interno del pool di sessioni. Se si sta creando un'applicazione Web, è possibile usare l'ID dell'utente. Se si sta creando un chatbot, è possibile usare l'ID conversazione.

L'identificatore deve essere una stringa lunga da 4 a 128 caratteri e può contenere solo caratteri alfanumerici e caratteri speciali da questo elenco: |, -, &, ^, %, $, #, (, ), {, }, [, ], ;, < e >.

Passare l'identificatore di sessione in un parametro di query denominato identifier nell'URL quando si effettua una richiesta a una sessione.

Per le sessioni dell'interprete del codice, è anche possibile usare un'integrazione con un framework LLM. Il framework gestisce automaticamente la generazione e la gestione dei token. Assicurarsi che l'applicazione sia configurata con un'identità gestita con le assegnazioni di ruolo necessarie nel pool di sessioni.

Protezione degli identificatori di sessione

L'identificatore di sessione è costituito da informazioni riservate che richiedono un processo sicuro durante la creazione e la gestione del relativo valore. Per proteggere questo valore, l'applicazione deve assicurarsi che ogni utente o tenant abbia accesso solo alle proprie sessioni.

Le strategie specifiche che impediscono l'uso improprio degli identificatori di sessione variano a seconda della progettazione e dell'architettura dell'app. Tuttavia, l'app deve avere sempre il controllo completo sulla creazione e l'uso di identificatori di sessione in modo che un utente malintenzionato non possa accedere alla sessione di un altro utente.

Esempi di strategie includono:

• Una sessione per utente: se l'app usa una sessione per utente, ogni utente deve essere autenticato in modo sicuro e l'app deve usare un identificatore di sessione univoco per ogni utente connesso.
• Una sessione per conversazione agente: se l'app usa una sessione per ogni conversazione dell'agente di intelligenza artificiale, assicurarsi che l'app usi un identificatore di sessione univoco per ogni conversazione che non possa essere modificato dall'utente finale.

Importante

L'impossibilità di proteggere l'accesso alle sessioni può comportare l'uso improprio o l'accesso non autorizzato ai dati archiviati nelle sessioni degli utenti.

Autenticazione

L'autenticazione viene gestita usando i token di Microsoft Entra (in precedenza Azure Active Directory). I token Microsoft Entra validi vengono generati da un'identità appartenente ai ruoli Esecutore di sessioni Azure ContainerApps e Collaboratore nel pool di sessioni.

Per assegnare i ruoli a un'identità, usare i comandi seguenti dell'interfaccia della riga di comando di Azure:

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>

Se si usa un'integrazione del framework LLM, il framework gestisce automaticamente la generazione e la gestione dei token. Assicurarsi che l'applicazione sia configurata con un'identità gestita con le assegnazioni di ruolo necessarie nel pool di sessioni.

Se si usano direttamente gli endpoint API di gestione del pool, è necessario generare un token e includerlo nell'intestazione Authorization delle richieste HTTP. Oltre alle assegnazioni di ruolo indicate in precedenza, il token deve contenere un'attestazione del gruppo di destinatari (aud) con il valore https://dynamicsessions.io.

Interfaccia della riga di comando di Azure

Per generare un token usando l'interfaccia della riga di comando di Azure, eseguire il comando seguente:

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

C#

In C# è possibile usare la libreria Azure.Identity per generare un token. Come prima cosa, installare la libreria:

dotnet add package Azure.Identity

Quindi, usare il codice seguente per generare un token:

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 è possibile usare la libreria @azure/identity per generare un token. Come prima cosa, installare la libreria:

npm install @azure/identity

Quindi, usare il codice seguente per generare un token:

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 è possibile usare la libreria azure-identity per generare un token. Come prima cosa, installare la libreria:

pip install azure-identity

Quindi, usare il codice seguente per generare un token:

from azure.identity import DefaultAzureCredential

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

Importante

È possibile usare un token valido per creare e accedere a qualsiasi sessione nel pool. Mantenere i token sicuri e non condividerli con parti non attendibili. Gli utenti finali devono accedere alle sessioni tramite l'applicazione, non direttamente.

Ciclo di vita

Il runtime di App contenitore gestisce automaticamente il ciclo di vita per ogni sessione in un pool di sessioni.

• In sospeso: quando si avvia una sessione, si trova nello stato in sospeso. Il tempo trascorso da una sessione nello stato in sospeso dipende dall'immagine del contenitore e dalle impostazioni specificate per il pool di sessioni. Una sessione in sospeso non viene aggiunta al pool di sessioni pronte.

• Pronto: al termine dell'avvio di una sessione, viene aggiunto al pool. La sessione è disponibile in questo stato per l'allocazione. Per le sessioni di contenitori personalizzate, è possibile specificare il numero di sessioni pronte da mantenere nel pool. Aumentare questo numero se le sessioni vengono allocate più velocemente del pool in fase di rifornimento.

• Allocato: quando si invia una richiesta a una sessione non in esecuzione, il pool fornisce una nuova sessione e la inserisce in uno stato allocato. Le richieste successive con lo stesso identificatore di sessione vengono instradate alla stessa sessione.

• Eliminazione: quando una sessione smette di ricevere richieste durante il tempo definito dall'impostazione cooldownPeriodInSeconds, la sessione e la relativa sandbox Hyper-V vengono eliminate completamente e in modo sicuro.

Sicurezza

Le sessioni dinamiche di App contenitore di Azure vengono compilate per eseguire codice e applicazioni non attendibili in un ambiente sicuro e isolato. Mentre le sessioni sono isolate l'una dall'altra, qualsiasi elemento all'interno di una singola sessione, inclusi i file e le variabili di ambiente, è accessibile dagli utenti della sessione. È consigliabile configurare o caricare dati sensibili in una sessione solo se si considerano attendibili gli utenti della sessione.

Limiti dell'anteprima

Le sessioni dinamiche di App contenitore di Azure sono attualmente in anteprima. Si applicano le limitazioni seguenti:

• È disponibile solo nelle regioni seguenti:

  Paese	Interprete del codice	Contenitore personalizzato
  Asia orientale	✔	✔
  Stati Uniti orientali	✔	✔
  Germania centro-occidentale	✔	✔
  Italia settentrionale	✔	✔
  Polonia Centrale	✔	✔
  Stati Uniti centro-settentrionali	✔	-
  Europa settentrionale	✔	✔
  West US 2	✔	✔

• La registrazione non è supportata. L'applicazione può registrare le richieste all'API di gestione del pool di sessioni e alle relative risposte.

Passaggi successivi

Sessioni dell'interprete di codice