Utiliser des sessions dynamiques dans Azure Container Apps

Les sessions dynamiques Azure Container Apps offrent des contextes isolés et sécurisés lorsque vous devez exécuter du code ou des applications séparément d’autres charges de travail. Les sessions s’exécutent à l’intérieur d’un pool de sessions qui fournit un accès immédiat aux sessions nouvelles et existantes. Ces sessions sont idéales pour les scénarios où les entrées générées par l’utilisateur doivent être traitées de manière contrôlée ou lors de l’intégration de services tiers qui nécessitent l’exécution de code dans un environnement isolé. Vous n’avez pas besoin de déployer une ressource d’application conteneur pour utiliser des sessions dynamiques, créer un pool de sessions et appeler son API de gestion.

Cet article explique comment gérer et interagir avec des sessions dynamiques.

Point de terminaison de gestion et routage

Votre application interagit avec une session à l’aide de l’API de gestion du pool de sessions. Pour obtenir une vue d’ensemble conceptuelle de la façon dont les requêtes sont routées, consultez les concepts clés.

Pour obtenir le point de terminaison de gestion du pool de sessions, consultez le point de terminaison de gestion des pools de sessions.

https://<SESSION_POOL_NAME>.<ENVIRONMENT_ID>.<REGION>.azurecontainerapps.io

Pour plus d’informations sur la gestion des pools de sessions, consultez le point de terminaison de gestion des pools de sessions.

Authentification et autorisation de l’API de gestion

Toutes les demandes adressées à l’API de gestion du pool de sessions nécessitent une authentification (AuthN) avec un jeton Microsoft Entra et une autorisation (AuthZ) via le rôle Exécuteur de session Azure ContainerApps sur le pool de sessions. Pour plus d’informations et d’exemples, consultez Authentification et autorisation.

Envoyer des demandes à une session

Pour envoyer une demande dans le conteneur d’une session, vous utilisez le point de terminaison de gestion comme racine de votre requête. Tout ce qui se trouve dans le chemin suivant le point de terminaison de gestion du pool de base est transféré vers le conteneur de la session.

Par exemple, si vous effectuez un appel à <POOL_MANAGEMENT_ENDPOINT>/api/uploadfile, la requête est routée vers le conteneur de session sur son port cible à l’adresse <TARGET_PORT>/api/uploadfile.

Exemple de requête

L’exemple suivant montre comment envoyer une demande à une session à l’aide de l’ID d’un utilisateur comme identificateur de session unique.

Avant d’envoyer la demande, remplacez les espaces réservés entre crochets <> par les valeurs propres à votre demande.

POST <POOL_MANAGEMENT_ENDPOINT>/<API_PATH_EXPOSED_BY_CONTAINER>?identifier=<USER_ID>
Authorization: Bearer <TOKEN>
{
  "command": "echo 'Hello, world!'"
}

Cette requête est transférée au conteneur de la session avec l’identificateur de l’ID de l’utilisateur.

Si aucune session n’existe pour l’identificateur donné, Azure Container Apps alloue automatiquement un du pool avant de transférer la requête.

Dans cet exemple, le conteneur de la session reçoit la requête sur le port cible à l’adresse <TARGET_PORT>/<API_PATH_EXPOSED_BY_CONTAINER>.

Identificateurs

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 chaîne de requête nommé identifier dans l’URL lorsque vous effectuez une requête à 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.

Le diagramme suivant montre comment un pool de sessions achemine les demandes vers des sessions existantes ou alloue une nouvelle session si nécessaire.

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 >.

Cycle de vie de session en pratique

Lorsque vous continuez à passer des appels à la même session, la session reste allouée dans le pool. Une fois qu’il n’y a aucune demande à la session après l’expiration de la période de refroidissement, la session est automatiquement détruite.

Sécurité

Modèle de sécurité

Les sessions dynamiques sont créées pour exécuter du code et des applications non approuvés 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.

Configurez ou chargez uniquement des données sensibles dans une session si vous faites confiance aux utilisateurs de la session.

Accès réseau

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.

Meilleures pratiques

• Identificateurs sécurisés : utilisez des identificateurs de session sécurisés à tout moment. Générez des identificateurs de session à l’aide de méthodes de chiffrement pour garantir des valeurs uniques et imprévisibles. Évitez d’utiliser des ID séquentiels qui pourraient être deviner par un attaquant.
• Utilisez HTTPS : utilisez toujours HTTPS pour chiffrer les données en transit. Cela protège les identificateurs de session et toutes les données sensibles échangées entre le client et le serveur contre l’interception.
• Limitez la durée de vie de la session : implémentez des délais d’expiration pour les sessions. Par exemple, autorisez un maximum de 15 minutes d’inactivité avant l’arrêt automatique de la session. Cela permet d’atténuer les risques en raison d’un appareil perdu ou sans assistance.
• Limiter la visibilité de session : définissez des contrôles d’accès stricts pour vous assurer que les identificateurs de session ne sont visibles que par le pool de sessions. Évitez d’exposer des ID de session dans des URL ou des logs.
• Changer régulièrement les informations d’identification de session : vérifiez et mettez à jour périodiquement les informations d’identification associées à vos sessions. La rotation réduit le risque d’accès non autorisé.

Conseils supplémentaires pour les sessions de conteneur personnalisées

• Utilisez des protocoles de transmission sécurisés : utilisez toujours HTTPS pour chiffrer les données en transit, y compris les identificateurs de session. Cette approche protège contre les attaques de l'homme du milieu.

• Surveiller l’activité de session : implémentez la journalisation et la surveillance pour suivre les activités de session. Utilisez ces journaux pour identifier des modèles inhabituels ou des violations de sécurité potentielles.

• Valider l’entrée utilisateur : traitez toutes les entrées utilisateur comme dangereuses. Utilisez les techniques de validation d’entrée et d’assainissement pour vous protéger contre les attaques par injection et garantir que seules les données approuvées sont traitées.

Authentification et autorisation

Lorsque vous envoyez des demandes à une session à l’aide de l’API de gestion de pool, l’authentification est gérée à l’aide de jetons Microsoft Entra. Seuls les jetons Microsoft Entra d’une identité appartenant au rôle Azure ContainerApps Session Executor dans le pool de sessions sont autorisés à appeler l’API de gestion du 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 intégration de l’infrastructure LLM (Large Language Model), 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. Outre les attributions de rôles 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 est 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 ne doivent jamais avoir un accès direct aux jetons. Mettent uniquement les jetons à la disposition de l’application, et jamais aux utilisateurs finaux.

Protéger les 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

L’échec de la 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.

Utiliser l’identité managée

Une identité managée à partir de l’ID Microsoft Entra permet à vos pools de sessions de conteneur et à leurs sessions d’accéder à d’autres ressources protégées par Microsoft Entra. Les identités gérées attribuées par le système et attribuées par l'utilisateur sont prises en charge dans un pool de sessions.

Pour plus d’informations sur les identités managées dans Microsoft Entra ID, consultez Identités managées pour les ressources Azure.

Il existe deux façons d’utiliser des identités managées avec des pools de sessions de conteneur personnalisés :

• Authentification par extraction d’images : utilisez l’identité managée pour vous authentifier auprès du registre de conteneurs pour extraire l’image conteneur.

• Accès aux ressources : utilisez l’identité managée du pool de sessions dans une session pour accéder à d’autres ressources protégées Microsoft Entra. En raison de ses implications en matière de sécurité, cette fonctionnalité est désactivée par défaut.

  Important

  Si vous activez l’accès à l’identité managée dans une session, tout code ou programme en cours d’exécution dans la session peut créer des jetons Microsoft Entra pour l’identité managée du pool. Étant donné que les sessions exécutent généralement du code non approuvé, utilisez cette fonctionnalité avec une prudence extrême.

Azure CLI

Pour activer l’identité managée pour un pool de sessions de conteneur personnalisé, utilisez Azure Resource Manager.

Azure Resource Manager

Pour activer l’identité managée pour un pool de sessions de conteneur personnalisé, vous ajoutez une identity propriété à la ressource du pool de sessions.

La propriété identity doit avoir une propriété type avec la valeur SystemAssigned ou UserAssigned. Pour plus d’informations sur la configuration de cette propriété, consultez Configurer des identités managées.

L’exemple suivant montre un extrait de modèle ARM qui active une identité affectée par l’utilisateur pour un pool de sessions conteneur personnalisé et l’utilise pour l’authentification par extraction d’images.

Avant d’envoyer la demande, remplacez les espaces réservés entre crochets <> par les valeurs appropriées pour votre pool de sessions et l’identificateur de session.

{
  "type": "Microsoft.App/sessionPools",
  "apiVersion": "2024-08-02-preview",
  "name": "my-session-pool",
  "location": "westus2",
  "properties": {
    "environmentId": "/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.ContainerApps/environments/<ENVIRONMENT_NAME>",
    "poolManagementType": "Dynamic",
    "containerType": "CustomContainer",
    "scaleConfiguration": {
      "maxConcurrentSessions": 10,
      "readySessionInstances": 5
    },
    "dynamicPoolConfiguration": {
      "executionType": "Timed",
      "cooldownPeriodInSeconds": 600
    },
    "customContainerTemplate": {
      "registryCredentials": {
          "server": "myregistry.azurecr.io",
          "identity": "<IDENTITY_RESOURCE_ID>"
      },
      "containers": [
        {
          "image": "myregistry.azurecr.io/my-container-image:1.0",
          "name": "mycontainer",
          "resources": {
            "cpu": 0.25,
            "memory": "0.5Gi"
          },
          "command": [
            "/bin/sh"
          ],
          "args": [
            "-c",
            "while true; do echo hello; sleep 10;done"
          ],
          "env": [
            {
              "name": "key1",
              "value": "value1"
            },
            {
              "name": "key2",
              "value": "value2"
            }
          ]
        }
      ],
      "ingress": {
        "targetPort": 80
      }
    },
    "sessionNetworkConfiguration": {
      "status": "EgressEnabled"
    },
    "managedIdentitySettings": [
      {
        "identity": "<IDENTITY_RESOURCE_ID>",
        "lifecycle": "None"
      }
    ]
  },
  "identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "<IDENTITY_RESOURCE_ID>": {}
    }
  }
}

Ce modèle contient les paramètres suivants pour l’identité managée :

Paramètre	Valeur	Descriptif
customContainerTemplate.registryCredentials.identity	<IDENTITY_RESOURCE_ID>	ID de ressource de l’identité managée à utiliser pour l’authentification par extraction d’images.
managedIdentitySettings.identity	<IDENTITY_RESOURCE_ID>	ID de ressource de l’identité managée à utiliser dans la session.
managedIdentitySettings.lifecycle	None	Cycle de vie de la session où l’identité managée est disponible. - None (par défaut) : la session ne peut pas accéder à l’identité. Ce paramètre est utilisé uniquement pour l’extraction d’images. - Main : en plus de la récupération d’images, la session principale peut également accéder à l’identité. À utiliser avec précaution.

Exploitation forestière

Les sessions dynamiques des Azure Container Apps s’intègrent à Azure Monitor et à Log Analytics pour collecter les journaux émis pendant l’exécution des sessions. Les étapes de configuration sont les mêmes pour l’interpréteur de code et les pools de sessions de conteneur personnalisées, mais les catégories de journaux disponibles diffèrent par type de session. Les métriques retournées par le biais d’en-têtes de réponse d’API ne sont pas écrites dans Log Analytics.

Différences de journalisation par type de session

Utilisez les instructions suivantes pour comparer le comportement de journalisation et accéder aux détails correspondant à votre type de session :

• Sessions d’interpréteur de code : les sorties sont retournées à partir de l’exécution (y compris stdout et stderr), mais les tables Log Analytics AppEnvSession ne sont pas émises. Consultez la journalisation des sessions de l’interpréteur de code.
• Sessions de conteneur personnalisées : les tables Log Analytics AppEnvSession sont émises lorsque votre conteneur écrit dans stdout ou stderr, et les journaux de la plateforme sont disponibles pour le cycle de vie et les événements du pool. Consultez la journalisation des sessions de conteneur personnalisées.
• Common : Les métriques retournées via les en-têtes de réponse d’API ne sont pas écrites dans Log Analytics.

Pour obtenir la liste complète des catégories de sessions prises en charge sur la ressource d’environnement (Microsoft.App/managedEnvironments), consultez les journaux pris en charge pour Microsoft.App/managedEnvironments.

Contenu connexe

• Types de session : Découvrez les différents types de sessions dynamiques :

  • Sessions d’interpréteur de code
  • Sessions de conteneur personnalisées

• Tutoriels : Collaborez directement avec l’API REST ou via un agent LLM :

  • Utilisez un agent LLM :
    • AutoGen
    • LangChain
    • LlamaIndex
    • Noyau sémantique
  • Utiliser l’API REST
    • Interpréteur de code JavaScript