OpenAI mTLS и X.509 Workload Identity теперь в GA: что должен проверить каждый оператор API-шлюза

29 августа OpenAI перевела mutual TLS (mTLS) и X.509 workload identity federation в general availability для всех API-организаций. Функции включаются вручную и по умолчанию отключены — но как только администратор организации их активирует, любой proxy или gateway, который проксирует API-запросы этой организации, становится обязательным держателем сертификата. Сбой выглядит не как ошибка 401, а как отказ TLS handshake — он происходит до того, как bearer-токен или API-ключ вообще проверяются.

Что именно вышло в GA 29 августа

OpenAI выпустила два взаимосвязанных механизма.

Mutual TLS добавляет проверку клиентского сертификата в API-запросы. После загрузки и активации trust anchor — на уровне проекта или всей организации — каждый запрос в этой области должен поступать через mTLS API host и предъявлять принятый клиентский сертификат во время TLS handshake. OpenAI проверяет сертификат до стандартной проверки API-ключа или access token.

X.509 workload identity federation использует те же trust anchors для обмена на token. Workload предъявляет сертификат и получает короткоживущий bearer token; последующие запросы отправляются с этим токеном плюс клиентским сертификатом через mTLS API host. Статический API-ключ в workload не нужен вообще.

Оба механизма управляются через новые RBAC-разрешения (api.mtls.read, api.mtls.write) и семейство эндпоинтов управления сертификатами:

• POST /v1/organization/certificates — загрузить trust anchor
• GET /v1/organization/certificates — список всех сертификатов организации
• GET | POST | DELETE /v1/organization/certificates/{certificate_id} — получить, обновить или удалить сертификат

Пять операционных последствий, которые нужно понять до включения mTLS

1. Меняется адрес API host. mTLS-проверка работает только на отдельном mTLS API host; соединения со стандартным api.openai.com сертификат не проверяют. Gateway, которому нужно предъявлять клиентский сертификат, обязан прописать mTLS host в base_url или upstream — иначе проверка обходится, а не применяется.

2. Gateway должен держать приватный ключ. Workload, предъявляющий TLS-клиентский сертификат, должен иметь защищённый доступ к приватному ключу. Gateway, который терминирует TLS и пересылает HTTP внутрь, управляет этим ключом сам. Прозрачный TCP proxy, не терминирующий TLS, может транслировать сертификат — но только при специальной настройке.

3. CEL-фильтры создают разграничение доступа на уровне workload. Каждый trust anchor может содержать CEL-фильтр, ограничивающий, какие именно верифицированные клиентские сертификаты он принимает — через выражения над api.mtls.subject_dn и api.mtls.san. Это позволяет привязать разные узлы шлюза к разным organizational unit или hostname-паттернам внутри одной организации без использования разных API-ключей.

4. Отзыва сертификатов нет. OpenAI не выполняет проверки AIA, CRL или OCSP. Единственный способ нейтрализовать скомпрометированный сертификат — деактивировать его через консоль или DELETE /v1/organization/certificates/{certificate_id}, затем сменить trust anchor и перевыкатить gateway на всех узлах, держащих старый ключ. Всё вручную, требует координации.

5. Multi-project gateway должен сопоставлять сертификаты с проектами. OpenAI проверяет project-level сертификаты раньше organization-level. Gateway, обслуживающий несколько проектов одной организации, либо предъявляет нужный per-project сертификат на отдельных TLS-соединениях, либо откатывается на organization-level сертификат. Логика маршрутизации должна учитывать, в какую область попадает конкретный запрос.

Сравнение с моделями аутентификации Anthropic и Google

Сравнение по провайдерам полезно для операторов шлюзов, которые маршрутизируют трафик на несколько backend'ов.

Anthropic использует OIDC-based Workload Identity Federation: клиентский сертификат не нужен, короткоживущий токен обменивается напрямую у cloud identity provider (AWS, GCP, Azure). Gateway не держит приватный ключ — он держит cloud IAM identity.

Google Vertex AI и Amazon Bedrock используют Managed Identity или service account JSON. Та же схема: identity живёт в cloud IAM plane, а не в локально управляемом сертификате.

OpenAI mTLS инфраструктурно наиболее требователен: нужна certificate authority, дистрибуция ключей на каждый узел шлюза и ручная ротация без поддержки отзыва. Зато он лучше всего переносится в среды с существующей PKI-инфраструктурой: корпоративные CA, HashiCorp Vault PKI, AWS Private CA, GCP Certificate Authority Service. Команды, уже эксплуатирующие PKI и имеющие изолированные или on-premises workloads, получают от этого реальную пользу.

Keyless-путь через X.509: что это меняет для шлюзов

X.509 workload identity federation меняет архитектурное уравнение для операторов, готовых принять PKI-требования. Gateway предъявляет сертификат token exchange эндпоинту OpenAI, получает короткоживущий bearer token и использует его в API-запросах — статический API-ключ нигде не хранится. Ротация ключей становится ротацией сертификатов, для которой в большинстве зрелых инфраструктур уже есть инструментарий.

Это наиболее значимый архитектурный сдвиг всего GA-релиза. mTLS-only путь добавляет второй фактор поверх существующего API-ключа; X.509 workload identity убирает API-ключ полностью.

Что проверить в routing-конфигурации прямо сейчас

mTLS отключён по умолчанию. Никаких действий не требуется, если только вы не планируете его включать или администратор вашей организации не сделает это без согласования с командой шлюза. Но функция создаёт новую категорию незаметной неправильной конфигурации.

Gateway с жёстко прописанным base_url на стандартный api.openai.com не предъявляет клиентский сертификат и не проверяется на его наличие — он фактически обходит принудительную проверку. Это одновременно сценарий сбоя (gateway не защищён mTLS) и непреднамеренный запасной выход (gateway не сломается, когда org-level mTLS включат). Допустим ли такой компромисс — зависит от вашей модели угроз.

Для команд, планирующих внедрение mTLS, рекомендованная последовательность: создать или подключить существующую CA, сгенерировать per-gateway клиентские сертификаты, загрузить trust anchor через POST /v1/organization/certificates, активировать сначала для некритичного проекта, протестировать запросы через mTLS API host и только после успешной валидации распространять на production.

Добавьте поля mTLS host и клиентского сертификата в схему провайдерных credentials прямо сейчас — до того, как какой-нибудь администратор включит функцию и создаст неожиданный жёсткий сбой. В документации по настройке провайдеров TheRouter перечислены доступные поля для кастомных TLS-настроек.