ISTO IME, DRUG REPOZITORIJ

V Microsoft Entra lahko ostane federativna poverilnica za GitHubov repozitorij, ki ga razvojna ekipa že dolgo ne uporablja. Projekt je bil preimenovan, prenesen v drugo organizacijo ali izbrisan, konfiguracija zaupanja v oblačnem okolju pa se ni spremenila. Če je bila vezana na ime prvotnega repozitorija, lahko v določenih okoliščinah znova postane uporabna za drug objekt z enakim imenom.

Takšna možnost je bila eden od razlogov, da je GitHub leta 2026 posegel v privzeto obliko identitete, ki jo njegovi avtomatizirani razvojni postopki predstavljajo zunanjim storitvam. Spremembo je napovedal 23. aprila, za nove ter po uvedbi preimenovane ali prenesene repozitorije na GitHub.com pa je začela veljati 15. julija. Starejših nespremenjenih repozitorijev ni samodejno vključil. GitHub Enterprise Server sprememba ne zajema. [1]

V ospredju ni ranljivost kriptografskega podpisa ali odkritje nove metode ponarejanja žetonov. GitHub je spremenil način, kako v žetonu označi repozitorij, za katerega je žeton izdan. Dotedanja oblika je uporabljala imeni lastnika in repozitorija, nova pa jima dodaja trajna številčna identifikatorja. Razlika je pomembna predvsem tam, kjer zunanji sistem na podlagi te oznake odloča o izdaji dostopne poverilnice.

Kako razvojni postopek pridobi zaupanje

GitHub Actions omogoča prijavo v oblačne storitve s kratkoživimi žetoni OpenID Connect (OIDC). Namesto da bi razvojna ekipa v GitHubu hranila dolgoročno skrivnost aplikacije, lahko opravilo med izvajanjem zahteva podpisan žeton GitHubovega ponudnika identitete. Za to potrebuje dovoljenje id-token: write, ki samo po sebi še ne zagotavlja dostopa do zunanjih virov. [2]

Pri povezovanju z Microsoft Entra se takšen žeton uporabi kot zunanje dokazilo v postopku federacije identitet. Microsoftova platforma preveri veljavnost žetona in pogoje konfiguriranega zaupanja. Pri običajnih federativnih poverilnicah so posebej pomembne tri trditve: iss določa izdajatelja, sub označuje subjekt, aud pa pove, kateri storitvi je žeton namenjen. Pri GitHub Actions je izdajatelj https://token.actions.githubusercontent.com; za običajno izmenjavo z Microsoft Entra se uporablja občinstvo api://AzureADTokenExchange. To vrednost je treba ustrezno zahtevati, saj ni univerzalna privzeta vrednost vseh GitHubovih OIDC-žetonov. [2][3]

Ko se pogoji ujemajo, lahko Microsoft Entra izda dostopni žeton aplikacijski ali drugi podprti identiteti, s katero je povezana federativna poverilnica. Kaj bo ta identiteta lahko dejansko storila, je odvisno od njenih dovoljenj in pravil ciljne storitve. Izmenjava žetona in dovoljenje za spreminjanje produkcijskih virov sta različna koraka.

Prejšnja privzeta oblika trditve sub je za izmišljeni repozitorij primer/izplacila in vejo main lahko znašala:

repo:primer/izplacila:ref:refs/heads/main

Zapis določa polno ime repozitorija in vejo, ne pa trajnega identifikatorja konkretnega repozitorija. Imeni sta uporabni za ljudi, ki upravljajo projekte, vendar nista nujno primerni kot edini dokaz identitete pri dolgoročnem federativnem zaupanju.

Repozitorij je mogoče preimenovati, prenesti ali izbrisati. Če GitHub pozneje dovoli ponovno uporabo njegovega imena, lahko isto besedilo označuje drug repozitorij. Standard OpenID Connect Core za identifikator subjekta določa lokalno enoličnost in prepoved ponovne dodelitve. GitHubova sprememba odpravlja prav tveganje, da bi imensko zasnovana trditev v različnih obdobjih predstavljala različna objekta. [1][7]

Stara poverilnica, novi repozitorij

Vzemimo hipotetičen primer organizacije, ki je iz repozitorija primer/izplacila objavljala aplikacijo v Azure. Za prijavo je uporabljala federativno poverilnico v Microsoft Entra, povezano z aplikacijsko identiteto z dovoljenji za objavo. Pozneje je repozitorij preselila, prvotne federativne poverilnice pa ni odstranila.

Da bi ta opuščena konfiguracija postala izkoristljiva, se mora uresničiti več pogojev. Prvotno ime mora biti znova na voljo, druga oseba ali skupina pa mora dobiti možnost ustvariti in upravljati repozitorij pod istim polnim imenom. To ni samoumevno: če organizacija še vedno nadzoruje svoj imenski prostor, si ga zunanja oseba ne more preprosto prisvojiti. Tveganje je drugačno pri sproščenem imenskem prostoru ali pri osebi, ki ima znotraj organizacije potrebne pravice za ustvarjanje repozitorijev.

Novi repozitorij bi moral omogočiti tudi zagon opravila, ki lahko pridobi GitHubov OIDC-žeton. Njegova trditev sub bi morala ustrezati stari konfiguraciji, vključno z zahtevanim kontekstom veje, okolja ali druge okoliščine izvajanja. V Microsoft Entra bi morala medtem ostati veljavna federativna poverilnica, ki še vedno sprejema imensko zasnovani subjekt. Ujemati bi se morali tudi izdajatelj, občinstvo in preostali pogoji preverjanja. [3][4]

Če bi bili ti pogoji izpolnjeni, bi lahko opravilo iz novega repozitorija pridobilo Microsoftov dostopni žeton za identiteto, ki je bila prvotno namenjena staremu projektu. Morebitna zloraba oblačnih virov bi bila nato omejena ali omogočena glede na pravice te identitete.

Gre za model možnega napada, ne za opis dokumentirane kompromitacije. GitHub in Microsoft opozarjata na ponovno uporabo subjekta (subject recycling) ter na zapuščene federativne poverilnice, vendar s tem ne potrjujeta, da se je predstavljeni dogodek zgodil v konkretni organizaciji. [1][4]

Pri tem mehanizmu je posebej pomembno, da je lahko žeton povsem pristen. GitHub ga je izdal dejanskemu opravilu, digitalni podpis je veljaven in izdajatelj je pravilno prepoznan. Sporna je povezava med subjektom, zapisanim v žetonu, in repozitorijem, ki mu je bila nekoč podeljena pravica do uporabe oblačne identitete.

Kriptografsko preverjanje potrjuje izvor in celovitost žetona. Ne more pa samo ugotoviti, ali danes isto ime še vedno pripada objektu, zaradi katerega je bilo zaupanje ustvarjeno.

Julijska sprememba: identifikator, ki ga ime ne more podedovati

GitHub je v novo privzeto obliko sub dodal številčna identifikatorja lastnika in repozitorija. Za isti izmišljeni projekt bi bil zapis po novem videti takole:

repo:primer@123456/izplacila@789012:ref:refs/heads/main

Številki sta ponazoritveni. Prva označuje lastnika, druga repozitorij. GitHub identifikatorja dodeli konkretnima objektoma, zato ju nov lastnik imena oziroma novo ustvarjeni repozitorij ne more podedovati zgolj s ponovno uporabo istega poimenovanja. [1][2]

Če bi nekdo pod istim lastnikom ustvaril drug repozitorij izplacila, bi lahko njegovo ime ostalo nespremenjeno, številčni identifikator repozitorija pa bi bil drugačen. Nova trditev zato ne bi ustrezala federativni poverilnici, ki pričakuje identifikator prvotnega repozitorija.

Pri tem je izraz nespremenljiva identiteta treba razumeti natančno. Trajna identifikatorja sta vgrajena v niz, ki še vedno vsebuje tudi imeni. Ob preimenovanju repozitorija se lahko zato celotna vrednost sub spremeni, čeprav njegov številčni ID ostane isti. Ob prenosu drugemu lastniku ostane ID repozitorija vezan na prvotni objekt, spremenita pa se lahko ime in identifikator lastnika.

Nova oblika preprečuje, da bi drug objekt zaradi enakega imena samodejno dobil enak subjekt. Ne zagotavlja pa, da bo obstoječa konfiguracija natančnega ujemanja še naprej delovala po vsaki spremembi imena ali lastništva. [2][5]

Zanimiva je tudi podrobnost iz samega postopka uvedbe. GitHub je 10. junija 2026 popravil prvotno napovedano ločilo med imenom in identifikatorjem: namesto vezaja je določil znak @. Skrbnik, ki bi konfiguracijo zaupanja pripravil po starejšem primeru in je ne bi posodobil, bi lahko ob prehodu naletel na zavrnjeno izmenjavo žetona. [1]

Enako previdnost zahteva kontekst delovnega postopka. GitHubova trditev sub se lahko razlikuje glede na to, ali opravilo uporablja vejo, oznako, zahtevek za vključitev sprememb ali zaščiteno okolje. Na primer, pri opravilu, povezanem z GitHubovim okoljem, se lahko uporabi kontekst environment namesto običajnega zapisa veje. Skrbnik mora zato preveriti dejansko izdano vrednost, ne le predpostavljati oblike po vzorcu za main. [2]

Prehod v Microsoft Entra

Organizacije, ki so federativne poverilnice ustvarile pred uvedbo nove oblike, imajo lahko še vedno pravila, vezana na dotedanja imena repozitorijev. Samodejna sprememba na GitHubovi strani in nespremenjena konfiguracija na oblačni strani lahko povzročita napako pri prijavi, če se vrednosti sub ne ujemata več.

Microsoft zato priporoča prehod z vzporedno pripravo nove federativne poverilnice. Skrbnik najprej pridobi oziroma preveri novo vrednost subjekta, jo nastavi v Microsoft Entra in nato omogoči novo obliko v GitHubu. Po uspešnem preizkusu prijave in delovanja postopka odstrani staro poverilnico. GitHub za pripravo prehoda ponuja tudi možnost predogleda novega prefiksa subjekta, za vključitev nove oblike pa nastavitve na ravni organizacije ali repozitorija ter programski vmesnik API. [1][5][8]

Za prehod ni dovolj preizkusiti samo ene objave, če ista aplikacijska identiteta sprejema žetone več razvojnih postopkov. Preveriti je treba vse dejansko uporabljene subjekte in njihove kontekste. Poverilnica, ki je pravilna za produkcijsko okolje, ni nujno ustrezna tudi za opravilo na drugi veji ali v drugem okolju.

Na voljo je še pristop s prilagodljivimi federativnimi poverilnicami Microsoft Entra. Te omogočajo izraze za ujemanje več trditev, pri GitHubovih žetonih med drugim repository_id in repository_owner_id. Za GitHub je poleg pogoja nad sub zahtevano preverjanje najmanj ene od teh dveh trditev. Če mora zaupanje veljati za točno določen repozitorij, je posebej pomemben repository_id; preverjanje repository_owner_id pa lahko dodatno omeji zaupanje na predvidenega lastnika. [6]

Takšna ureditev dopušča natančnejše pogoje in v določenih primerih zmanjša število posameznih federativnih poverilnic. Vendar je Microsoft funkcionalnost septembra 2026 še vedno označeval kot predogledno, z omejitvami pri upravljanju. Pred uvedbo je treba preveriti njeno podporo v uporabljenem okolju in oceniti posledice morebitnega širšega ujemanja vej ali drugih kontekstov.

Prehod na novo obliko je smiseln tudi zaradi zaščite pred ponovnim prevzemom starega imena. Če organizacija po uspešni migraciji trajno obdrži še staro federativno poverilnico, lahko ta še vedno zaupa prvotnemu imenskemu subjektu. Novo pravilo v takšnem primeru ne odpravi tveganja, ki ga ohranjeno staro pravilo dopušča.

Kaj ostane po odstranitvi repozitorija

Primer opozarja na problem, ki se ne začne in ne konča pri GitHubu. Življenjski cikel razvojnega projekta je pogosto drugačen od življenjskega cikla identitete, uporabljene za dostop do infrastrukture. Repozitorij je lahko arhiviran ali izbrisan, aplikacijska identiteta in njene pravice v Azure pa ostanejo. Enako velja za federativne poverilnice, ki so bile ustvarjene za postopke, ki jih nihče več ne izvaja.

Microsoft takšne zapuščene poverilnice (dangling federated identity credentials) izrecno opredeljuje kot tveganje. Njihova prisotnost lahko omogoči ponovno vzpostavitev zaupanja, če pozneje drug subjekt pridobi ustrezno ime in izpolni pogoje stare konfiguracije. [4]

Pri varnostnem pregledu zato podatek o zadnji uspešni prijavi ni zadosten. Preveriti je treba, kateremu dejanskemu repozitoriju pripada zaupanja vredni subjekt, kdo ga nadzoruje, kakšne spremembe delovnih postopkov so dovoljene in ali je oblačna identiteta še potrebna. Pregled mora zajeti tudi vloge in dovoljenja, saj bi bil vpliv napačne povezave zaupanja bistveno drugačen pri identiteti z omejenim dostopom kot pri tisti s širokimi privilegiji.

Trajni identifikatorji pri tem rešujejo samo določeno vrsto zamenjave. Če ima nekdo pravico spreminjati delovni postopek v legitimnem repozitoriju, nova oblika sub ne prepreči, da bi ta postopek zahteval žeton. Zaščite vej, pravila potrjevanja sprememb, dovoljenja GitHub Actions in zaščite okolij morajo zato ostati del celotnega modela zaupanja.

GitHubova sprememba iz leta 2026 je razmeroma majhen poseg v strukturo žetona, vendar odpravlja konkretno nevarnost: da bi oblačna storitev nekoč zaupala drugemu repozitoriju samo zato, ker se njegovo ime ujema z imenom prvotnega.

Pri upravljanju federiranih identitet je zato treba spremljati več kot veljavnost podpisov in uspešnost prijav. Pomembna je tudi zgodovina objekta, na katerega je vezano zaupanje. Ko repozitorij izgine ali zamenja lastnika, mora nekdo preveriti, ali imajo pripadajoče federativne poverilnice in dodeljene pravice še upravičen razlog za obstoj. GitHub je z novo obliko subjekta zmanjšal odvisnost od ponovljivih imen. Za odstranitev zastarelega zaupanja v ciljnem okolju pa mora še vedno poskrbeti njegov upravljavec.

EVIDENCE PROFILE

Dokazni profil članka

Profil pokaže vrsto dokazne podlage in omejitve osrednjega argumenta.

OSREDNJI DOKAZStara imenska oblika GitHubove OIDC-trditve sub lahko ob ponovno uporabljenem imenu in zapuščeni federativni poverilnici privede do napačnega zaupanja; nova oblika trditve vsebuje trajna ID-ja repozitorija in lastnika.

RAZISKAVE0

DOKUMENTACIJA7

PREDOBJAVE0

UREDNIŠKI PREIZKUSNE

PREVERJENO2026-10-18

Viri

1. 01PRIMARY DOCUMENTATIONGitHub
   Immutable subject claims for GitHub Actions OIDC tokens, 23. april 2026; posodobitev 10. junija 2026.Odpri vir ↗
2. 02PRIMARY DOCUMENTATIONGitHub
   OpenID Connect reference. Uradna tehnična dokumentacija GitHub Actions.Odpri vir ↗
3. 03PRIMARY DOCUMENTATIONMicrosoft
   Overview of federated identity credentials in Microsoft Entra ID. Microsoft Graph v1.0.Odpri vir ↗
4. 04PRIMARY DOCUMENTATIONMicrosoft
   Mutable subjects in federated identity credentials, 30. julij 2026.Odpri vir ↗
5. 05PRIMARY DOCUMENTATIONMicrosoft
   Migrate GitHub Actions federated credentials to immutable subjects, 30. julij 2026.Odpri vir ↗
6. 06PRIMARY DOCUMENTATIONMicrosoft
   Flexible federated identity credentials (preview), 23. september 2026.Odpri vir ↗
7. 07STANDARDOpenID Foundation
   OpenID Connect Core 1.0 incorporating errata set 2. Razdelka 2 in 5.7.Odpri vir ↗
8. 08PRIMARY DOCUMENTATIONGitHub
   REST API endpoints for GitHub Actions OIDC.Odpri vir ↗