configure aws credentials
v4.0.2
قم بتكوين بيانات اعتماد AWS الخاصة بك ومتغيرات بيئة المنطقة للاستخدام في إجراءات GitHub الأخرى.
ينفذ هذا الإجراء سلسلة AWS JavaScript SDK Creditive Consolution وتصدير متغيرات بيئة الجلسة لاستخدام أفعالك الأخرى. يتم اكتشاف صادرات متغير البيئة من قبل كل من AWS SDKs و AWS CLI لمكالمات API AWS.
يجب توقيع مكالمات API إلى AWS بمعلومات بيانات الاعتماد ، لذلك عندما تستخدم أحد AWS SDKs أو أداة AWS ، يجب أن تزودها ببيانات اعتماد AWS ومنطقة AWS. تتمثل إحدى طرق القيام بذلك في إجراءات GitHub في استخدام سر مستودع مع بيانات اعتماد IAM ، ولكن هذا لا يتبع إرشادات أمان AWS حول استخدام بيانات الاعتماد طويلة الأجل. بدلاً من ذلك ، نوصي باستخدام بيانات اعتماد طويلة الأجل أو JWT لجلب بيانات اعتماد مؤقتة ، واستخدامها مع أدواتك بدلاً من ذلك. هذا العمل github يسهل ذلك.
AWS SDKs والأدوات تبحث عن بيانات الاعتماد الخاصة بك في متغيرات البيئة الموحدة. في جوهرها ، يمر هذا الإجراء من خلال تدفق دقة الاعتماد القياسية ، وفي النهاية ، يصدر متغيرات البيئة لك لاستخدامها لاحقًا.
نحن ندعم خمس طرق لجلب بيانات الاعتماد من AWS ، لكننا نوصيك باستخدام موفر OIDC الخاص بـ Github بالتزامن مع نقطة نهاية موفر هوية AWS IAM.
لمزيد من المعلومات حول كيفية القيام بذلك ، تابع القراءة.
قد تكون بعض هذه الوثائق غير دقيقة إذا كنت تستخدم GHES (GitHub Enterprise Server) ، يرجى ملاحظة ملاحظة وثائق GitHub عند ذات صلة.
على سبيل المثال ، فإن عنوان URL الذي تم إصداره من OIDC JWT يختلف عن token.actions.githubusercontent.com المعتاد. نتيجة لذلك ، ستحتاج إلى تكوين هذا بشكل مختلف عند إنشاء مزود الهوية.
ليس لدينا حاليًا بيئة اختبار GHES للتحقق من صحة هذا الإجراء. إذا كنت تعمل في GHEs وتواجه مشاكل ، فيرجى إخبارنا بذلك.
نوصي باتباع أفضل ممارسات Amazon IAM لأوراق اعتماد AWS المستخدمة في سير عمل إجراءات GitHub ، بما في ذلك:
هناك خمس طرق مختلفة مدعومة لاسترداد بيانات الاعتماد:
AssumeRoleWithWebIdentity )AssumeRole )AssumeRoleWithWebIdentity )AssumeRole )نظرًا لأننا نستخدم AWS JavaScript SDK ، سنستخدم دائمًا تدفق دقة بيانات الاعتماد لـ Node.js. اعتمادًا على مدخلاتك ، قد يتجاوز الإجراء أجزاء من هذا التدفق.
نوصي باستخدام الخيار الأول أعلاه: موفر Github's OIDC. تستخدم هذه الطريقة OIDC للحصول على بيانات اعتماد قصيرة الأجل اللازمة لأفعالك. راجع OIDC لمزيد من المعلومات حول كيفية إعداد حساب AWS الخاص بك لتولي دور مع OIDC.
يصف الجدول التالي الطريقة التي سنستخدمها للحصول على بيانات الاعتماد الخاصة بك بناءً على القيم التي يتم توفيرها إلى الإجراء:
| الهوية المستخدمة | aws-access-key-id | role-to-assume | web-identity-token-file | role-chaining | إذن id-token |
|---|---|---|---|---|---|
| [✅ الموصى به] افترض دورًا مباشرة باستخدام مزود GitHub OIDC | ✔ | ✔ | |||
| مستخدم أنا | ✔ | ||||
| افترض دورًا باستخدام بيانات اعتماد المستخدم IAM | ✔ | ✔ | |||
| افترض دورًا باستخدام بيانات اعتماد ملف WebIdentity Token | ✔ | ✔ | |||
| افترض دورًا باستخدام بيانات الاعتماد الحالية | ✔ | ✔ |
ملاحظة: لا يكون role-chaining ضروريًا دائمًا لاستخدام بيانات الاعتماد الحالية. إذا كنت تحصل على خطأ "بيانات الاعتماد التي تم تحميلها بواسطة SDK لا تتطابق مع" ، فحاول تمكين هذا الخيار.
انظر Action.yml لمزيد من التفاصيل.
| خيار | وصف | مطلوب |
|---|---|---|
| AWS-Region | أي منطقة AWS لاستخدامها | نعم |
| دور | دور لجلب أوراق الاعتماد. مطلوب فقط لبعض أنواع المصادقة. | لا |
| AWS-Access-Key-ID | AWS مفتاح الوصول للاستخدام. مطلوب فقط لبعض أنواع المصادقة. | لا |
| AWS-Secret-Access-Key | AWS المفتاح السري للاستخدام. مطلوب فقط لبعض أنواع المصادقة. | لا |
| AWS-SESSE-TOKEN | رمز جلسة AWS للاستخدام. تستخدم في سيناريوهات المصادقة غير المألوفة. | لا |
| التزايد الأدوار | استخدم بيانات الاعتماد الحالية من البيئة لتولي دور جديد. | لا |
| جمهور | جمهور JWT عند استخدام OIDC. تستخدم في أقسام AWS غير الافتراضية ، مثل مناطق الصين. | لا |
| http-proxy | وكيل HTTP لاستخدامه لمكالمات API. | لا |
| معرف الحكم القناع | لا تعتبر معرفات حساب AWS سرية. سيؤدي تحديد هذا إلى إخفاء معرفات الحساب من الإخراج على أي حال. | لا |
| المدة الثانية ثانية | مدة الدور المفترضة في الثواني ، إذا افتراض دور. الافتراضات إلى 1 ساعة. | لا |
| معرف الأدوار | المعرف الخارجي للدور الذي يجب افتراضه. مطلوب فقط إذا كان دورك يتطلب ذلك. | لا |
| اسم الدور | الإعدادات الافتراضية إلى "githubactions" ، ولكن قد يتم تغييرها إذا لزم الأمر. | لا |
| دوران في جلسة التزلج على الأدوار | تخطي جلسة العلامات إذا تم تعيينها. | لا |
| ضمن الجلسة السياسية | يمكنك تقييد سياسة الدور المفترضة من خلال تحديد سياسة مضمنة هنا. | لا |
| المدارس | يمكنك تقييد سياسة الدور المفترضة من خلال تحديد سياسة مُدارة هنا. | لا |
| الإخراج-الالتزام | عند التعيين ، جلبت المخرجات بيانات الاعتماد كخطوة عمل. الإعدادات الافتراضية إلى خطأ. | لا |
| غير متداولات غير مهتمة | عند تعيين ، يحاول إلغاء ضبط أي بيانات اعتماد موجودة في عداء الإجراء الخاص بك. | لا |
| تعطيل الترجع | معاق إعادة المحاولة/منطق التراجع لتولي مكالمات الدور. بشكل افتراضي ، يتم تمكين إعادة المحاولة. | لا |
| إعادة المحاولة | يحد من عدد محاولات إعادة المحاولة قبل الاستسلام. الافتراضات إلى 12. | لا |
| شحنات خاصة-Workaround | من غير المألوف ، أن بعض البيئات لا يمكنها تحمل الشخصيات الخاصة في مفتاح سري. سيؤدي هذا الخيار إلى إعادة محاولة جلب بيانات الاعتماد حتى لا يحتوي مفتاح الوصول السري على أحرف خاصة. يتجاوز هذا الخيار تعطيل الترجع وإعادة المحاكاة. | لا |
مدة الجلسة الافتراضية هي ساعة واحدة .
إذا كنت ترغب في ضبط هذا ، فيمكنك نقل المدة إلى role-duration-seconds ، ولكن لا يمكن أن تتجاوز المدة الحد الأقصى الذي تم تعريفه عند إنشاء دور IAM.
إذا كان دورك يتطلب معرفًا خارجيًا لتوليه ، فيمكنك تزويد المعرف الخارجي بإدخال role-external-id
اسم الجلسة الافتراضي هو "githubactions" ، ويمكنك تعديله من خلال تحديد الاسم المطلوب في role-session-name . سيتم وضع علامة على الجلسة مع العلامات التالية: (راجع وثائق Github لتعريفات متغير البيئة GITHUB_ )
| مفتاح | قيمة |
|---|---|
| جيثب | "الإجراءات" |
| مستودع | github_repository |
| سير العمل | github_workflow |
| فعل | github_action |
| ممثل | github_actor |
| فرع | github_ref |
| يقترف | github_sha |
ملاحظة: يجب أن تتوافق جميع قيم العلامات مع متطلبات العلامة. على وجه الخصوص ، سيتم اقتطاع GITHUB_WORKFLOW إذا كانت طويلة جدًا. إذا كانت GITHUB_ACTOR أو GITHUB_WORKFLOW تحتوي على أحرف غير صالحة ، فسيتم استبدال الأحرف بـ '*'.
سيستخدم الإجراء وضع علامات على الجلسة افتراضيًا أثناء افتراض الأدوار ، إلا إذا اتبعت توصيتنا وتولى دور مع WebIdentity. بالنسبة لافتراض دور WebIdentity ، يجب تضمين علامات الجلسة في رمز الويب المشفر. هذا يعني أنه لا يمكن توفير العلامات إلا من قبل مزود OIDC ، ولا يمكن تعيينها خلال مكالمة API AmerOleWithWithWitionIdentity ضمن الإجراء. انظر #419 لمزيد من المعلومات.
يمكنك تخطي علامة الجلسة هذه من خلال توفير role-skip-session-tagging كما هو صحيح في مدخلات الإجراء:
uses : aws-actions/configure-aws-credentials@v4
with :
role-skip-session-tagging : trueسياسات الجلسة غير مطلوبة ، لكنها تسمح لك بالحد من نطاق بيانات الاعتماد التي تم جلبها دون إجراء تغييرات على أدوار IAM. يمكنك تحديد سياسات الجلسة المضمنة في ملف سير العمل الخاص بك ، أو الرجوع إلى سياسة الجلسة المدارة الحالية بواسطة ARN.
سياسة IAM بتنسيق JSON المترابط الذي تريد استخدامه كسياسة جلسة مضمنة. اعتمادًا على التفضيلات ، يمكن كتابة JSON على سطر واحد مثل هذا:
uses : aws-actions/configure-aws-credentials@v4
with :
inline-session-policy : ' {"Version":"2012-10-17","Statement":[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:List*","Resource":"*"}]} 'أو يمكننا الحصول على JSON منسقة بشكل جيد أيضًا:
uses : aws-actions/configure-aws-credentials@v4
with :
inline-session-policy : >-
{
"Version": "2012-10-17",
"Statement": [
{
"Sid":"Stmt1",
"Effect":"Allow",
"Action":"s3:List*",
"Resource":"*"
}
]
} أسماء موارد Amazon (ARNS) للسياسات المدارة IAM التي تريد استخدامها كسياسات جلسة مدارة. يجب أن توجد السياسات في نفس حساب الدور. يمكنك تمرير سياسة واحدة مُدارة مثل هذا:
uses : aws-actions/configure-aws-credentials@v4
with :
managed-session-policies : arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccessويمكننا تمرير سياسات مُدارة متعددة مثل هذا:
uses : aws-actions/configure-aws-credentials@v4
with :
managed-session-policies : |
arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
arn:aws:iam::aws:policy/AmazonS3OutpostsReadOnlyAccess يمكنك الآن تكوين إعدادات إعادة المحاولة عند فشل استدعاء STS. بشكل افتراضي ، نقوم بإعادة المحاولة مع التراجع الأسي 12 مرة. يمكنك تعطيل هذا السلوك تمامًا عن طريق ضبط إدخال disable-retry إلى true ، أو يمكنك تكوين عدد المرات التي يعيد فيها إعادة محاكاة الإدخال مع إدخال retry-max-attempts .
لا يتم إخفاء معرف حسابك افتراضيًا في سجلات سير العمل لأنه لا يعتبر معلومات حساسة. ومع ذلك ، يمكنك تعيين إدخال mask-aws-account-id إلى true لإخفاء معرف حسابك في سجلات سير العمل إذا رغبت في ذلك.
في بعض الأحيان ، يمكن أن تعترض أوراق الاعتماد الحالية في عداءك النتيجة المقصودة. يمكنك تعيين مدخلات unset-current-credentials على true للعمل حول هذه المشكلة.
بعض حالات الحافة غير قادرة على تحليل AWS_SECRET_ACCESS_KEY بشكل صحيح إذا كانت تحتوي على أحرف خاصة. لمزيد من المعلومات ، يرجى الاطلاع على وثائق AWS CLI. إذا قمت بتعيين الخيار special-characters-workaround ، فإن هذا الإجراء سيقوم باستمرار بإعادة محاكمة بيانات الاعتماد حتى نحصل على واحدة لا تحتوي على شخصيات خاصة. يتجاوز هذا الخيار خيارات disable-retry والاسترداد retry-max-attempts . نوصيك بعدم تمكين هذا الخيار ما لم يكن مطلوبًا ، لأن إعادة محاولة واجهات برمجة التطبيقات بلا حدود حتى تنجح ليست أفضل الممارسات.
نوصي باستخدام مزود OIDC الخاص بـ Github للحصول على بيانات اعتماد AWS قصيرة الأجل اللازمة لأفعالك. عند استخدام OIDC ، تقوم بتكوين IAM لقبول JWTS من نقطة نهاية Github's OIDC. سيقوم هذا الإجراء بعد ذلك بإنشاء JWT فريد من نوعه في تشغيل سير العمل باستخدام نقطة نهاية OIDC ، وسيستخدم JWT لتولي الدور المحدد مع بيانات الاعتماد قصيرة الأجل.
للحصول على هذا للعمل
قم بتكوين سير العمل الخاص بك لاستخدام id-token: write إذن.
تكوين جمهورك ، إذا لزم الأمر.
في حساب AWS الخاص بك ، قم بتكوين IAM للثقة في مزود هوية Github OIDC.
تكوين دور IAM مع حدود المطالبة المناسبة ونطاق الإذن.
ملاحظة : تم الإبلاغ عن تسمية دورك "githubactions" لعدم العمل. انظر #953.
حدد هذا الدور ARN عند إعداد هذا الإجراء.
أولاً ، لكي ينشئ هذا الإجراء JWT ، يجب أن يكون ملف سير العمل الخاص بك يحتوي على id-token: write :
permissions :
id-token : write
contents : read عند إنشاء JWT ، يجب تحديد الجمهور. عادة ، ستستخدم sts.amazonaws.com ، وهذا الإجراء يستخدم هذا افتراضيًا إذا لم تحدد واحدة. هذا سوف يعمل في معظم الحالات. قد يكون تغيير الجمهور الافتراضي أمرًا ضروريًا عند استخدام أقسام AWS غير الافتراضية ، مثل مناطق الصين. يمكنك تحديد الجمهور من خلال مدخلات audience :
- name : Configure AWS Credentials for China region audience
uses : aws-actions/configure-aws-credentials@v4
with :
audience : sts.amazonaws.com.cn
aws-region : us-east-3
role-to-assume : arn:aws-cn:iam::123456789100:role/my-github-actions-roleلاستخدام مزود OIDC الخاص بـ Github ، يجب عليك أولاً إعداد الاتحاد مع المزود باعتباره IAM IDP. يجب إنشاء مزود GitHub OIDC مرة واحدة فقط لكل حساب (أي أدوار IAM المتعددة التي يمكن افتراضها من قبل OIDC من Github يمكنها مشاركة موفر OIDC واحد). فيما يلي نموذج نموذج CloudFormation الذي سيقوم بتكوين هذه الثقة لك.
لاحظ أنه تم ضبط Thumbprint أدناه على جميع F لأن Thumbprint لا يتم استخدامه عند مصادقة token.actions.githubusercontent.com . هذه حالة خاصة تستخدم فقط عندما تقوم Github's OIDC بالتوثيق مع IAM . تستخدم IAM مكتبتها من CAS الموثوق بها للمصادقة. القيمة لا تزال واجهة برمجة التطبيقات ، لذلك يجب تحديدها.
يمكنك نسخ القالب أدناه ، أو تحميله من هنا: https://d38mtn6aq9zhn6.cloudfront.net/configure-aws-credentials-latest.yml
Parameters :
GitHubOrg :
Description : Name of GitHub organization/user (case sensitive)
Type : String
RepositoryName :
Description : Name of GitHub repository (case sensitive)
Type : String
OIDCProviderArn :
Description : Arn for the GitHub OIDC Provider.
Default : " "
Type : String
OIDCAudience :
Description : Audience supplied to configure-aws-credentials.
Default : " sts.amazonaws.com "
Type : String
Conditions :
CreateOIDCProvider : !Equals
- !Ref OIDCProviderArn
- " "
Resources :
Role :
Type : AWS::IAM::Role
Properties :
AssumeRolePolicyDocument :
Statement :
- Effect : Allow
Action : sts:AssumeRoleWithWebIdentity
Principal :
Federated : !If
- CreateOIDCProvider
- !Ref GithubOidc
- !Ref OIDCProviderArn
Condition :
StringEquals :
token.actions.githubusercontent.com:aud : !Ref OIDCAudience
StringLike :
token.actions.githubusercontent.com:sub : !Sub repo:${GitHubOrg}/${RepositoryName}:*
GithubOidc :
Type : AWS::IAM::OIDCProvider
Condition : CreateOIDCProvider
Properties :
Url : https://token.actions.githubusercontent.com
ClientIdList :
- sts.amazonaws.com
ThumbprintList :
- ffffffffffffffffffffffffffffffffffffffff
Outputs :
Role :
Value : !GetAtt Role.Arn للتوافق مع أفضل ممارسة Amazon IAM المتمثلة في منح أقل امتيازًا ، يجب أن تحتوي وثيقة سياسة الدور على Condition يحدد موضوعًا ( sub ) يسمح له بتولي الدور. يوصي Github أيضًا بالتصفية للجمهور الصحيح ( aud ). راجع وثائق AWS IAM حول الادعاءات التي يمكنك تصفية في سياسات الثقة الخاصة بك.
بدون شرط موضوع ( sub ) ، يمكن لأي مستخدم أو مستودع GitHub أن يتولى الدور. يمكن تحديد الموضوع إلى منظمة GitHub ومستودع كما هو موضح في قالب السحاب. ومع ذلك ، قد يتسبب تحديد النطاق إلى ORG و REPO في فشل افتراض الدور في بعض الحالات. انظر مثال على ادعاءات الموضوع للحصول على تفاصيل محددة حول قيمة الموضوع التي ستعتمد على سير العمل الخاص بك. يمكنك أيضًا تخصيص مطالبة الموضوع إذا كنت تريد التحكم الكامل في المعلومات التي يمكنك تصفيةها في سياسة الثقة الخاصة بك. إذا لم تكن متأكدًا من مفتاح موضوعك ( sub ) ، فيمكنك إضافة إجراء actions-oidc-debugger إلى سير العمل الخاص بك لمعرفة قيمة مفتاح الموضوع ( sub ) ، بالإضافة إلى المطالبات الأخرى.
يمكن إضافة شروط مطالبة إضافية لخصوصية أعلى كما هو موضح في وثائق GitHub. بسبب تفاصيل التنفيذ ، لا يتم دعم كل مطالبة OIDC حاليًا بواسطة IAM.
لمزيد من المعلومات حول إجراءات OIDC و GitHub ، يرجى الاطلاع على:
إذا قمت بتشغيل إجراءات github الخاصة بك في عداء مستضيف ذاتيًا يمكنه بالفعل الوصول إلى بيانات اعتماد AWS ، مثل مثيل EC2 ، فأنت لا تحتاج إلى توفير بيانات اعتماد مفتاح وصول المستخدم IAM إلى هذا الإجراء. سنستخدم أساليب قرار بيانات AWS JavaScript SDK القياسية للعثور على بيانات الاعتماد الخاصة بك ، لذلك إذا تمكنت AWS JS SDK من المصادقة على العداء ، فإن هذا الإجراء سيؤدي أيضًا إلى ذلك.
إذا لم يتم تقديم بيانات اعتماد مفتاح الوصول في مدخلات الإجراء ، فسيستخدم هذا الإجراء بيانات الاعتماد من بيئة العداء باستخدام الطرق الافتراضية لـ AWS SDK لـ JavaScript.
يمكنك استخدام هذا الإجراء ببساطة لتكوين المنطقة ومعرف الحساب في البيئة ، ثم استخدام بيانات اعتماد العداء لجميع مكالمات AWS API التي تم إجراؤها من خلال سير عمل الإجراءات:
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2في هذه الحالة ، يجب أن يكون لبيانات اعتماد عداءك أذونات للاتصال بأي واجهات برمجة التطبيقات AWS التي تسمى من خلال سير العمل الإجراءات الخاصة بك.
أو يمكنك استخدام هذا الإجراء لتولي دور ما ، ثم استخدام أوراق اعتماد الدور لجميع مكالمات API AWS التي تم إجراؤها بواسطة سير عمل الإجراءات:
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2
role-to-assume : my-github-actions-roleفي هذه الحالة ، يجب أن يكون لبيانات اعتماد عداءك أذونات لتولي الدور.
يمكنك أيضًا تولي دور باستخدام ملف رمز هوية الويب ، مثل استخدام Amazon EKS IRSA. يمكن للقرون التي تعمل في عقد العمال EKS التي لا تعمل كجذر استخدام هذا الملف لتولي دور بهوية ويب.
إذا لزم الأمر ، فاستخدم وكيل HTTP ، يمكنك تعيينه في الإجراء يدويًا.
بالإضافة إلى ذلك ، سينظر هذا الإجراء دائمًا في متغير بيئة HTTP_PROXY .
الوكيل المكون يدويًا:
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2
role-to-assume : my-github-actions-role
http-proxy : " http://companydomain.com:3128 "تم تكوين الوكيل في متغير البيئة:
# Your environment configuration
HTTP_PROXY= " http://companydomain.com:3128 " لا يقوم سير العمل هذا بتثبيت AWS CLI في بيئتك. يحتاج المتسابقون المستضيفون ذاتيًا الذين يعتزمون تشغيل هذا الإجراء قبل تنفيذ أوامر aws إلى تثبيت AWS CLI إذا لم يكن موجودًا بالفعل. يجب أن تتضمن معظم البيئات العداء التي استضافتها Github AWS CLI افتراضيًا.
- name : Configure AWS Credentials
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2
role-to-assume : arn:aws:iam::123456789100:role/my-github-actions-role
role-session-name : MySessionName في هذا المثال ، سيقوم الإجراء بتحميل رمز OIDC من متغير البيئة المقدمة من github واستخدامه لتولي دور arn:aws:iam::123456789100:role/my-github-actions-role مع اسم الجلسة MySessionName .
- name : Configure AWS Credentials
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2
role-to-assume : arn:aws:iam::123456789100:role/my-github-actions-role
role-session-name : MySessionName
- name : Configure other AWS Credentials
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2
role-to-assume : arn:aws:iam::987654321000:role/my-second-role
role-session-name : MySessionName
role-chaining : true في هذا المثال المكون من خطوتين ، ستستخدم الخطوة الأولى OIDC لتولي الدور arn:aws:iam::123456789100:role/my-github-actions-role كما هو الحال في المثال السابق. بعد ذلك ، ستستخدم الخطوة الثانية هذا الدور لتولي دور مختلف ، arn:aws:iam::987654321000:role/my-second-role .
- name : Configure AWS Credentials
uses : aws-actions/configure-aws-credentials@v4
with :
aws-access-key-id : ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key : ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region : us-east-2
role-to-assume : ${{ secrets.AWS_ROLE_TO_ASSUME }}
role-external-id : ${{ secrets.AWS_ROLE_EXTERNAL_ID }}
role-duration-seconds : 1200
role-session-name : MySessionName في هذا المثال ، يحتوي Secret AWS_ROLE_TO_ASSUME على سلسلة مثل arn:aws:iam::123456789100:role/my-github-actions-role . لتولي دور في نفس الحساب مثل بيانات الاعتماد الثابتة ، يمكنك ببساطة تحديد اسم الدور ، مثل role-to-assume: my-github-actions-role .
- name : Configure AWS Credentials 1
id : creds
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2
role-to-assume : arn:aws:iam::123456789100:role/my-github-actions-role
output-credentials : true
- name : get caller identity 1
run : |
aws sts get-caller-identity
- name : Configure AWS Credentials 2
uses : aws-actions/configure-aws-credentials@v4
with :
aws-region : us-east-2
aws-access-key-id : ${{ steps.creds.outputs.aws-access-key-id }}
aws-secret-access-key : ${{ steps.creds.outputs.aws-secret-access-key }}
aws-session-token : ${{ steps.creds.outputs.aws-session-token }}
role-to-assume : arn:aws:iam::123456789100:role/my-other-github-actions-role
- name : get caller identity2
run : |
aws sts get-caller-identity يوضح هذا المثال أنه يمكنك الرجوع إلى بيانات الاعتماد التي تم جلبها كمخرجات إذا تم ضبط output-credentials على TRUE. يوضح هذا المثال أيضًا أنه يمكنك استخدام مدخلات aws-session-token في موقف حيث يتم جلب الرموز المميزة للجلسة ونقلها إلى هذا الإجراء.
يتم توفير هذا الرمز بموجب ترخيص معهد ماساتشوستس للتكنولوجيا.
إذا كنت ترغب في الإبلاغ عن مشكلة أمنية محتملة في هذا المشروع ، فيرجى عدم إنشاء مشكلة GitHub. بدلاً من ذلك ، يرجى اتباع التعليمات هنا أو إرسال بريد إلكتروني إلى أمان AWS مباشرة.
