Общие сведения о динамических сеансах приложений контейнеров Azure

Динамические сеансы контейнеров приложений Azure обеспечивают быстрый доступ к защищенным средам-песочницам, которые идеально подходят для выполнения кода или приложений, требующих строгой изоляции от других рабочих нагрузок.

Сеансы имеют следующие атрибуты:

• Строгой изоляции: сеансы изолированы друг от друга и от среды узла. Каждый сеанс выполняется в собственной песочнице Hyper-V, обеспечивая безопасность и изоляцию корпоративного уровня. При необходимости можно включить сетевую изоляцию для дальнейшего повышения безопасности.

• Простой доступ. Доступ к сеансам можно получить через REST API. Уникальный идентификатор помечает каждый сеанс. Если сеанс с заданным идентификатором не существует, новый сеанс автоматически выделяется.

• Полностью управляемый: платформа полностью управляет жизненным циклом сеанса. Сеансы автоматически очищаются, когда больше не используется.

• Быстрый запуск: новый сеанс выделяется в миллисекундах. Быстрые запуски обеспечиваются автоматически путем автоматического обслуживания пула готовых, но нераспределенных сеансов.

• Масштабируемый: сеансы могут выполняться в большом масштабе. Одновременно можно выполнять сотни или тысячи сеансов.

Типы докладов

Приложения контейнеров Azure поддерживают два типа сеансов:

Тип	Описание	Модель выставления счетов
Интерпретатор кода	Полностью управляемый интерпретатор кода	На сеанс (потребление)
Пользовательский контейнер	Использование собственного контейнера	Выделенный план контейнерных приложений

Интерпретатор кода

Сеансы интерпретатора кода позволяют запускать код в песочнице, предварительно установленной с помощью популярных библиотек. Они идеально подходят для запуска ненадежного кода, например кода, предоставленного пользователями приложения или кода, созданного большой языковой моделью (LLM). Дополнительные сведения о сеансах интерпретатора кода.

Пользовательский контейнер

Пользовательские сеансы контейнеров позволяют запускать собственные образы контейнеров в безопасных изолированных песочницах. Их можно использовать для запуска пользовательского интерпретатора кода для языка, который не поддерживается из поля, или для выполнения рабочих нагрузок, требующих строгой изоляции. Дополнительные сведения о пользовательских сеансах контейнеров.

Основные понятия

Ключевыми понятиями в динамических сеансах контейнерных приложений Azure являются пулы сеансов и сеансы.

Пулы сеансов

Чтобы обеспечить время выделения сеансов под секундой, приложения контейнеров Azure поддерживают пул готовых, но нераспределенных сеансов. При отправке запроса на новый сеанс платформа выделяет сеанс из пула. По мере выделения сеансов платформа автоматически пополняет пул для поддержания постоянного количества готовых сеансов.

Пулы можно настроить, чтобы задать максимальное количество сеансов, которые можно выделить одновременно с помощью maxConcurrentSessions свойства. Вы можете задать длительность ожидания из последнего запроса перед удалением свойства сеанса cooldownPeriodInSeconds . Для пользовательских сеансов контейнеров можно также указать образ контейнера и параметры, которые будут использоваться для сеансов в пуле, включая целевое количество сеансов, которые будут готовы к работе в пуле.readySessionInstances

Сеансы

Сеанс — это изолированная среда, которая запускает код или приложение. Каждый сеанс изолирован от других сеансов и от среды узла с песочницей Hyper-V . При необходимости можно включить сетевую изоляцию для дальнейшего повышения безопасности.

Вы взаимодействуете с сеансами в пуле сеансов, отправляя HTTP-запросы. Каждый пул сеансов имеет уникальную конечную точку управления пулом.

Для сеансов интерпретатора кода можно также использовать интеграцию с платформой LLM.

Идентификаторы сеанса

Чтобы отправить HTTP-запрос в сеанс, необходимо указать идентификатор сеанса в запросе. Идентификатор сеанса передается в параметре запроса с именем identifier в URL-адресе при выполнении запроса к сеансу.

• Если сеанс с идентификатором уже существует, запрос отправляется в существующий сеанс.
• Если сеанс с идентификатором не существует, новый сеанс автоматически выделяется перед отправкой запроса.

Формат идентификатора

Идентификатор сеанса — это строка свободной формы, что означает, что ее можно определить любым способом, который соответствует потребностям вашего приложения.

Идентификатор сеанса — это строка, определяемая в пуле сеансов. При создании веб-приложения можно использовать идентификатор пользователя в качестве идентификатора сеанса. При создании чат-бота можно использовать идентификатор беседы.

Идентификатор должен быть строкой длиной от 4 до 128 символов и может содержать только буквенно-цифровые символы и специальные символы из этого списка: |, -&^%$#(){}[];<>

Защита идентификаторов сеанса

Идентификатор сеанса — это конфиденциальная информация, которую необходимо безопасно управлять. Приложение должно гарантировать, что у каждого пользователя или клиента есть доступ только к собственным сеансам.

Конкретные стратегии, которые препятствуют неправильному использованию идентификаторов сеансов, отличаются в зависимости от структуры и архитектуры приложения. Однако ваше приложение всегда должно иметь полный контроль над созданием и использованием идентификаторов сеанса, чтобы злоумышленник не смог получить доступ к сеансу другого пользователя.

Примеры стратегий включают:

• Один сеанс на пользователя: если приложение использует один сеанс для каждого пользователя, каждый пользователь должен быть безопасно проверен, и приложение должно использовать уникальный идентификатор сеанса для каждого вошедшего в систему пользователя.
• Один сеанс на беседу агента. Если приложение использует один сеанс для беседы агента ИИ, убедитесь, что приложение использует уникальный идентификатор сеанса для каждой беседы, которую не может изменить конечный пользователь.

Внимание

Неспособность защитить доступ к сеансам может привести к неправильному использованию или несанкционированного доступа к данным, хранящимся в сеансах пользователей.

Проверка подлинности и авторизация

При отправке запросов в сеанс с помощью API управления пулом проверка подлинности обрабатывается с помощью токенов Microsoft Entra (ранее — Azure Active Directory). Только маркеры Microsoft Entra из удостоверения, принадлежащего роли исполнителя сеансов Azure ContainerApps в пуле сеансов, разрешены вызывать API управления пулом.

Чтобы назначить роль удостоверению, используйте следующую команду Azure CLI:

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

Если вы используете интеграцию платформы LLM, платформа обрабатывает создание маркеров и управление ими. Убедитесь, что приложение настроено с управляемым удостоверением с необходимыми назначениями ролей в пуле сеансов.

Если вы используете конечные точки API управления пула напрямую, необходимо создать маркер и включить его в Authorization заголовок HTTP-запросов. Помимо упомянутых ранее назначений ролей маркер должен содержать утверждение аудитории (aud) со значением https://dynamicsessions.io.

Azure CLI

Чтобы создать токен с помощью Azure CLI, выполните следующую команду:

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

C#

В C#можно использовать библиотеку Azure.Identity для создания маркера. Сначала установите библиотеку:

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;

JavaScript

В JavaScript можно использовать библиотеку @azure/identity для создания маркера. Сначала установите библиотеку:

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;

Python

В Python можно использовать библиотеку azure-identity для создания маркера. Сначала установите библиотеку:

pip install azure-identity

Затем используйте следующий код для создания маркера:

from azure.identity import DefaultAzureCredential

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

Внимание

Допустимый маркер можно использовать для создания и доступа к любому сеансу в пуле. Обеспечьте безопасность маркеров и не делитесь ими с ненадежными сторонами. Конечные пользователи должны обращаться к сеансам через приложение, а не напрямую. Они никогда не должны иметь доступ к маркерам, используемым для проверки подлинности запросов к пулу сеансов.

Жизненный цикл

Среда выполнения контейнерных приложений автоматически управляет жизненным циклом для каждого сеанса в пуле сеансов.

• Ожидание: когда сеанс запускается, он находится в состоянии ожидания. Время, затрачивается на сеанс в ожидании, зависит от образа контейнера и параметров, заданных для пула сеансов. Ожидающий сеанс не добавляется в пул готовых сеансов.

• Готово: когда сеанс запускается и готов, он добавляется в пул. Сеанс доступен в этом состоянии для выделения. Для пользовательских сеансов контейнеров можно указать целевое число готовых сеансов для хранения в пуле. Увеличьте это число, если сеансы выделяются быстрее, чем пул обновляется.

• Выделено: при отправке запроса в неработающий сеанс пул предоставляет новый сеанс и помещает его в выделенное состояние. Последующие запросы с тем же идентификатором сеанса направляются в тот же сеанс.

• Удаление. Когда сеанс перестанет получать запросы во время, определенное cooldownPeriodInSeconds параметром, сеанс и его песочница Hyper-V полностью и безопасно удаляются.

Безопасность

Динамические сеансы приложений контейнеров Azure создаются для запуска ненадежного кода и приложений в безопасной и изолированной среде. Хотя сеансы изолированы друг от друга, все, что находится в одном сеансе, включая файлы и переменные среды, доступно пользователям сеанса. Если вы доверяете пользователям сеанса, необходимо настроить или передать конфиденциальные данные.

По умолчанию сеансы не могут выполнять исходящие сетевые запросы. Вы можете управлять доступом к сети, настроив параметры состояния сети в пуле сеансов.

Кроме того, следуйте инструкциям в разделе проверки подлинности и авторизации , чтобы убедиться, что только авторизованные пользователи могут получать доступ к сеансам и в разделе "Идентификаторы сеансов", чтобы обеспечить безопасность идентификаторов сеансов .

Доступность по регионам

Динамические сеансы доступны в следующих регионах:

Область/регион	Интерпретатор кода	Пользовательский контейнер
Восточная Австралия	✔	✔
Центральная часть США (EUAP)	✔	✔
Восточная часть США 2 (EUAP)	✔	✔
Восточная часть США	✔	✔
Восточная Азия	✔	✔
Центрально-Западная Германия	✔	✔
Северная Италия	✔	✔
Центрально-северная часть США	✔	-
Центральная Польша	✔	✔
Северная Швейцария	✔	✔
Центрально-западная часть США	✔	✔
западная часть США 2	✔	✔

Связанный контент

• Типы сеансов: узнайте о различных типах динамических сеансов:

  • Сеансы интерпретатора кода
  • Пользовательские сеансы контейнеров

• Учебники. Работа непосредственно с REST API или с помощью агента LLM:

  • Используйте агент LLM:
    • AutoGen
    • LangChain
    • LlamaIndex
    • Семантическое ядро
  • Использование REST API
    • Интерпретатор кода JavaScript