GitHub Actions: пуни SHA није довољан без мањих дозвола

У постојећем GitHub Actions workflow-у фиксирајте спољне акције на пуни commit SHA, поставите permissions: {contents: read} за цео ток и доделите write дозволу само послу који објављује. GitHub-ова безбедносна упутства препоручују управо пуни SHA и најмање потребне дозволе: таг може да се помери, а акција може да користи GITHUB_TOKEN и када јој није изричито прослеђен.

Редослед је важан у постојећој датотеци: прво утврдите шта се извршава, затим закључајте ревизије, па сузите права. Условни пример има посао test, који чита код, и release, који објављује издање. SHA одређује који се код акције покреће; permissions одређује шта тај код сме да уради помоћу токена датог послу.

Попишите акције и послове пре измене

У датотекама у .github/workflows прођите кроз све ставке uses. Забележите спољне акције у корацима и послове који позивају поново употребљив workflow из другог репозиторијума. Уз сваку референцу упишите репозиторијум, тренутни таг, грану или SHA, као и посао у ком се покреће. Локалне акције са путањом која почиње са ./ немају спољну ревизију коју бисте заменили SHA вредношћу.

За сваки посао утврдите да ли само преузима код или користи GitHub API за упис: креира издање, мења садржај, означава захтев за измену или објављује пакет. Забележите и послове који користе тајне. Тако ћете раздвојити стварну потребу за write дозволом од дозволе коју је ток до сада добијао подразумевано. У условном примеру test не уписује ништа у репозиторијум, док release креира издање.

Замените покретне референце пуним commit SHA

У спољној ставци uses замените референцу облика actions/checkout@ТАГ обликом actions/checkout@ПУНИ_COMMIT_SHA. Ово је условни запис: ПУНИ_COMMIT_SHA мора да се замени стварном пуном вредношћу commit-а, а не да остане у YAML датотеци. Исто урадите за остале спољне акције и позване workflow датотеке из других репозиторијума. Коментар са називом издања може да олакша каснији преглед, али извршавање одређује вредност после знака @.

Пре измене отворите репозиторијум сваке акције и утврдите који commit одговара издању које желите. Проверите да SHA припада баш том репозиторијуму, а не његовом fork-у. Немојте узети скраћени приказ вредности са странице commit-а: у uses упишите пуну вредност. Прегледајте и измене које је изабрана ревизија донела, нарочито рад са садржајем репозиторијума и тајнама; фиксирана ревизија сама по себи не значи да је њен код безбедан.

После замене покрените посао који користи акцију. Ако се понашање разликује од очекиваног, прво проверите да ли је уписан commit намераваног издања и да ли његови улази одговарају постојећем workflow-у. Ово раздваја грешку у избору ревизије од каснијих проблема са дозволама.

Ограничите GITHUB_TOKEN на нивоу посла

На највишем нивоу workflow датотеке, уз on и jobs, додајте permissions: {contents: read}. Условни test тада може да чита садржај репозиторијума без права да га мења. Унутар jobs.release додајте засебан кључ permissions: {contents: write}. Он припада само послу за објављивање; постављен на врх датотеке, дао би write приступ и пословима којима није потребан.

GitHub-ова референца за workflow синтаксу наводи да се дозволе могу задати за цео ток или појединачни посао, да write обухвата и read и да ненаведене дозволе постају none. Зато подешавање у release послу треба да садржи све дозволе које тај посао стварно користи: оно није само додатак општем подешавању. contents: write омогућава креирање издања, али послу који, рецимо, означава захтев за измену треба и одговарајућа pull-requests: write дозвола.

Дозволе посла важе за све његове кораке који користе GITHUB_TOKEN. Зато кораке за тестирање и обраду неповерљивог улаза држите у послу са read приступом, а посао за објављивање ограничите на предвиђени окидач и неопходне кораке. Ако после сужавања права неки корак добије грешку због забрањеног уписа, проверите коју радњу обавља пре додавања дозволе целом послу.

Одржавајте закључане ревизије преко Dependabot-а

Фиксирана ревизија остаје иста док је не ажурирате. У датотеци .github/dependabot.yml укључите ажурирања акција: GitHub-ово упутство за Dependabot даје пример са version: 2 и ставком updates која садржи package-ecosystem: "github-actions", directory: "/" и schedule: {interval: "weekly"}. Путања "/" у том подешавању обухвата workflow датотеке у .github/workflows.

Dependabot затим предлаже ажурирања кроз захтеве за измену. Тај предлог задржите као тачку за преглед: упоредите стари и нови commit, проверите издање коме нова ревизија припада и пустите workflow пре спајања. Аутоматско прихватање би уклонило прилику да приметите промене у коду акције или њеном понашању. Ако за изабрану ревизију нема јасне везе са издањем, проверите тачно шта предложени commit мења.

Испробајте оба пута извршавања

Покрените уобичајени ток у ком test чита код и проверава измену. Он треба да ради са contents: read, а посао за објављивање треба да остане прескочен када окидач није намењен издању. Затим испробајте предвиђени пут објављивања: release треба да добије само дозволе потребне за ту радњу. Таква провера открива и погрешно изабран SHA и корак који се раније ослањао на сувише широка права.

При следећој измени workflow датотеке поновите попис uses ставки и дозвола нових послова. Нова спољна акција треба да има проверену ревизију, а нови посао да наследи read приступ док конкретна радња не оправда ужу, изричито наведену write дозволу.

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

• SSH потпис на Git commit-у није довољан — кључ мора и на GitHub
• GitHub Actions без трајног cloud кључа: OIDC тражи строжи subject
• GitHub Copilot управља десктоп апликацијама — дозволе остају пресудне