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

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

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

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

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

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

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

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

Примечание.

Динамические сеансы приложений контейнеров Azure в настоящее время находятся в предварительной версии.

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

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

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

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

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

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

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

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

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

Пулы сеансов

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

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

Сеансы

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

az role assignment create \
    --role "Contributor" \
    --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 создаются для запуска ненадежного кода и приложений в безопасной и изолированной среде. Хотя сеансы изолированы друг от друга, все, что находится в одном сеансе, включая файлы и переменные среды, доступно пользователям сеанса. Если вы доверяете пользователям сеанса, необходимо настроить или передать конфиденциальные данные.

Ограничения предварительной версии

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

• Он доступен только в следующих регионах:

  Область/регион	Интерпретатор кода	Пользовательский контейнер
  Восточная Азия	✔	✔
  Восточная часть США	✔	✔
  западная часть США 2	✔	✔
  Центрально-северная часть США	✔	-
  Северная Европа	✔	-

• Ведение журнала не поддерживается. Приложение может регистрировать запросы к API управления пулом сеансов и его ответам.

Следующие шаги

Сеансы интерпретатора кода