Dynamische sessies gebruiken in Azure Container Apps

Dynamische sessies van Azure Container Apps bieden geïsoleerde, beveiligde contexten wanneer u code of toepassingen afzonderlijk van andere workloads wilt uitvoeren. Sessies worden uitgevoerd in een sessiegroep die directe toegang biedt tot nieuwe en bestaande sessies. Deze sessies zijn ideaal voor scenario's waarbij door de gebruiker gegenereerde invoer op een gecontroleerde manier moet worden verwerkt of wanneer services van derden worden geïntegreerd waarvoor code in een geïsoleerde omgeving moet worden uitgevoerd.

In dit artikel leest u hoe u dynamische sessies kunt beheren en ermee kunt werken.

Sessietoegang

Uw toepassing communiceert met een sessie met behulp van de beheer-API van de sessiegroep.

Een eindpunt voor poolbeheer volgt deze indeling:

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

Zie het beheereindpunt voor sessiegroepen voor meer informatie over het beheren van sessiegroepen

Aanvragen doorsturen naar de container van een sessie

Als u een aanvraag wilt verzenden naar de container van een sessie, gebruikt u het beheereindpunt als basis voor uw aanvraag. Alles in het pad dat volgt na het beheer-eindpunt van het basispoolbeheer wordt doorgestuurd naar de container van de sessie.

Als u bijvoorbeeld een aanroep doet naar: <POOL_MANAGEMENT_ENDPOINT>/api/uploadfile, wordt de aanvraag doorgestuurd naar de container van de sessie op 0.0.0.0:<TARGET_PORT>/api/uploadfile.

Voortdurende interactie

Terwijl u doorgaat met het maken van oproepen naar dezelfde sessie, blijft de sessie toegewezen in de pool. Zodra er geen aanvragen voor de sessie zijn nadat de afkoelperiode is verstreken, wordt de sessie automatisch vernietigd.

Voorbeeldaanvraag

In het volgende voorbeeld ziet u hoe u een aanvraag verzendt naar een sessie met behulp van de gebruikers-id als de unieke sessie-id.

Voordat u de aanvraag verzendt, vervangt u de tijdelijke aanduidingen tussen de <> vierkante haken door waarden die specifiek zijn voor uw aanvraag.

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

Deze aanvraag wordt doorgestuurd naar de container in de sessie met de identificatiecode van de gebruikers-id.

Als de sessie nog niet wordt uitgevoerd, wijst Azure Container Apps automatisch een sessie toe vanuit de pool voordat de aanvraag wordt doorgestuurd.

In dit voorbeeld ontvangt de container van de sessie de aanvraag op http://0.0.0.0:<INGRESS_PORT>/<API_PATH_EXPOSED_BY_CONTAINER>.

Identificatiemiddelen

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

Veiligheid

Dynamische sessies zijn gebouwd om niet-vertrouwde code en toepassingen uit te voeren in een veilige 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.

Configureer of upload gevoelige gegevens alleen 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.

• Gebruik sterke, unieke sessie-id's: Genereer altijd sessie-id's die lang en complex zijn om beveiligingsaanvallen te voorkomen. Gebruik cryptografische algoritmen om id's te maken die moeilijk te raden zijn.

• Zichtbaarheid van sessie beperken: stel strikte toegangsbeheer in om ervoor te zorgen dat sessie-id's alleen zichtbaar zijn voor de sessiegroep. Vermijd het weergeven van sessie-id's in URL's of logboeken.

• Korte verlooptijden implementeren: configureer sessie-id's om te verlopen na een korte periode van inactiviteit. Deze aanpak minimaliseert het risico dat sessies worden gekaapt nadat een gebruiker klaar is met de interactie met uw toepassing.

• Sessiereferenties regelmatig wijzigen: Bekijk en actualiseer periodiek de referenties die aan uw sessies zijn gekoppeld. Rotatie vermindert het risico op onbevoegde toegang.

• Veilige overdrachtsprotocollen gebruiken: gebruik altijd HTTPS om gegevens tijdens overdracht te versleutelen, inclusief sessie-id's. Deze aanpak beschermt tegen man-in-the-middle-aanvallen.

• Sessieactiviteit bewaken: logboekregistratie en bewaking implementeren om sessieactiviteiten bij te houden. Gebruik deze logboeken om ongebruikelijke patronen of mogelijke beveiligingsschendingen te identificeren.

• Gebruikersinvoer valideren: alle gebruikersinvoer behandelen als gevaarlijk. Gebruik invoervalidatie- en sanitatietechnieken om te beschermen tegen injectieaanvallen en ervoor te zorgen dat alleen vertrouwde gegevens worden verwerkt.

U kunt het volgende doen om uw sessies volledig te beveiligen:

• Verificatie en autorisatie van Microsoft Entra-id gebruiken
• Sessie-id's beveiligen

Authenticatie en autorisatie

Wanneer u aanvragen verzendt naar een sessie met behulp van de poolbeheer-API, wordt verificatie afgehandeld met behulp van Microsoft Entra-tokens. 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 (Large Language Model) 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.

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

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.

Een beheerde identiteit gebruiken

Met een beheerde identiteit van Microsoft Entra ID kunnen uw containersessiegroepen en hun sessies toegang krijgen tot andere met Microsoft Entra beveiligde resources. Zowel door het systeem toegewezen als door de gebruiker toegewezen beheerde identiteiten worden ondersteund in een sessiegroep.

Zie Beheerde identiteiten voor Azure-resources voor meer informatie over beheerde identiteiten in Microsoft Entra ID.

Er zijn twee manieren om beheerde identiteiten te gebruiken met aangepaste containersessiegroepen:

• Authenticatie voor het ophalen van afbeeldingen: gebruik de beheerde identiteit om te authenticeren bij het containerregister om de containerafbeelding op te halen.

• Toegang tot resources: gebruik de beheerde identiteit van de sessiegroep in een sessie voor toegang tot andere met Microsoft Entra beveiligde resources. Vanwege de gevolgen voor de beveiliging is deze functie standaard uitgeschakeld.

  Belangrijk

  Als u toegang tot beheerde identiteit in een sessie inschakelt, kunnen code of programma's die in de sessie worden uitgevoerd, Microsoft Entra-tokens maken voor de beheerde identiteit van de pool. Aangezien sessies doorgaans niet-vertrouwde code uitvoeren, gebruikt u deze functie met extreme voorzichtigheid.

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

Loggen

Consolelogboeken van containers die in een sessie worden uitgevoerd, zijn beschikbaar in de Azure Log Analytics-werkruimte die is gekoppeld aan de Azure Container Apps-omgeving in een tabel met de naam AppEnvSessionConsoleLogs_CL.

Verwante inhoud

• Sessietypen: meer informatie over de verschillende typen dynamische sessies:

  • Code-interpretersessies
  • Aangepaste containersessies

• Zelfstudies: Rechtstreeks werken met de REST API of via een LLM-agent:

  • Gebruik een LLM-agent:
    • AutoGen
    • LangChain
    • LlamaIndex
    • Semantische kernel
  • De REST API gebruiken
    • JavaScript Code-interpreter