GitHub Actions-ի ամպային բանալիները փոխարինեք մեկ job-ի OIDC token-ով

|Հեղինակ: QUASA-ի խմբագրական թիմ|5 րոպե ընթերցանություն| 1
GitHub Actions-ի ամպային բանալիները փոխարինեք մեկ job-ի OIDC token-ով

GitHub Actions-ի job-ը կարող է Google Cloud մուտք գործել առանց service account-ի երկարաժամկետ JSON բանալու․ այն ստանում է OIDC token, իսկ Workload Identity Federation-ը դրա փոխարեն տրամադրում է կարճաժամկետ հավատարմագրեր։ Google Cloud-ի կարգավորման ուղեցույցը նկարագրում է, թե ինչպես սահմանափակել այդ մուտքը GitHub-ի repository-ի և branch-ի հատկանիշներով։

Անցումն արեք այս հերթականությամբ՝ ստեղծեք սահմանափակված OIDC provider, թույլատրեք ընտրված job-ին օգտագործել service account-ը, փորձարկեք անհրաժեշտ Google Cloud գործողությունը և միայն հաջող փորձից հետո հեռացրեք հին բանալին։ Service account-ը կարող է մնալ որպես ռեսուրսային թույլտվությունների կրող․ փոխվում է այն եղանակը, որով job-ը ստանում է դրա անունից գործելու իրավունք։

Հավաքեք նույնացուցիչներն ու որոշեք job-ի թույլտվությունը

Գրանցեք Google Cloud նախագծի ID-ն ու համարը, GitHub repository-ի և դրա սեփականատիրոջ թվային ID-ները, թույլատրելի branch-ը և գործող service account-ի էլփոստի հասցեն։ Նախագծի համարը պետք է Workload Identity provider-ի և IAM principal-ի ուղիներում, իսկ ID-ն՝ նախագծին ուղղված gcloud հրամաններում։ Նախ պարզեք նաև, թե job-ը որ ռեսուրսին է դիմելու. դրանից է կախված service account-ին անհրաժեշտ նվազագույն դերը։

Ստորև բերված պայմանական օրինակը թույլ է տալիս միայն main branch-ը, որի Git ref-ը refs/heads/main է։ Եթե նույն service account-ի բանալին օգտագործում են այլ workflow-ներ կամ արտաքին համակարգեր, գրանցեք այդ կախվածությունները մինչև փոփոխությունը։ Առանձին ստուգեք pull request-ից կամ environment-ով աշխատող job-երը. դրանց token-ի հատկանիշները կարող են տարբերվել ընտրված branch-ի սովորական գործարկումից։

Ստեղծեք pool և սահմանափակեք OIDC provider-ը

Google Cloud-ում ստեղծեք Workload Identity Pool, ապա դրա ներսում՝ OIDC provider։ Cloud Shell-ում pool-ը կարելի է ստեղծել gcloud iam workload-identity-pools create POOL_ID --project=PROJECT_ID --location=global --display-name=GitHub հրամանով։ Provider-ի issuer URI-ն սահմանեք https://token.actions.githubusercontent.com/ հասցեով, իսկ audience-ի համար օգտագործեք լռելյայն տարբերակը։ Այս կազմաձևումը տեղակայեք այն նախագծում, որի համարը հետո կգրեք provider-ի ամբողջական ուղու մեջ։

Attribute mapping-ում նշեք google.subject=assertion.sub, attribute.repository_id=assertion.repository_id, attribute.repository_owner_id=assertion.repository_owner_id և attribute.ref=assertion.ref։ Թվային repository_id-ն ու repository_owner_id-ն ընտրեք անունների փոխարեն. անունը կարող է փոխվել կամ ջնջումից հետո կրկին օգտագործվել, մինչդեռ այդ ID-ները եզակի են։ Քարտեզագրված ref-ը պետք է branch-ի պայմանը հստակ կապի GitHub-ի ուղարկած արժեքին։

Provider-ի attribute condition-ի պայմանական օրինակը հետևյալն է՝ attribute.repository_owner_id=='OWNER_ID' && attribute.repository_id=='REPO_ID' && attribute.ref=='refs/heads/main'։ OWNER_ID-ն և REPO_ID-ն փոխարինեք ձեր GitHub օբյեկտների իրական թվային ID-ներով։ Պայմանը ստուգվում է Google Cloud-ում մինչև token-ի ընդունումը. workflow-ի trigger-ը միայնակ այդ սահմանափակման փոխարինողը չէ։

Provider-ը ստեղծելուց հետո պահեք դրա ամբողջական անունը՝ projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID։ Այստեղ PROJECT_NUMBER-ը նախագծի թիվն է, ոչ թե տառերից կազմված ID-ն։ Եթե provider-ի պայմանը մերժում է սպասված գործարկումը, համեմատեք repository-ի, սեփականատիրոջ և ref-ի փաստացի արժեքները ձեր գրած արժեքների հետ՝ պայմանը լայնացնելու փոխարեն։

Տվեք service account-ին հասնելու և ռեսուրսը կարդալու իրավունքները

Գործող service account-ի IAM policy-ում federated principal-ին տվեք roles/iam.workloadIdentityUser դերը։ Repository-ի համար principalSet-ի ուղին կլինի principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/attribute.repository_id/REPO_ID։ Այն կարելի է կապել gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL --role=roles/iam.workloadIdentityUser --member=PRINCIPAL_SET հրամանով՝ PRINCIPAL_SET-ի տեղում դնելով այդ ամբողջական ուղին։ Provider-ի պայմանն այդ կապից անկախ կպահանջի նաև ճիշտ owner ID-ն ու main branch-ը։

Այնուհետև հենց service account-ին տվեք այն դերը, որն անհրաժեշտ է փորձնական գործողությանը, ցանկալի է՝ կոնկրետ ռեսուրսի վրա։ Օրինակ՝ Cloud Storage bucket-ի օբյեկտները դիտելու պայմանական փորձի համար service account-ին տվյալ bucket-ի վրա տվեք roles/storage.objectViewer դերը։ Federation-ը լուծում է նույնականացումը, իսկ ռեսուրսի IAM policy-ն որոշում է, թե նույնականացված job-ը ինչ կարող է անել։ Լայն նախագծային դեր տալը կթաքցնի բացակայող նեղ թույլտվությունը և կավելացնի job-ի հասանելիությունը։

Փորձարկեք job-ը առանց հին JSON գաղտնիքի

Փորձնական workflow-ում ընտրեք on: workflow_dispatch, որպեսզի այն ձեռքով գործարկեք main branch-ից։ Job-ի permissions բաժնում սահմանեք contents: read և id-token: write։ Երկրորդ թույլտվությունը GitHub-ից OIDC token խնդրելու համար է. այն ինքնին Google Cloud-ի ռեսուրսների վրա գրելու իրավունք չի տալիս։ google-github-actions/auth-ի հրահանգները ցույց են տալիս ընթացիկ auth@v3 քայլը, provider-ի ամբողջական ուղին և service account-ի ընտրովի փոխանցումը։

  1. Եթե workflow-ն օգտագործում է checkout, actions/checkout քայլը դրեք նույնականացումից առաջ։ Դրանից հետո ավելացրեք google-github-actions/auth@v3 քայլը՝ workload_identity_provider դաշտում նշելով ամբողջական provider-ի անունը, service_account դաշտում՝ գործող account-ի հասցեն։ gcloud-ի համար հստակ նշեք նաև project_id-ը, որպեսզի հաջորդ հրամանները ճիշտ նախագծին ուղղվեն։
  2. Հեռացրեք փորձնական job-ից credentials_json դաշտը և հին GitHub secret-ի բոլոր հղումները։ Նույն job-ում երկու եղանակն էլ պահելու դեպքում հաջող գործարկումը չի ապացուցի, որ OIDC ուղին աշխատում է։ Եթե ստուգումը կատարելու եք gcloud-ով, auth քայլից հետո ավելացրեք google-github-actions/setup-gcloud@v3։
  3. Պայմանական Cloud Storage փորձի համար կատարեք gcloud storage ls gs://BUCKET/ հրամանը։ BUCKET-ը փոխարինեք այն bucket-ի անունով, որի վրա service account-ին տվել եք դիտման իրավունքը։ Հաջող արդյունքը պետք է հաստատի հենց նախատեսված ռեսուրսային գործողությունը, ոչ միայն auth քայլի ավարտը։

Այնուհետև նույն workflow-ը գործարկեք այլ branch-ից, որտեղ փորձնական workflow-ի ֆայլը նույնպես հասանելի է։ Սպասվող արդյունքը federation-ի մերժումն է provider-ի branch պայմանի պատճառով։ Եթե փորձը հասնում է Cloud Storage գործողությանը, վերանայեք provider-ի condition-ը և job-ում մնացած հավատարմագրերը։ Կազմաձևման ու IAM փոփոխությունների տարածումը կարող է որոշ ժամանակ պահանջել, ուստի նոր կարգավորումից անմիջապես հետո ստացած սխալը գնահատեք նաև այդ հանգամանքի հաշվառմամբ։

Հաջող անցումից հետո անջատեք և ջնջեք հին բանալին

Երբ հիմնական workflow-ը նոր եղանակով հաջողությամբ կատարում է իր իրական Google Cloud գործողությունը, GitHub-ից հեռացրեք JSON secret-ը և workflow-ներից՝ դրա օգտագործման հղումները։ Մինչև բանալուն դիպչելը հաստատեք, որ նույն key ID-ից այլ pipeline կամ արտաքին համակարգ կախված չէ։ Բանալին նույնականացրեք service account-ի Keys բաժնում կամ դրա բանալիների ցանկում. service account-ի անունը բավարար չէ ճիշտ բանալին ընտրելու համար։

Google Cloud-ի բանալիների կառավարման հրահանգը խորհուրդ է տալիս բանալին նախ անջատել և ջնջել միայն այն բանից հետո, երբ համոզվել եք, որ այն այլևս պետք չէ։ Անջատումից հետո հետևեք կախված գործարկումներին, ապա ջնջեք հենց ստուգված KEY_ID-ն Keys բաժնից կամ gcloud iam service-accounts keys delete KEY_ID --iam-account=SERVICE_ACCOUNT_EMAIL հրամանով։ Բանալին ջնջելը չի պահանջում ջնջել service account-ը. վերջինս շարունակում է ծառայել OIDC-ով թույլատրված job-ին իր սահմանափակ IAM դերերով։

Կարդացեք նաև:

Կիսվել:

Առնչվող հոդվածներ

Բաժանորդագրվեք մեր տեղեկագրին

Ստացեք Web3-ի, ԱԲ-ի և կրիպտոյի վերջին լուրերն անմիջապես ձեր էլ. փոստին։

0