GitHub Actions-д AWS key хадгалах хэрэггүй: OIDC-г нөхцөлтэй холбо

GitHub Actions-оос AWS-д байнгын access key хадгалалгүй нэвтрэхийн тулд AWS IAM-д GitHub-ийн OIDC provider бүртгэж, deploy хийх job-д зориулсан role үүсгэнэ. Job-д id-token: write зөвшөөрөл өгөөд aws-actions/configure-aws-credentials action-аар OIDC токеныг түр AWS credential болгон солино. GitHub-ийн AWS OIDC заавар энэ аргаар AWS credential-ийг GitHub secret-д байнга хадгалах шаардлагагүйг тайлбарладаг.

Аюулгүй байдлын гол тохиргоо нь role-д ямар repository, branch эсвэл environment хандаж болохыг тогтоох trust policy юм. Зөвхөн токен хүсэх зөвшөөрөл нэмээд role-ийг өргөн хүрээнд нээлттэй үлдээвэл өөр job түр AWS эрх авах боломжтой. AWS-д хийж болох үйлдлийг role-ийн тусдаа permission policy хязгаарлах тул нэвтрэх нөхцөл болон нөөцийн эрхийг хоёуланг нь тохируулна.

IAM-д OIDC provider ба deploy role үүсгэх

AWS IAM-ийн Identity providers хэсэгт OpenID Connect provider нэмнэ. Provider URL нь https://token.actions.githubusercontent.com, албан ёсны AWS action ашиглах үеийн Audience нь sts.amazonaws.com байна. AWS-ийн OIDC provider үүсгэх заавар нь audience токены aud утгатай таарах ёстойг, provider бүртгэсний дараа түүнд итгэх IAM role шаардлагатайг заадаг. Тухайн AWS account-д GitHub provider бүртгэлтэй бол URL болон audience-ийг нь шалгаж, давхар бүртгэхгүй.

Provider нь GitHub-ээс ирсэн токеныг таних суурь холбоос болохоос AWS нөөцийн эрх биш. Deploy role-д зөвхөн тухайн ажилд хэрэгтэй үйлдэл, нөөцийг заасан permission policy холбоно. Жишээлбэл, нэг S3 bucket-д файл байршуулдаг job-д account даяарх администраторын эрх хэрэггүй. Ижил provider-ийг ашигладаг өөр repository эсвэл өөр deployment зорилгод тусдаа role өгвөл тэдний trust болон AWS эрхийг бие даан хязгаарлаж болно.

Trust policy-д repository, branch эсвэл environment-ийг заах

Role-ийн trust policy-д GitHub provider-ийн ARN-г Federated principal, sts:AssumeRoleWithWebIdentity-г action болгон оруулна. AWS-ийн GitHub OIDC role-ийн заавар sub нөхцөлөөр тодорхой repository эсвэл branch-ийг хязгаарлахыг зөвлөдөг. IAM нь GitHub provider-д итгэдэг role-ийн sub нөхцөл байхыг шаарддаг ч repository доторх бүх branch-ийг зөвшөөрсөн wildcard-ийг таны өмнөөс нарийсгахгүй.

Дараах нь нөхцөлт жишээ: ORG, REPO болон main-ийг өөрийн утгаар солино. Environment ашигладаггүй, sub утгадаа owner болон repository-ийн ID нэмээгүй job-д trust policy-ийн Condition хэсгийг {"StringEquals":{"token.actions.githubusercontent.com:aud":"sts.amazonaws.com","token.actions.githubusercontent.com:sub":"repo:ORG/REPO:ref:refs/heads/main"}} гэж тохируулна. StringEquals нь заасан утгатай яг таарахыг шаардана; repo:ORG/REPO:* гэсэн нөхцөлөөс ялгаатай нь өөр branch болон environment-ийн job-ийг зөвшөөрөхгүй.

GitHub-ийн зарим repository-д sub утгад өөрчлөгдөхгүй owner болон repository-ийн ID ордог. Тийм repository-д бодит утга нь repo:ORG@OWNER_ID/REPO@REPO_ID:ref:refs/heads/main хэлбэртэй тул нэрээр бичсэн өмнөх жишээтэй таарахгүй. Trust policy-г өөрийн repository-ийн sub хэлбэрт нийцүүл; тааруулахын тулд wildcard нэмбэл хязгаар өргөснө.

Deploy job environment: prod ашигладаг бол branch-ийн оронд repo:ORG/REPO:environment:prod гэсэн sub утгыг trust policy-д тавина. Энэ утга environment-ийн нэрийг заадаг бөгөөд аль branch түүнд хүрч болохыг өөрөө шийдэхгүй. GitHub environment-д зөвшөөрөгдсөн deployment branch эсвэл tag-ийг тохируулж, шаардлагатай бол approval хамгаалалт нэмнэ. ID агуулдаг repository-д environment-ийн жишээний owner болон repository хэсгийг мөн бодит ID-тай хэлбэрээр солино.

Deploy job-ийн YAML зөвшөөрөл ба AWS нэвтрэлт

AWS-д нэвтрэх job-ийн permissions хэсэгт id-token: write өгнө. Кодыг actions/checkout-оор татдаг бол contents: read нэмсэн permissions: {id-token: write, contents: read} нь YAML-ийн товч бичлэг болно. Энэ зөвшөөрлийг бүх workflow-д биш, AWS эрх шаардлагатай job-д байрлуулж, бусад GITHUB_TOKEN эрхийг ажлын хэрэгцээгээр нь хязгаарла. id-token: write нь AWS нөөц дээр бичих эрх биш; зөвхөн OIDC токен хүсэх боломж юм.

Credential тохируулах алхамд aws-actions/configure-aws-credentials ашиглаж, role-to-assume-д deploy role-ийн ARN, aws-region-д ажиллах бүсийг өгнө. Action-ийг хянаж сонгосон бүтэн commit SHA-д бэхлэх нь дараагийн release гарлаа гээд workflow өөр код ажиллуулахаас сэргийлнэ. Дараагийн алхамд aws sts get-caller-identity ажиллуулж, буцсан AWS account болон role төлөвлөсөн утгатай таарч буйг шалгаж болно; энэ командын гаралт нь deploy хийх permission зөв эсэхийг дангаараа батлахгүй.

Workflow-ийн on: {push: {branches: [main]}} гэх мэт trigger нь job хэзээ эхлэхийг хязгаарлана. Харин AWS trust policy нь эхэлсэн job-ийн OIDC токен role ашиглаж болох эсэхийг тусад нь шийддэг. Иймээс зөвхөн trigger-ийн branch шүүлтүүрт найдахгүй: ижил repository дахь өөр workflow ч role авахыг оролдож болно. Role-ийн permission policy-г хязгаарлах шаардлага мөн хэвээр үлдэнэ, учир нь зөвшөөрөгдсөн job авсан түр credential-ээрээ тэр policy-д багтсан үйлдлүүдийг хийж чадна.

Байнгын key-ээс шилжих дараалал

1. Одоогийн AWS access key-г ашигладаг workflow, job болон бусад хэрэглэгчийг тогтоо. Нэг key хэд хэдэн ажилд ашиглагддаг бол ганц workflow-г шилжүүлээд устгаж болохгүй.
2. OIDC provider, deploy role, нарийн trust policy үүсгэ. Role-ийн permission policy-д хуучин хэрэглэгчийн бүх эрхийг хуулалгүй, deployment-д хэрэгтэй AWS үйлдэл ба нөөцийг сонго.
3. Нэг deploy job-ийн AWS алхмыг OIDC action руу шилжүүл. aws-access-key-id болон aws-secret-access-key input-уудыг авч, job-ийн permissions, role ARN, region болон шаардлагатай environment-ийг тохируул.
4. Зөвшөөрсөн branch эсвэл хамгаалсан environment-ээс job ажиллуулж, AWS identity болон deployment-ийн үр дүнг шалга. Зөвшөөрөгдөх ёсгүй branch, repository эсвэл environment role авч чадахгүй байгааг мөн нягтал.
5. Бүх хэрэглэгч шилжсэний дараа хуучин key-г IAM-д идэвхгүй болгож, түүнээс хамаарах ажил үлдээгүйг шалгаад устга. GitHub дахь хуучин secret-ийн утгыг мөн арилга.

Нэвтрэлт саатвал яаж буцах вэ

Role авах алхам амжилтгүй болбол provider ARN, audience, role ARN болон бодит sub утгыг trust policy-тэй тулга. Branch-д зориулсан :ref:refs/heads/main нөхцөл environment ашигласан job-ийн :environment:prod утгатай таарахгүй. Role амжилттай авсан ч deployment бүтэлгүйтвэл trust нөхцөлийг сулруулахаасаа өмнө role-ийн permission policy-д шаардлагатай AWS үйлдэл, нөөц байгаа эсэхийг шалга.

Шилжилтийн турш хуучин key идэвхтэй хэвээр бол deployment саатахад өмнөх workflow хувилбар руу түр буцаж болно. Key-г идэвхгүй болгосон бол эрх бүхий AWS администратор шаардлагатай үед түүнийг түр сэргээж чадна; устгасан key-г буцааж идэвхжүүлэх боломжгүй. Иймээс устгах алхмыг зөв branch эсвэл environment-ээс OIDC deployment ажиллаж, хуучин key-г ашигладаг бусад ажил үлдээгүйг тогтоосны дараа хийнэ.

Мөн уншаарай:

• n8n-ийг өөрийн серверт байрлуулах нь: нэг encryption key бүх нууцыг аварна
• AWS-ийн хөнгөлөлтөд шууд бүү түгж: ашиглаагүй цаг буцаад ирэхгүй
• GitHub Actions эсвэл GitLab CI: ижил pipeline 91 секундээр зөржээ