Настройка проверки подлинности сертификата клиента в приложениях контейнеров Azure

Приложения контейнеров Azure поддерживают проверку подлинности сертификата клиента (также называемую взаимной проверкой подлинности TLS или mTLS), которая позволяет получить доступ к приложению-контейнеру с помощью двусторонней проверки подлинности. В этой статье показано, как настроить авторизацию сертификата клиента в приложениях контейнеров Azure.

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

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

Контейнерные приложения принимают сертификаты клиента в формате PKCS12, когда доверенный центр сертификации выдает их или когда они самозаверяются.

Настройка авторизации сертификата клиента

Чтобы настроить поддержку сертификатов клиента, задайте clientCertificateMode свойство в шаблоне приложения контейнера.

Для свойства можно задать одно из следующих значений:

  • require: сертификат клиента необходим для всех запросов к приложению-контейнеру.
  • accept: сертификат клиента является необязательным. Если сертификат клиента не указан, запрос по-прежнему принимается.
  • ignore: сертификат клиента игнорируется.

Ingress передает сертификат клиента приложению-контейнеру, если require или accept задано.

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

{
  "properties": {
    "configuration": {
      "ingress": {
        "clientCertificateMode": "require"
      }
    }
  }
}

Замечание

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

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

Получите идентификатор Azure Resource Manager (ARM) контейнерного приложения:

APP_ID=$(az containerapp show \
  --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --query id \
  --output tsv)

Пропатчите clientCertificateMode свойство в приложении:

az rest \
  --method patch \
  --url "https://management.azure.com/$APP_ID?api-version=<API_VERSION>" \
  --body '{
    "properties": {
      "configuration": {
        "ingress": {
          "clientCertificateMode": "require"
        }
      }
    }
  }'

Замечание

Не забудьте использовать допустимую и стабильную версию API, которая поддерживает эту функцию. Например, замените <API_VERSION> в команде 2025-01-01 или другой поддерживаемой версией.

Режим сертификата клиента и формат заголовка

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

  • При require установке клиент должен предоставить сертификат.
  • Если accept задано, сертификат необязателен. Если клиент предоставляет сертификат, он передается приложению в заголовке X-Forwarded-Client-Cert в виде списка с запятой.

Пример X-Forwarded-Client-Cert значения заголовка

Следующий пример — это пример значения заголовка X-Forwarded-Client-Cert , который может получить ваше приложение:

Hash=<HASH_VALUE>;Cert="-----BEGIN CERTIFICATE-----<CERTIFICATE_VALUE>";Chain="-----BEGIN CERTIFICATE-----<CERTIFICATE_VALUE>";

Разбивка полей заголовка

Поле Описание Как использовать его
Hash Отпечаток SHA-256 сертификата клиента. Используйте отпечаток для идентификации или проверки сертификата клиента.
Cert Сертификат клиента в кодировке Base64 в формате PEM (один сертификат). Анализ сертификата для проверки метаданных, таких как субъект и издатель.
Chain Один или несколько промежуточных сертификатов в кодировке PEM. Предоставьте промежуточные сертификаты при создании цепочки полного доверия для проверки.

Дальнейшие шаги