OpenAI добавила ресурсы федерации удостоверений рабочей нагрузки в свои официальные SDK и опубликовала документацию для автоматизации аутентификации API и Codex без хранения долгосрочных учетных данных OpenAI.

Система принимает удостоверения, выданные поддерживаемыми облачными платформами, платформами непрерывной интеграции и рабочих нагрузок, а затем обменивает их на кратковременные токены доступа OpenAI. OpenAI поддержка документов для источников удостоверений, включая Amazon Web Services, Microsoft Azure, Google Cloud, Oracle Cloud, Kubernetes, GitHub Actions и SPIFFE-совместимые среды.

Это больше, чем SDK удобство. Это дает организациям возможность подключить существующую систему идентификации рабочей нагрузки к OpenAI и ограничить ущерб, вызванный утечкой, копированием или неправильной ротацией ключей API. Это также меняет то, что шлюзы и платформы разработчиков должны записывать при аутентификации автоматизированных рабочих нагрузок от имени клиента.

Как OpenAI работает федерация идентификации рабочих нагрузок

Рабочая нагрузка сначала получает учетные данные из своей собственной среды. В зависимости от платформы и службы OpenAI это удостоверение может быть представлено через OpenID Connect, SPIFFE или сертификат X.509. Затем он заменяется на временный токен доступа OpenAI вместо использования постоянного ключа API, встроенного в конфигурацию приложения.

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

Для рабочих нагрузок OpenAI API внешний идентификатор может быть сопоставлен с учетной записью службы проекта. В управляемых Codex средах OpenAI документы сопоставлены с пользователями рабочей области или учетными записями служб. Это различие важно, поскольку автоматический внутренний процесс обычно не должен наследовать те же идентификаторы и разрешения, что и отдельный разработчик.

Официальные выпуски Python и Node SDK от 3 ноября добавили сгенерированные ресурсы для управления поставщиками удостоверений рабочей нагрузки и правилами федерации. Однако OpenAI не опубликовал отдельную статью о запуске, определяющую точную область развертывания, поэтому организациям следует подтвердить соответствие учетной записи требованиям и доступность конфигурации перед планированием миграции.

Почему недолговечные учетные данные имеют значение

Обычные ключи API просты, но они создают эксплуатационные трудности. Ключ, скопированный в переменную CI, образ контейнера или сценарий развертывания, может оставаться полезным до тех пор, пока кто-нибудь не поменяет или не отзовет его. Федерация заменяет эти постоянные учетные данные токеном доступа, полученным на основе удостоверения, которым уже обладает рабочая нагрузка и срок действия которого истекает через ограниченный период.

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

GitHub Действия — это один из вариантов немедленного использования. Организация может использовать идентификатор рабочего процесса вместо размещения многоразового ключа OpenAI в секретах репозитория или организации. Облачные службы и рабочие нагрузки Kubernetes могут следовать одному и тому же общему шаблону через свои собственные системы идентификации.

Последствия для шлюзов и партнерских платформ

Federation вводит новый путь аутентификации для любой плоскости управления AI API, используемой командами разработчиков.Платформа больше не может предполагать, что каждый восходящий запрос авторизуется статическим ключом клиента. Возможно, потребуется сохранить идентификатор внешней рабочей нагрузки, получить или принять кратковременные токены и связать использование с правильной учетной записью службы проекта OpenAI.

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

Та же проблема относится к AI API платформе реселлера. Сопоставление каждой рабочей нагрузки клиента с узкой учетной записью службы безопаснее, чем совместное использование учетных данных на уровне организации, но платформа должна препятствовать разрешению внешнего удостоверения одного арендатора в проект OpenAI другого арендатора. Записи аудита должны сохранять внешнюю идентификацию, правило федерации, сопоставленный субъект OpenAI и результирующую атрибуцию использования.

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

Что остается неясным

В документации установлена ​​модель аутентификации и поддерживаемые категории поставщиков удостоверений, но некоторые вопросы развертывания остаются специфичными для учетной записи. OpenAI в отдельном объявлении четко не указано, какие планы или организации могут немедленно настроить федерацию. Дополнения SDK показывают поддержку клиента, но тип SDK сам по себе не подтверждает, что каждая учетная запись имеет соответствующие права на серверную часть.

Существует также разница в уровне обслуживания, на которую следует обратить внимание: OpenAI документирует федерацию X.509 для пути API, но не для пути Codex. Команды должны проверить тип учетных данных, поддерживаемый предполагаемой службой, а не предполагать, что все механизмы идентификации применяются единообразно.

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