GitHub Actions без долгорочен клуч: OIDC бара прецизна политика на доверба

30 септември 2026 г., во 03:00|Автор: Уредувачки тим на QUASA|5 мин. читање| 2

За да ги отстраните долгорочните cloud-клучеви од GitHub Actions, прво ограничете кој репозиториум и контекст смеат да преземат cloud-улога, а потоа заменете го клучот во работниот тек со OIDC. Објаснувањето на GitHub за OIDC ја опишува размената: задачата добива сопствен токен, провајдерот го проверува нејзиниот идентитет и издава краткотрајни акредитиви за тоа извршување.

Клучната граница е политиката на доверба на cloud-улогата. Дозволата id-token: write во YAML ѝ овозможува на задачата да побара GitHub OIDC токен, но не ѝ дава автоматски пристап до cloud-ресурсите. Ако сакате пристап само преку определен работен тек, условот за репозиториум и гранка не е доволен: мора да го ограничите и патот до одобреното извршување.

Одредете кој смее да ја преземе улогата

Пред миграцијата запишете од кој репозиториум се распоредува апликацијата, од која гранка или GitHub environment тргнува задачата и кои ресурси ѝ се потребни. Разгледајте два обида што политиката треба да ги одбие: задача од друг репозиториум и задача од друг дозволен пат во истиот репозиториум. Токенот на секоја задача носи тврдења за нејзиното потекло; cloud-провајдерот одлучува дали тие одговараат на условите за улогата.

Одвојте ја довербата од дозволите на улогата. Политиката на доверба одредува кој може да ја преземе улогата, додека дозволите прикачени на неа одредуваат што може да направи добиената сесија. Затоа на улогата дајте ѝ само дејства и ресурси потребни за распоредувањето: тесниот услов за OIDC не го стеснува пристапот откако улогата веќе е преземена.

Поставете федеративна врска со точен услов

Во AWS, како конкретен пример, додајте го GitHub OIDC провајдерот во IAM со issuer token.actions.githubusercontent.com и audience sts.amazonaws.com кога ја користите AWS акцијата. Потоа создадете IAM улога чија политика за sts:AssumeRoleWithWebIdentity ги споредува тврдењата aud и sub со очекуваните вредности. За условен репозиториум ORG/REPO што распоредува од гранката main, sub во стандардниот формат е repo:ORG/REPO:ref:refs/heads/main; заменете ги примерните имиња со вистинските пред да ја зачувате политиката.

Водичот на GitHub за AWS ги прикажува тие IAM услови и наведува дека за репозиториуми создадени по 15 јули 2026 година sub вклучува и непроменливи идентификатори на сопственикот и репозиториумот. Проверете кој формат го користи вашиот репозиториум пред да ја внесете точната вредност: услов напишан за постариот формат ќе одбие легитимна задача со новиот формат. Користете точно совпаѓање наместо широко правило што прифаќа секоја гранка или средина во репозиториумот.

Ако задачата користи GitHub environment, sub го содржи името на средината наместо гранката. Во тој случај поставете правила за заштита на средината, особено кои гранки и ознаки смеат да распоредуваат преку неа. Самото име на средината во IAM условот не кажува кој смее да ја активира во GitHub.

Заменете ги статичните акредитиви во YAML

Во задачата што се најавува на AWS додајте permissions со id-token: write. Ако користите actions/checkout за преземање на содржината, додајте и contents: read; другите GitHub дозволи ограничете ги според потребата на задачата. Поставувањето на овие дозволи на ниво на задача го задржува барањето OIDC токен кај делот од работниот тек што навистина се најавува.

Во чекорите користете aws-actions/configure-aws-credentials со role-to-assume поставен на ARN на новата улога и aws-region на потребниот регион. Акцијата го разменува GitHub OIDC токенот за краткотрајни AWS акредитиви што ги користат следните чекори во задачата. Отстранете ги aws-access-key-id и aws-secret-access-key од конфигурацијата на тој чекор, како и други повикувања на стариот клуч во работниот тек: инаку успешното извршување не покажува јасно дека се користел OIDC.

Пуштете ја одобрената задача и извршете aws sts get-caller-identity пред операцијата за распоредување. Проверете дали одговорот ги покажува очекуваните AWS сметка и преземена улога. Овој позитивен тест ја проверува патеката за најавување; одделно проверете дали дозволите на улогата ја овозможуваат токму потребната операција врз ресурсот.

Врзете ја довербата и за работниот тек кога е потребно

Условот што ги препознава репозиториумот и гранката може да прифати друга задача од истата гранка. Ако барањето е само одобрен reusable workflow да добие cloud-пристап, вклучете го и неговиот job_workflow_ref во sub, заедно со репозиториумот и дозволениот контекст. Референцата на GitHub за OIDC го опишува приспособувањето со repo, context и job_workflow_ref.

Најпрво внесете го соодветниот услов во политиката на cloud-улогата, а потоа применете го новиот формат на sub во GitHub. Промената го заменува стандардниот формат на целото тврдење; ако двете страни не се усогласени, и одобрената задача ќе биде одбиена. Кај репозиториум со непроменлив формат, вклучете ги и идентификаторите што остануваат дел од repo сегментот.

Ограничувањето на reusable workflow го проверува идентитетот на задачата што работи во него, но важно е и кој може да го повика. Ако друг работен тек од истиот дозволен контекст смее да ја активира одобрената патека, може да стигне до истата задача. Контролата на измени во гранката и правилата на средината затоа се дел од границата на доверба.

Проверете го одбивањето, па укинете ги старите клучеви

Изведете негативни проверки во извршувања без старите AWS клучеви. Задача од недозволен репозиториум нека ја побара истата улога со id-token: write и истите поставки на AWS акцијата; повторете го обидот од недозволена гранка ако политиката ја ограничува гранката. Очекуваниот резултат е одбиено преземање на улогата, додека одобрената задача и понатаму успева.

Ако политиката е врзана и за reusable workflow, пробајте од друг работен тек во истиот репозиториум и дозволен контекст, без одобрената reusable патека. Разликувајте ги двете проверки: другата задача може да добие сопствен GitHub OIDC токен, но AWS треба да одбие тој токен да ја преземе улогата. Ако преземањето успее, споредете ја добиената вредност на sub со IAM условот и проверете дали правилото е пошироко од планираното или другата задача може да ја повика одобрената патека.

Откако одобрената задача ќе успее, а недозволените обиди ќе бидат одбиени, избришете ги старите клучеви од GitHub Secrets и укинете ги кај AWS. Така работниот тек останува со проверена патека за краткотрајно најавување, без употреблив долгорочен клуч покрај неа.

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

Сподели: