Visão geral das sessões dinâmicas dos Aplicativos de Contêiner do Azure

As sessões dinâmicas dos Aplicativos de Contêiner do Azure fornecem acesso rápido a ambientes seguros em área restrita que são ideais para executar códigos ou aplicativos que exigem forte isolamento de outras cargas de trabalho.

As sessões têm os seguintes atributos:

• Isolamento forte: as sessões são isoladas umas das outras e do ambiente do host. Cada sessão é executada em sua própria área restrita do Hyper-V, fornecendo segurança e isolamento de nível empresarial. Opcionalmente, você pode habilitar o isolamento de rede para aprimorar ainda mais a segurança.

• Acesso simples: as sessões são acessadas por meio de uma API REST. Um identificador exclusivo marca cada sessão. Se uma sessão com um determinado identificador não existir, uma nova sessão será alocada automaticamente.

• Totalmente gerenciada: a plataforma gerencia totalmente o ciclo de vida de uma sessão. As sessões são limpas automaticamente quando não estão mais em uso.

• Inicialização rápida: uma nova sessão é alocada em milissegundos. As start-ups rápidas são obtidas mantendo automaticamente um pool de sessões prontas, mas não alocadas.

• Escalonável: as sessões podem ser executadas em alta escala. Você pode executar centenas ou milhares de sessões simultaneamente.

Tipos de sessão

Os Aplicativos de Contêiner do Azure dão suporte a dois tipos de sessões:

Tipo	Descrição	Modelo de cobrança
Interpretador de códigos	Interpretador de código totalmente gerenciado	Por sessão (consumo)
Contêiner personalizado	Traga seu próprio contêiner	Plano Dedicado de Aplicativos de Contêiner

Interpretador de códigos

As sessões de interpretador de código permitem que você execute o código em uma área restrita pré-instalada com bibliotecas populares. Eles são ideais para executar código não confiável, como código fornecido por usuários do aplicativo ou código gerado por um modelo de linguagem grande (LLM). Saiba mais sobre sessões de interpretador de código.

Contêiner personalizado

As sessões de contêiner personalizadas permitem que você execute suas próprias imagens de contêiner em áreas restritas seguras e isoladas. Você pode usá-los para executar um interpretador de código personalizado para um idioma que não tem suporte pronto ou para executar cargas de trabalho que exigem isolamento forte. Saiba mais sobre sessões de contêineres personalizadas.

Conceitos

Os principais conceitos nas sessões dinâmicas dos Aplicativos de Contêiner do Azure são pools de sessão e sessões.

Pools de sessão

Para fornecer tempos de alocação de sessão de sub-segundo, os Aplicativos de Contêiner do Azure mantêm um pool de sessões prontas, mas não alocadas. Quando você envia uma solicitação para uma nova sessão, a plataforma aloca uma sessão do pool para você. À medida que as sessões são alocadas, a plataforma reabastece automaticamente o pool para manter um número constante de sessões prontas.

Você pode configurar pools para definir o número máximo de sessões que podem ser alocadas simultaneamente por meio da propriedade maxConcurrentSessions. Você pode definir a duração da espera da última solicitação antes que uma sessão seja excluída da propriedade cooldownPeriodInSeconds. Para sessões de contêiner personalizadas, você também pode especificar a imagem de contêiner e as configurações a serem usadas para as sessões no pool, incluindo o número de sessões de destino para se manter pronto no pool por meio de readySessionInstances.

Sessões

Uma sessão é um ambiente em área restrita que executa seu código ou aplicativo. Cada sessão é isolada de outras sessões e do ambiente do host com uma área restrita do Hyper-V. Opcionalmente, você pode habilitar o isolamento de rede para aprimorar ainda mais a segurança.

Você interage com sessões em um pool de sessões enviando solicitações HTTP. Cada pool de sessões tem um ponto de extremidade de gerenciamento de pool exclusivo.

Para sessões de interpretador de código, você também pode usar uma integração com uma estrutura LLM.

Identificadores de sessão

Para enviar uma solicitação HTTP para uma sessão, você deve fornecer um identificador de sessão na solicitação. Você passa o identificador de sessão em um parâmetro de consulta nomeado identifier na URL ao fazer uma solicitação para uma sessão.

• Se já existir uma sessão com o identificador, a solicitação será enviada para a sessão existente.
• Se uma sessão com o identificador não existir, uma nova sessão será alocada automaticamente antes que a solicitação seja enviada a ela.

Formato do identificador

O identificador de sessão é uma cadeia de caracteres de forma livre, o que significa que você pode defini-la de qualquer maneira que atenda às necessidades do aplicativo.

O identificador de sessão é uma cadeia de caracteres que você define que é exclusiva dentro do pool de sessão. Se você estiver criando um aplicativo Web, poderá usar a ID do usuário como o identificador de sessão. Se você estiver criando um chatbot, poderá usar a ID da conversa.

O identificador deve ser uma cadeia de caracteres de 4 a 128 caracteres e pode conter apenas caracteres alfanuméricos e caracteres especiais desta lista: |, -, &, ^, %,$, #, (, ), {, }, [, ], ;, < e >.

Proteger identificadores de sessão

O identificador de sessão é as informações confidenciais que você deve gerenciar com segurança. Seu aplicativo precisa garantir que cada usuário ou locatário tenha acesso apenas a suas próprias sessões.

As estratégias específicas que impedem o uso indevido de identificadores de sessão diferem conforme o design e a arquitetura do seu aplicativo. No entanto, seu aplicativo deve sempre ter controle total sobre a criação e o uso de identificadores de sessão para que um usuário mal-intencionado não consiga acessar a sessão de outro usuário.

As estratégias de exemplo incluem:

• Uma sessão por usuário: caso o aplicativo use uma sessão por usuário, cada usuário deve ser autenticado com segurança, e seu aplicativo deve usar um identificador de sessão exclusivo para cada usuário conectado.
• Uma sessão por conversa de agente: caso o aplicativo use uma sessão por conversa de agente de IA, garanta que o aplicativo use um identificador de sessão exclusivo para cada conversa que não possa ser modificado pelo usuário final.

Importante

A falha na proteção do acesso às sessões pode resultar no uso indevido ou no acesso não autorizado aos dados armazenados nas sessões dos usuários.

Autenticação e autorização

Quando você envia solicitações para uma sessão usando a API de gerenciamento de pool, a autenticação é feita usando tokens do Microsoft Entra (antigo Azure Active Directory). Somente os tokens do Microsoft Entra de uma identidade pertencente à função Executor de Sessão dos Aplicativos de Contêiner do Azure no pool de sessões estão autorizados a chamar a API de gerenciamento de pool.

Para atribuir a função a uma identidade, use o seguinte comando da CLI do Azure:

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

Se você estiver usando uma integração de estrutura LLM, a estrutura manipulará a geração e o gerenciamento de tokens para você. Verifique se o aplicativo está configurado com uma identidade gerenciada com as atribuições de função necessárias no pool de sessão.

Se você estiver usando diretamente os pontos de extremidade da API de gerenciamento do pool, deverá gerar um token e incluí-lo no cabeçalho Authorization de suas solicitações HTTP. Além das atribuições de função mencionadas anteriormente, o token precisa conter uma declaração de audiência (aud) com o valor https://dynamicsessions.io.

CLI do Azure

Para gerar um token usando a CLI do Azure, execute o seguinte comando:

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

C#

No C#, você pode usar a biblioteca Azure.Identity para gerar um token. Para instalar a biblioteca:

dotnet add package Azure.Identity

Em seguida, use o seguinte código para gerar um token:

using Azure.Identity;

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

JavaScript

No JavaScript, você pode usar a biblioteca @azure/identity para gerar um token. Para instalar a biblioteca:

npm install @azure/identity

Em seguida, use o seguinte código para gerar um 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

No Python, você pode usar a biblioteca azure-identity para gerar um token. Para instalar a biblioteca:

pip install azure-identity

Em seguida, use o seguinte código para gerar um token:

from azure.identity import DefaultAzureCredential

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

Importante

Um token válido pode ser usado para criar e acessar qualquer sessão no pool. Mantenha seus tokens seguros e não os compartilhe com partes não confiáveis. Os usuários finais devem acessar sessões por meio de seu aplicativo, não diretamente. Elas nunca devem ter acesso aos tokens usados para autenticar as solicitações no pool de sessões.

Ciclo de vida

O runtime dos Aplicativos de Contêiner gerencia automaticamente o ciclo de vida de cada sessão em um pool de sessões.

• Pendente: quando uma sessão está sendo iniciada, ela está no estado pendente. O tempo que uma sessão passa no estado pendente depende da imagem do contêiner e das configurações especificadas para o pool de sessões. Uma sessão pendente não é adicionada ao pool de sessões prontas.

• Pronto: quando uma sessão terminar de ser iniciada e estiver pronta, ela será adicionada ao pool. A sessão está disponível nesse estado para alocação. Para sessões de contêiner personalizadas, você pode especificar o número de destino de sessões prontas para manter no pool. Aumente esse número se as sessões forem alocadas mais rapidamente do que o pool está sendo reabastecido.

• Alocado: quando você envia uma solicitação para uma sessão não em execução, o pool fornece uma nova sessão e a coloca em um estado alocado. As solicitações subsequentes com o mesmo identificador de sessão são roteada para a mesma sessão.

• Excluindo: quando uma sessão para de receber solicitações durante o tempo definido pela configuração cooldownPeriodInSeconds, a sessão e sua área restrita do Hyper-V são excluídas de forma completa e segura.

Segurança

As sessões dinâmicas dos Aplicativos de Contêiner do Azure são criadas para executar aplicativos e códigos não confiáveis em um ambiente seguro e isolado. Embora as sessões sejam isoladas umas das outras, qualquer coisa dentro de uma única sessão, incluindo arquivos e variáveis de ambiente, é acessível pelos usuários da sessão. Você só deve configurar ou carregar dados confidenciais em uma sessão se confiar nos usuários da sessão.

Por padrão, as sessões são impedidas de fazer solicitações de rede de saída. Você pode controlar o acesso à rede definindo as configurações de status de rede no pool de sessões.

Além disso, siga as diretrizes na seção de autenticação e autorização para garantir que somente usuários autorizados possam acessar as sessões e na seção de proteção de identificadores de sessão para garantir que os identificadores de sessão estejam seguros.

Limitações de visualização

As seguintes limitações se aplicam a sessões dinâmicas:

• Está disponível nas seguintes regiões:

  Region	Interpretador de códigos	Contêiner personalizado
  Leste da Austrália	✔	✔
  EUA Central EUAP	✔	✔
  Leste dos EUA 2 EUAP	✔	✔
  Leste dos EUA	✔	✔
  Leste da Ásia	✔	✔
  Centro-Oeste da Alemanha	✔	✔
  Norte da Itália	✔	✔
  Centro-Norte dos EUA	✔	-
  Polônia Central	✔	✔
  Norte da Suíça	✔	✔
  Centro-Oeste dos EUA	✔	✔
  Oeste dos EUA 2	✔	✔

Próximas etapas

Sessões de interpretador de código