Удостоверяване нагоре по веригата без ключ за AI API Gateways: Модел за обединяване на идентичност на работното натоварване

Служителите на производствения шлюз не трябва да носят дълготрайни ключове API нагоре по веригата, когато доставчикът може да удостовери самото работно натоварване. По-безопасният модел е да обмените съществуваща облачна, Kubernetes, CI или SPIFFE самоличност за краткотрайни идентификационни данни на доставчик, да кеширате правилно тези идентификационни данни и да ги ограничите до най-малката полезна граница за оторизация.

Трудната част не е обменът на токени. Той се справя с неравномерна поддръжка от доставчика, едновременни опреснявания, съпоставяне на идентичност, изключения от контролната равнина, прекъсвания и миграция, без да създава скрит резервен вариант към широко привилегирован споделен ключ.

Започнете с възможности за удостоверяване, а не с глобална настройка без ключ

Факт: Поддръжката за удостоверяване се различава според доставчика и операцията. OpenAI и Anthropic поддържат обединяване на самоличността на работното натоварване за API работни натоварвания. Azure OpenAI поддържа Microsoft Entra ID и управлявани самоличности. Google Облакът поддържа прикачени акаунти за услуги, идентификационни данни по подразбиране на приложението и федерация на идентичност на работното натоварване за външни работни натоварвания. Изводите по време на изпълнение и административните API обаче не приемат непременно едни и същи типове идентификационни данни.

Например, OpenAI токените за идентичност на работното натоварване в момента не могат да извикват администраторски API крайни точки. Следователно шлюзът не може безопасно да представи удостоверяването като едно поле на ниво доставчик, като например auth_mode: federated.

Препоръка: Изградете матрица на възможностите, въведена от акаунт на доставчик, семейство крайни точки, среда и клас на работа:

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

Поставяне на брокер на идентификационни данни между адаптерите за маршрутизиране и доставчика

Адаптерите на доставчици не трябва да извличат идентификационни данни за метаданни, да конструират твърдения или да управляват независимо опресняване на токени. Представете брокер на идентификационни данни с един тесен интерфейс:

Credential acquire(CredentialRequest request)

CredentialRequest {
  provider_account_id
  workload_identity_id
  operation_class
  target_service_account
  audience
  scopes
}

Credential {
  value
  expires_at
  authorization_context
  provenance
}

Стойността на идентификационните данни е чувствителна и трябва да остане в паметта или в одобрен ефимерен кеш. Контекстът на оторизацията записва проекта на доставчика, акаунта на услугата, обхватите, ролите или ограниченията за внедряване, представени от токена. Произходът идентифицира как е придобит, като oidc_exchange, managed_identity, adc или break_glass.

Този договор запазва маршрутизацията неутрална спрямо доставчика, като същевременно запазва подробностите, необходими за проверки на авторизация и телеметрия. Освен това не позволява мултимоделен API шлюз за екипи да третира всеки носещ токен като взаимозаменяем.

Използване на специфични за доставчика адаптери за придобиване

Всеки адаптер за придобиване трябва да изпълнява само стъпките, изисквани от неговия доставчик:

• Получаване на външно твърдение от източника на локална идентичност, като токен на акаунт за проектирана услуга на Kubernetes, услуга за облачни метаданни или работно натоварване на SPIFFE API.
• Заявете точната аудитория, очаквана от доставчика или конфигурираното правило за обединяване.
• Обменете твърдението, когато доставчикът изисква токен exchange.
• Връща получените идентификационни данни и пълномощно време за изтичане.
• Класифицира неуспехите като локална идентичност, обмен, оторизация, конфигурация или грешки в наличността на доставчика.

Крайна точка, съвместима с OpenAIVertex AI, е полезен пример за разделяне: приложение може да получи Google токен за достъп чрез идентификационни данни по подразбиране на приложението и да предостави този токен като OpenAI идентификационни данни на клиента. Адаптерът на протокола остава OpenAI-съвместим, докато получаването на идентификационни данни остава Google-специфично.

Направете упълномощаване на кеша на токените

Факт: Федералните идентификационни данни са краткотрайни. OpenAI токените за достъп до идентичност на работното натоварване продължават не повече от един час, не могат да надживеят токена на външния субект или потвърдения сертификат и се издават без токени за опресняване. Работното натоварване трябва да повтори обмена преди изтичане.

Кешираният ключ трябва да включва всяко измерение, което може да промени произтичащия авторитет:

cache_key = hash(
  provider_account_id,
  workload_identity_id,
  target_service_account,
  audience,
  normalized_scopes,
  operation_class
)

Пропускането на целевия акаунт, аудитория или обхвати може да накара работник да използва повторно валиден токен в грешен контекст на оторизация. Това е по-опасно от пропуск в кеша.

Опресняване преди изтичане, като се използва граница на безопасност и рандомизирано трептене. Една практическа политика е:

refresh_at = expires_at
             - max(configured_margin, token_lifetime * 0.10)
             - random_jitter

Точният марж трябва да отчита изкривяването на часовника, забавянето на обмена, времето за повторен опит и най-дългата очаквана заявка. Не опреснявайте само с фиксиран таймер, отделен от expires_at.

Предотвратяване на бури на обмен с еднократно опресняване

Когато много заявки срещнат един и същ токен с близко изтичане, само едно изпълнение трябва да извърши обмена. Другите обаждащи се трябва да продължат да използват съществуващите идентификационни данни, докато остават в рамките на разрешения прозорец, или да изчакат за кратко споделения резултат от опресняване.

Използвайте еднократно заключване на кеш ключ. При внедряване с много процеси или много възли решете дали всеки работник може да поддържа свой собствен кеш или трябва да се разпредели координацията на опресняването. Локалният кеш е по-прост, но увеличава обема на обмена. Разпределеният кеш намалява обмена, но разширява границата на чувствителни токени и изисква криптиран транспорт, строг контрол на достъпа и внимателно изгонване.

Препоръка: Предпочитайте кешове в процеса, освен ако ограниченията на доставчика или размерът на флота не показват необходимостта от споделена услуга за токени. Първо координирайте обновяванията във всеки процес, след това измерете обменния обем.

Свързване на идентичности с точни заявления за натоварване

Федерацията премества доверието от съхранен ключ към претенции за самоличност. Следователно разрешителното картографиране може да бъде също толкова опасно, колкото изтекли споделени идентификационни данни.

Потвърдете издателя и целевата аудитория, след което обвържете съпоставянето с неизменни или строго контролирани твърдения. За Kubernetes включете пространството от имена и акаунта за услуга, вместо да се доверявате на каквото и да е натоварване в клъстера. За CI ограничете хранилището, работния поток, средата и защитения клон или контекста на разполагане. За идентичности в облака картографирайте конкретен принципал на работното натоварване, а не цял клиент или организация.

Създайте отделни акаунти за услуги нагоре по веригата или управлявани самоличности за производство, етапи, фонови задания и административна автоматизация. Ограничете всяка самоличност до моделите, проектите, работните пространства, внедряванията и API операциите, от които се нуждае.

Факт: OpenAI може да ограничи съпоставянията на самоличността на работното натоварване с API разрешения. Anthropic сътрудниците обмениха идентификационни данни със сервизен акаунт и предупреждава, че обединяването е толкова сигурно, колкото и конфигурацията на самоличността нагоре. Управляваните самоличности и IAM в облака по подобен начин зависят от присвояването на роли с правилен обхват.

Разделете идентификационните данни за време на изпълнение от администраторските идентификационни данни

Работник за изводи никога не трябва да наследява токен на администратор на организация само защото някои задачи на контролната равнина все още се нуждаят от такъв. Разделете системата на две граници на сигурност:

• Равнина на изпълнение: Обработва заявки за модели и получава само обединени или управлявани идентификационни данни, обхванати от извод.
• Контролна равнина: Извършва администриране на проект, работно пространство, таксуване или акаунт за услуги чрез изолирани задания с отделно съхранени идентификационни данни и по-силно одобрение контроли.

Административните идентификационни данни не трябва да имат път към променливите на средата за изпълнение, спецификациите на pod, пакетите за отстраняване на грешки или кешовете на токени. Запишете използването им в същата система за проверка само за добавяне, използвана за промени в конфигурацията.

Неуспешно затваряне без импровизирано възстановяване

Препоръка: Не замествайте автоматично неуспешен обединен обмен със споделен статичен ключ. Автоматичното възстановяване може да заобиколи отменено съпоставяне, да прикрие неправилна аудитория или да възстанови достъпа, който администраторът на самоличността е премахнал умишлено.

Връщане на класифицирана грешка при удостоверяване нагоре, спиране на изпращането до акаунта на засегнатия доставчик и разрешаване на нормална политика за маршрутизиране за избор на друг доставчик само когато тази алтернатива е разрешена за клиента и работното натоварване. Резервният модел и резервният идентификационен номер са различни решения.

Ключът със счупено стъкло все още може да бъде оправдан при сериозни прекъсвания на доставчика на самоличност. Дръжте го деактивиран или недостъпен при нормална работа. Активирането трябва да изисква удостоверено одобрение, да има фиксирано изтичане, да ограничава акаунта и операциите на засегнатия доставчик и да предупреждава за всяка заявка, направена с него. Неговият произход трябва да се показва в телеметрията на заявката.

Мигрирайте един пул за маршрутизиране наведнъж

1. Време на изпълнение на инвентара и административни идентификационни данни. Идентифицирайте кои процеси могат да четат всеки от тях.
2. Създайте специална самоличност за работно натоварване и акаунт за услуга на доставчик с тесен обхват.
3. Конфигурирайте точни съпоставяния на издателя, аудиторията, темата и разрешенията.
4. Добавете проверка преди полет, която придобива токен и извиква разрешена крайна точка с ниско въздействие.
5. Canary a малък пул за маршрутизиране, използващ само федерация. Не оставяйте автоматичния резервен ключ активиран по време на теста.
6. Сравнете неуспешното удостоверяване, забавянето на обмена, възрастта на токена и резултатите от упълномощаването на доставчика със съществуващия път.
7. Увеличавайте трафика постепенно и наблюдавайте поне един пълен цикъл на опресняване на токена.
8. Премахнете стария ключ от достъпа по време на изпълнение, след което го отменете след дефинираното наблюдение период.

Повторете този процес по акаунт на доставчик и среда. Глобалното прекъсване затруднява разграничаването на грешка в картографирането на идентичността от специфично за доставчика поведение на токен.

Измерете и тествайте режимите на отказ

Записване на забавяне при обмен на токени, опити за опресняване, неуспешно опресняване, възраст на идентификационните данни, издател, картографиран принципал, акаунт на доставчик, клас на операция и категория на грешка при удостоверяване. Никога не записвайте токени за достъп, външни твърдения, клиентски тайни или пълни заглавки за оторизация.

Преди обединяването да стане единственият производствен път, тествайте:

• Изкривяване на часовника между работници, доставчици на идентичност и услуги за токени на доставчика.
• Недостъпност на крайната точка на самоличност на метаданни или работно натоварване.
• Изтекли твърдения и неправилни аудитории.
• Премахване на роля и правило за обединяване деактивиране.
• Ограничаване на обмена на токени и временни грешки на доставчика.
• Едновременно опресняване при пиков трафик.
• Ротация на ключовете за подписване, докато старите токени остават валидни.

За ротация на емитента на OIDC публикувайте стари и нови ключове за подписване с достатъчно припокриване за кешове на верификатори и издадени токени. OpenAI документира 600-секундно кеширане за откриване и отдалечени JWKS данни, с опресняване на JWKS, когато токен препраща към неизвестен ID на ключ. Не приемайте, че всеки верификатор се държи идентично; тестова ротация с живи канарчета.

Приемете безключово удостоверяване по време на изпълнение като ограничена миграция

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

Започнете с матрицата на възможностите, идентификационни данни на посредник през един интерфейс, кеширайте по контекст на оторизация, използвайте точни съпоставяния на идентичността и неуспешно затваряне при грешки в обмена. Завършете миграцията само след като наблюдавате успешно опресняване, отмяна, прекъсване и тестове за ротация на ключ за подписване. Това създава път за изпълнение без ключ, чиято наличност и поведение на оторизация се разбират, а не се предполага.

Свързано четене

• проверка на идентификационните данни на доставчика преди маршрутизиране на производствения трафик