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

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

Accès à la session

Votre application interagit avec une session à l’aide de l’API de gestion du pool de sessions.

Un point de terminaison de gestion de pool suit ce format :

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

Routage des requêtes vers le conteneur d’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 après le point de terminaison de gestion de pool de base est transféré au 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 la session à l’adresse 0.0.0.0:<TARGET_PORT>/api/uploadfile.

Interaction continue

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.

Exemple de requête

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

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 la session n’est pas déjà en cours d’exécution, Azure Container Apps alloue automatiquement une session à partir du pool avant de transférer la requête.

Dans cet exemple, le conteneur de la session reçoit la requête à l’adresse http://0.0.0.0:<INGRESS_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.

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

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.

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.

• Utilisez des identificateurs de session forts et uniques : générez toujours des identificateurs de session longs et complexes pour empêcher les attaques par force brute. Utilisez des algorithmes de chiffrement pour créer des identificateurs difficiles à deviner.

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

• Implémenter des délais d’expiration courts : configurez les identificateurs de session pour qu’ils expirent après une courte période d’inactivité. Cette approche réduit le risque de détournement de sessions une fois qu’un utilisateur a fini d’interagir avec votre application.

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

• 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 les clients des attaques de l’intercepteur.

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

Pour sécuriser entièrement vos sessions, vous pouvez :

• Utiliser l’authentification et l’autorisation Microsoft Entra ID
• Protéger les identificateurs de session

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

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

dotnet add package Azure.Identity

using Azure.Identity;

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

npm install @azure/identity

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;

pip install azure-identity

from azure.identity import DefaultAzureCredential

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

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.

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.

{
  "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>": {}
    }
  }
}

Exploitation forestière

Les journaux de console des conteneurs exécutés dans une session sont disponibles dans l’espace de travail Azure Log Analytics associé à l’environnement Azure Container Apps dans une table nommée AppEnvSessionConsoleLogs_CL.

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