Azure Container Apps で動的セッションを使用する

Azure Container Apps の動的 セッション では、他のワークロードとは別にコードまたはアプリケーションを実行する必要がある場合に、分離されたセキュリティで保護されたコンテキストが提供されます。 セッションは、新規および既存のセッションにすぐにアクセスできる セッション プール 内で実行されます。 これらのセッションは、ユーザーが生成した入力を制御された方法で処理する必要があるシナリオや、分離された環境でコードを実行する必要があるサードパーティのサービスを統合する場合に最適です。

この記事では、動的セッションを管理および操作する方法について説明します。

セッション アクセス

アプリケーションは、セッション プールの管理 API を使ってセッションと対話します。

プール管理エンドポイントは、次の形式に従います。

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

セッション プールの管理の詳細については、「セッション プール管理エンドポイント」を参照してください。

セッションのコンテナーへの要求の転送

セッションのコンテナーに要求を送信するには、要求のルートとして管理エンドポイントを使用します。 ベース プール管理エンドポイントの後のパス内の内容はすべて、セッションのコンテナーに転送されます。

たとえば、次の呼び出しを行う場合: <POOL_MANAGEMENT_ENDPOINT>/api/uploadfile、要求は、 0.0.0.0:<TARGET_PORT>/api/uploadfileでセッションのコンテナーにルーティングされます。

継続的な対話

同じセッションを引き続き呼び出す場合、セッションはプールに 割り当てられた ままになります。 クールダウン期間が経過した後にセッションへの要求がないと、セッションは自動的に破棄されます。

サンプルリクエスト

次の例は、ユーザーの ID をセッション一意識別子として使用してセッションに要求を送信する方法を示しています。

要求を送信する前に、<> 角かっこの間のプレースホルダーを、要求に固有の値に置き換えます。

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

この要求は、ユーザーの ID の識別子を使用してセッション内のコンテナーに転送されます。

セッションがまだ実行されていない場合、Azure Container Apps は、要求を転送する前にプールからセッションを自動的に割り当てます。

この例では、セッションのコンテナーは、 http://0.0.0.0:<INGRESS_PORT>/<API_PATH_EXPOSED_BY_CONTAINER>で要求を受信します。

識別子

セッションに HTTP 要求を送信するには、要求内でセッション識別子を指定する必要があります。 セッションに要求を行うときに、URL に identifier という名前のクエリ文字列パラメーターでセッション識別子を渡します。

• その識別子を持つセッションが既に存在する場合、要求は既存のセッションに送信されます。

• その識別子を持つセッションが存在しない場合、要求が送信される前に新しいセッションが自動的に割り当てられます。

識別子の形式

セッション識別子は自由形式の文字列です。つまり、アプリケーションのニーズに合わせて任意の方法で定義できます。

セッション識別子は、セッション プール内で一意である定義した文字列です。 Web アプリケーションを構築する場合は、ユーザーの ID をセッション識別子として使用できます。 チャットボットを構築している場合は、会話 ID を使用できます。

識別子は、4 文字から 128 文字の文字列である必要があり、この一覧 (|、-、&、^、%、$、#、(、)、{、}、[、]、;、<、>) の英数字と特殊文字のみを含められます。

安全

動的セッションは、セキュリティで保護された分離された環境で信頼されていないコードとアプリケーションを実行するように構築されています。 セッションは互いに分離されますが、ファイルや環境変数など、1 つのセッション内のものであれば何でも、セッションのユーザーはアクセスできます。

セッションのユーザーを信頼している場合にのみ、機密性の高いデータをセッションに構成またはアップロードします。

既定では、セッションは送信ネットワーク要求を行うことができなくなっています。 セッション プールでネットワーク状態の設定を構成することで、ネットワーク アクセスを制御できます。

• 強力な一意のセッション識別子を使用する: ブルート フォース攻撃を防ぐために、長くて複雑なセッション識別子を常に生成します。 暗号アルゴリズムを使用して、推測が困難な識別子を作成します。

• セッションの可視性を制限する: セッション識別子がセッション プールにのみ表示されるように、厳密なアクセス制御を設定します。 URL またはログでセッション ID を公開しないようにします。

• 短い有効期限を実装する: 短時間の非アクティブの後に有効期限が切れるセッション識別子を構成します。 このアプローチにより、ユーザーがアプリケーションとの対話を完了した後にセッションがハイジャックされるリスクが最小限に抑えられます。

• セッション資格情報を定期的にローテーションする: セッションに関連付けられている資格情報を定期的に確認して更新します。 ローテーションにより、不正アクセスのリスクが減少します。

• セキュリティで保護された転送プロトコルを利用する: HTTPS を使用して、セッション識別子を含む転送中のデータを常に暗号化します。 このアプローチは、中間者攻撃から保護します。

• セッション アクティビティの監視: セッション アクティビティを追跡するためのログ記録と監視を実装します。 これらのログを使用して、異常なパターンや潜在的なセキュリティ侵害を特定します。

• ユーザー入力を検証する: すべてのユーザー入力を危険として扱います。 入力の検証と衛生技術を使用して、インジェクション攻撃から保護し、信頼できるデータのみが処理されるようにします。

セッションを完全にセキュリティで保護するには、次のことができます。

• Microsoft Entra ID の認証と承認を使用する
• セッション識別子を保護する

認証と承認

プール管理 API を使用してセッションに要求を送信すると、認証は Microsoft Entra トークンを使用して処理されます。 Azure ContainerApps Session Executor ロールに属する ID からの Microsoft Entra トークンのみが、プール管理 API を呼び出す権限を持ちます。

ロールを ID に割り当てるには、次の Azure CLI コマンドを使用します。

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

大規模言語モデル (LLM) フレームワーク統合を使用している場合、フレームワークはトークンの生成と管理を自動的に処理します。 アプリケーションが、セッション プールで必要なロールの割り当てを持つマネージド ID で構成されていることを確認します。

プールの管理 API エンドポイントを直接使用している場合は、トークンを生成し、それを HTTP 要求の Authorization ヘッダーに含める必要があります。 前述のロールの割り当てに加えて、トークンには、値 aud を持つ対象者 (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

セッション識別子を保護する

セッション識別子は機密情報であり、安全に管理する必要があります。 アプリケーションでは、各ユーザーまたはテナントが自身のセッションのみにアクセスできるようにする必要があります。

セッション識別子の誤用を防ぐ具体的な戦略は、アプリの設計とアーキテクチャによって異なります。 ただし、悪意のあるユーザーが別のユーザーのセッションにアクセスできないようにするために、アプリは常にセッション識別子の作成と使用を完全に制御する必要があります。

戦略の例を以下に示します。

• ユーザーごとに 1 つのセッション: アプリでユーザーごとに 1 つのセッションを使用する場合は、各ユーザーを安全に認証し、アプリではログインされた各ユーザーに対して一意のセッション識別子を使用する必要があります。

• エージェントの会話ごとに 1 つのセッション: アプリで AI エージェントの会話ごとに 1 つのセッションを使用する場合は、アプリが各会話ごとにエンド ユーザーが変更できない一意のセッション識別子を使用していることを確認します。

マネージド ID の使用

Microsoft Entra ID のマネージド ID を使用すると、コンテナー セッション プールとそのセッションから他の Microsoft Entra で保護されたリソースにアクセスできます。 セッション プールでは、システム割り当てマネージド ID とユーザー割り当てマネージド ID の両方がサポートされます。

Microsoft Entra ID のマネージド ID の詳細については、「Azure リソースのマネージド ID」を参照してください。

カスタム コンテナー セッション プールでマネージド ID を使用するには、次の 2 つの方法があります。

• イメージ プルの認証: マネージド ID を使用してコンテナー レジストリで認証し、コンテナー イメージをプルします。

• リソース アクセス: セッション内でセッション プールのマネージド ID を使用して、Microsoft Entra で保護された他のリソースにアクセスします。 セキュリティへの影響により、この機能は既定で無効になっています。

  Von Bedeutung

  セッションでマネージド ID へのアクセスを有効にした場合、セッションで実行されているコードまたはプログラムは、プールのマネージド ID の Microsoft Entra トークンを作成できます。 通常、セッションでは信頼されていないコードが実行されるため、この機能は細心の注意を払って使用してください。

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

ロギング（記録）

セッションで実行されているコンテナーのコンソール ログは、 AppEnvSessionConsoleLogs_CLという名前のテーブル内の Azure Container Apps 環境に関連付けられている Azure Log Analytics ワークスペースで使用できます。

関連コンテンツ

• セッションの種類: さまざまな種類の動的セッションについて説明します。

  • コード インタープリター セッション
  • カスタム コンテナー セッション

• チュートリアル: REST API を直接操作するか、LLM エージェントを使用して作業します。

  • LLM エージェントを使用します。
    • AutoGen
    • LangChain
    • LlamaIndex
    • セマンティック カーネル
  • REST API の使用
    • JavaScript コード インタープリター