Présentation des sessions dynamiques Azure Container Apps

Les sessions dynamiques Azure Container Apps offrent un accès rapide à des environnements sandbox sécurisés, idéaux pour exécuter du code ou des applications nécessitant une forte isolation des autres charges de travail.

Les sessions ont les attributs suivants :

• Fort isolement : les sessions sont isolées les unes des autres et de l’environnement hôte. Chaque session s’exécute dans son propre bac à sable Hyper-V, fournissant une sécurité et une isolation de niveau entreprise. Si vous le souhaitez, vous pouvez activer l’isolation réseau pour améliorer la sécurité.

• Accès simple : les sessions sont accessibles via une API REST. Un identificateur unique marque chaque session. Si une session avec un identificateur donné n’existe pas, une nouvelle session est automatiquement allouée.

• Entièrement géré : La plateforme gère entièrement le cycle de vie d'une session. Les sessions sont automatiquement nettoyées lorsqu’elles ne sont plus utilisées.

• Démarrage rapide : une nouvelle session est allouée en millisecondes. Les démarrages rapides sont réalisés en conservant automatiquement un pool de sessions prêtes mais non allouées.

• Évolutif : les sessions peuvent s'exécuter à grande échelle. Vous pouvez exécuter des centaines ou des milliers de sessions simultanément.

Remarque

Les sessions dynamiques Azure Container Apps sont actuellement en préversion.

Types de session

Azure Container Apps prend en charge deux types de sessions :

Type	Description	Modèle de facturation
Interpréteur de code	Interpréteur de code entièrement managé	Par session (consommation)
Conteneur personnalisé	Bring your own container	Plan dédié aux applications de conteneur

Interpréteur de code

Les sessions d’interpréteur de code vous permettent d’exécuter du code dans un bac à sable préinstallé avec les bibliothèques populaires. Elles sont idéales pour exécuter du code non approuvé, comme le code fourni par les utilisateurs de votre application ou du code généré par un modèle de langage volumineux (LLM). En savoir plus sur les sessions d'interprétation de code.

Conteneur personnalisé

Les sessions de conteneur personnalisées vous permettent d’exécuter vos propres images conteneur dans des bacs à sable sécurisés isolés. Vous pouvez les utiliser pour exécuter un interpréteur de code personnalisé pour une langue qui n’est pas prise en charge hors de la boîte de dialogue ou pour exécuter des charges de travail nécessitant une isolation forte. En savoir plus sur sessions de conteneur personnalisées.

Concepts

Les concepts clés des sessions dynamiques Azure Container Apps sont les pools de sessions et les sessions.

Pools de sessions

Pour fournir des temps d'allocation de session inférieurs à la seconde, Azure Container Apps gère un pool de sessions prêtes mais non allouées. Lorsque vous soumettez une requête pour une nouvelle session, la plateforme vous alloue une session du pool. À mesure que les sessions sont allouées, la plateforme réapprovisionnera automatiquement le pool pour maintenir un nombre constant de sessions prêtes.

Vous pouvez configurer des pools pour définir le nombre maximum de sessions pouvant être allouées simultanément via la propriété maxConcurrentSessions. Vous pouvez définir la durée d'attente à partir de la dernière demande avant qu'une session ne supprime la propriété cooldownPeriodInSeconds. Pour les sessions de conteneur personnalisées, vous pouvez également spécifier l'image du conteneur et les paramètres à utiliser pour les sessions du pool, y compris le nombre cible de sessions à maintenir prêtes dans le pool via readySessionInstances.

Sessions

Une session est un environnement bac à sable qui exécute votre code ou votre application. Chaque session est isolée des autres sessions et de l’environnement hôte avec un bac à sable Hyper-V. Si vous le souhaitez, vous pouvez activer l’isolation réseau pour améliorer la sécurité.

Vous interagissez avec les sessions d’un pool de sessions en envoyant des requêtes HTTP. Chaque pool de sessions a un point de terminaison de gestion de pool unique.

Pour les sessions d'interprétation de code, vous pouvez également utiliser une intégration avec un framework LLM.

Identificateurs de session

Pour envoyer une requête HTTP à une session, vous devez fournir un identificateur de session dans la requête. Vous transmettez l’identificateur de session dans un paramètre de requête nommé identifier dans l’URL lorsque vous effectuez une demande à une session.

• Si une session avec l’identificateur existe déjà, la requête est envoyée à la session existante.
• Si une session avec l’identificateur n’existe pas, une nouvelle session est automatiquement allouée avant l’envoi de la requête.

Format de l’identificateur

L’identificateur de session est une chaîne de forme libre, ce qui signifie que vous pouvez la définir d’une manière qui convient aux besoins de votre application.

L’identificateur de session est une chaîne que vous définissez qui est unique dans le pool de sessions. Si vous créez une application web, vous pouvez utiliser l’ID de l’utilisateur comme identificateur de session. Si vous créez un chatbot, vous pouvez utiliser l’ID de conversation.

L’identificateur doit être une chaîne de 4 à 128 caractères contenant seulement des caractères alphanumériques et des caractères spéciaux de cette liste : |, -, &, ^, %, $, #, (, ), {, }, [, ], ;, < et >.

Protection des identificateurs de session

L’identificateur de session est des informations sensibles que vous devez gérer en toute sécurité. Votre application doit s’assurer que chaque utilisateur ou tenant a uniquement accès à ses propres sessions.

Les stratégies spécifiques qui empêchent une mauvaise utilisation des identificateurs de session diffèrent selon la conception et l’architecture de votre application. Toutefois, votre application doit toujours avoir un contrôle complet sur la création et l’utilisation des identificateurs de session afin qu’un utilisateur malveillant ne puisse pas accéder à la session d’un autre utilisateur.

Voici quelques exemples de stratégies :

• Une session par utilisateur : si votre application utilise une session par utilisateur, chaque utilisateur doit être authentifié en toute sécurité et votre application doit utiliser un identificateur de session unique pour chaque utilisateur connecté.
• Une session par conversation d’agent : si votre application utilise une session par conversation d’agent IA, assurez-vous que votre application utilise un identificateur de session unique pour chaque conversation, qui ne peut pas être modifié par l’utilisateur final.

Important

La non-sécurisation de l’accès aux sessions peut entraîner une mauvaise utilisation ou un accès non autorisé aux données stockées dans les sessions de vos utilisateurs.

Authentification et autorisation

Lorsque vous envoyez des requêtes à une session à l’aide de l’API de gestion de pool, l’authentification est gérée à l’aide de jetons Microsoft Entra (anciennement Azure Active Directory). Seuls les jetons Microsoft Entra d’une identité appartenant au rôle Exécuteur de session Azure ContainerApps sur le pool de sessions sont autorisés à appeler l’API de gestion de pool.

Pour attribuer le rôle à une identité, utilisez la commande Azure CLI suivante :

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

Si vous utilisez une l’intégration de l’infrastructure LLM, l’infrastructure gère la génération et la gestion des jetons pour vous. Vérifiez que l’application est configurée avec une identité managée dotée des attributions de rôle nécessaires sur le pool de sessions.

Si vous utilisez directement les points de terminaison de l’API de gestion du pool, vous devez générer un jeton et l’inclure dans l’en-tête Authorization de vos requêtes HTTP. En plus des attributions de rôle mentionnées précédemment, le jeton doit contenir une revendication d’audience (aud) avec la valeur https://dynamicsessions.io.

Azure CLI

Pour générer un jeton en utilisant Azure CLI, exécutez la commande suivante :

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

C#

En C#, vous pouvez utiliser la bibliothèque Azure.Identity pour générer un jeton. Commencez par installer la bibliothèque :

dotnet add package Azure.Identity

Utilisez ensuite le code suivant pour générer un jeton :

using Azure.Identity;

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

JavaScript

En JavaScript, vous pouvez utiliser la bibliothèque @azure/identity pour générer un jeton. Commencez par installer la bibliothèque :

npm install @azure/identity

Utilisez ensuite le code suivant pour générer un jeton :

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

En Python, vous pouvez utiliser la bibliothèque azure-identity pour générer un jeton. Commencez par installer la bibliothèque :

pip install azure-identity

Utilisez ensuite le code suivant pour générer un jeton :

from azure.identity import DefaultAzureCredential

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

Important

Un jeton valide peut être utilisé pour créer et accéder à n’importe quelle session dans le pool. Gardez vos jetons dans un endroit sécurisé et ne les partagez pas avec des parties non approuvées. Les utilisateurs finaux doivent accéder aux sessions en utilisant votre application, pas directement. Ils ne doivent jamais avoir accès aux jetons utilisés pour authentifier les requêtes auprès du pool de sessions.

Cycle de vie

Le runtime Container Apps gère automatiquement le cycle de vie de chaque session dans un pool de sessions.

• En attente : lorsqu’une session démarre, elle est dans l’état en attente. La durée pendant laquelle une session passe dans l’état en attente dépend de l’image conteneur et des paramètres que vous spécifiez pour le pool de sessions. Une session en attente n’est pas ajoutée au pool de sessions prêtes.

• Ready : lorsqu’une session est terminée et prête, elle est ajoutée au pool. La session est disponible à cet état pour l’allocation. Pour les sessions de conteneur personnalisées, vous pouvez spécifier le nombre cible de sessions prêtes à conserver dans le pool. Augmentez ce nombre si les sessions sont allouées plus rapidement que le pool est réapprovisionné.

• Alloué : lorsque vous envoyez une requête à une session non en cours d'exécution, le pool fournit une nouvelle session et la place dans un état alloué. Les requêtes suivantes avec le même identificateur de session sont routées vers la même session.

• Suppression : Lorsqu'une session cesse de recevoir des requêtes pendant le temps défini par le paramètre cooldownPeriodInSeconds, la session et son sandbox Hyper-V sont supprimés complètement et de manière sécurisée.

Sécurité

Les sessions dynamiques Azure Container Apps sont conçues pour exécuter du code et des applications non fiables dans un environnement sécurisé et isolé. Bien que les sessions soient isolées les unes des autres, tout ce qui se trouve dans une seule session, y compris les fichiers et les variables d’environnement, est accessible par les utilisateurs de la session. Vous devez configurer ou charger des données sensibles dans une session uniquement si vous approuvez les utilisateurs de la session.

Par défaut, les sessions ne peuvent pas effectuer de requêtes réseau sortantes. Vous pouvez contrôler l’accès réseau en configurant les paramètres d’état du réseau sur le pool de sessions.

En outre, suivez l’aide de la section authentification et autorisation pour vous assurer que seuls les utilisateurs autorisés peuvent accéder aux sessions et dans la section protéger les identificateurs de session pour vous assurer que les identificateurs de session sont sécurisés.

Limitations de la version préliminaire

Les sessions dynamiques Azure Container Apps sont actuellement en préversion. Les restrictions suivantes s’appliquent :

• Elles sont disponibles uniquement dans les régions suivantes :

  Région	Interpréteur de code	Conteneur personnalisé
  Asie Est	✔	✔
  USA Est	✔	✔
  Allemagne Centre-Ouest	✔	✔
  Italie Nord	✔	✔
  Pologne Centre	✔	✔
  Centre-Nord des États-Unis	✔	-
  Europe Nord	✔	✔
  USA Ouest 2	✔	✔

Étapes suivantes

Sessions d’interpréteur de code