GitHub Actions без трајног cloud кључа: OIDC тражи строжи subject

GitHub Actions може да приступи Azure ресурсима без дуготрајног сервисног кључа: посао затражи OIDC токен, а Azure га размени за приступни токен ако су услови поверења испуњени. GitHub упутство за OIDC описује тај поступак као начин да се облачни креденцијали не чувају међу дуготрајним Actions тајнама.

Успешан Azure Login показује да један посао пролази; не показује да су остали одбијени. Ако услов поверења прихвата преширок subject (sub), и посао из другог репозиторијума или гране може да добије исти облачни идентитет. Зато конфигурација мора да одреди издаваоца, публику и тачан контекст посла, а провера да обухвати и покушаје који морају да пропадну.

Минимално подешавање за Azure

Условни пример је репозиторијум primer-tim/servis који распоређује апликацију са гране main. За пријаву преко OIDC, Microsoft упутство за Azure Login тражи федеративни акредитив на Microsoft Entra апликацији или кориснички додељеном управљаном идентитету, дозволу id-token: write и корак azure/login@v2. Идентитету треба доделити Azure улогу потребну за конкретан ресурс: федеративни акредитив одређује ко сме да се пријави, а улога шта пријављени идентитет сме да ради.

1. Припремите Microsoft Entra апликацију са сервисним принципалом или кориснички додељен управљани идентитет. Забележите client ID, tenant ID и subscription ID. За овај начин пријаве workflow-у није потребан client secret.
2. Додајте federated identity credential за GitHub Actions. За условни посао без GitHub environment-а изаберите репозиторијум primer-tim/servis и грану main, па у акредитиву проверите стварне вредности за issuer, audience и subject. Подразумевани Azure Login audience за јавни Azure је api://AzureADTokenExchange.
3. У послу који се покреће за push на main поставите permissions са id-token: write. Ако исти посао користи actions/checkout, додајте contents: read. У корак uses: azure/login@v2 проследите client-id, tenant-id и subscription-id; Microsoft пример чита те идентификаторе из GitHub secrets.
4. После пријаве покрените радњу која захтева предвиђену Azure улогу. Када дозвољени посао ради и одбијени случајеви прођу проверу, уклоните стари сервисни кључ из workflow-а и обришите сачувану тајну.

Дозвола id-token: write даје послу могућност да затражи GitHub OIDC токен; сама по себи не даје дозволу за измену Azure ресурса. То је важна разлика при провери: неуспех пре добијања GitHub токена говори о подешавању workflow-а, док одбијена размена токена показује да се примењује федеративни услов.

Шта Azure заправо пореди у токену

Issuer (iss) означава GitHub издаваоца https://token.actions.githubusercontent.com. Audience (aud) мора да одговара вредности коју Azure Login тражи и коју федеративни акредитив прихвата. Subject је ужи услов: он повезује токен са репозиторијумом и контекстом извршавања. Иста публика може да важи за више послова, па њено поклапање није замена за прецизан subject.

За условни старији репозиторијум који није укључио непроменљиви формат, посао са гране main, без environment-а и без догађаја pull_request, има облик subject-а repo:primer-tim/servis:ref:refs/heads/main. Према GitHub OIDC референци, репозиторијуми направљени после 15. јула 2026. подразумевано у тај низ укључују и непроменљиве ID вредности власника и репозиторијума; ранији репозиторијуми задржавају стари формат док га не промене, а исти нови формат важи и после преименовања или преноса репозиторијума. Зато у Azure треба унети вредност коју заиста шаље ваш посао, а не дословно преписати условни пример.

Ако посао користи GitHub environment, подразумевани subject садржи име тог окружења уместо референце на грану. Федеративни услов за environment production тада сам не доказује да је посао покренут са main: ограничење дозвољених грана треба подесити у правилима за то окружење. За догађај pull_request без environment-а подразумевани контекст је такође другачији, што је још један разлог да вредност subject-а потиче из стварног начина покретања посла.

Подразумевани subject не издваја одобрени reusable workflow. Ако је и његова путања део границе поверења, GitHub омогућава прилагођени subject који обухвата repo, context и job_workflow_ref. Та промена замењује читав подразумевани формат, па Azure акредитив мора да очекује нову пуну вредност; услов у Azure подесите пре укључивања GitHub шаблона. Само подешавање шаблона на нивоу организације не мора да промени токене репозиторијума док се он не укључи у тај шаблон.

Три негативна теста за границу поверења

Пробне послове ограничите на Azure Login и безопасну проверу пријављеног идентитета, без измене ресурса. Сваком дајте исте идентификаторе Entra идентитета и дозволу id-token: write, тако да разлика буде у контексту из ког токен долази. Поред исхода забележите репозиторијум, грану, environment и reusable workflow: порука о недостајућој дозволи или погрешном client ID није доказ да је услов subject-а одбио токен.

• Други репозиторијум: условно покрените пробни посао из другог репозиторијума са истим Entra client ID. Његов subject садржи друго име репозиторијума, а у непроменљивом формату и други ID, па размена за идентитет намењен репозиторијуму servis треба да буде одбијена. Ако успе, прегледајте све федеративне акредитиве тог Entra идентитета, а не само онај који сте управо додали.
• Друга грана: покрените пробни посао са гране feature у истом репозиторијуму. GitHub и даље може да му изда OIDC токен, али његов subject не треба да прође Azure услов за main. Ако посао користи environment, проверите његова правила за дозвољене гране, јер подразумевани subject са именом окружења не носи исту проверу гране.
• Други reusable workflow: позовите неодобрени reusable workflow из истог репозиторијума и истог контекста. Док је на снази само подразумевани subject, овај покушај може да прође и тако покаже шта услов не разликује. Поновите пробу после укључивања прилагођеног subject-а са job_workflow_ref и одговарајућег Azure услова: сада размена треба да буде одбијена јер се пуна вредност subject-а разликује.

Проверите и позитиван пут истим поступком: одобрени посао треба да добије приступни токен и изврши само радњу коју му додељена Azure улога дозвољава. Тако се разликују две границе које се често мешају — избор посла који сме да преузме идентитет и овлашћења која тај идентитет има после пријаве.

Исти принцип код другог облачног провајдера

При преласку на другог провајдера задржите редослед провере, али користите audience и начин задавања услова које тражи та интеграција. Најпре утврдите GitHub issuer, затим публику за конкретну размену и subject који тачно описује одобрени репозиторијум, грану или environment и, ако је потребно, reusable workflow. После успешне пријаве одобреног посла поновите покушаје из суседних контекста. Кратак век токена уклања потребу за трајним cloud кључем у Actions тајнама; прецизан услов поверења одређује ко сме да затражи заменски приступ.

Прочитајте и:

• Kajabi или Thinkific: јефтинији курс може да тражи више алата
• APEC тражи заштиту радника: AI мења и социјалну сигурност
• OBS Studio или StreamYard: лакши пренос тражи месечну претплату