A CI/CD service deploys resources into AWS.
Obtain time-limited permissions for each run without storing a long-term access key.
Which design is most appropriate?
Let the CI/CD principal assume an IAM role through AWS STS and use temporary credentials for the deployment.
Detailed explanation
Role assumption issues short-lived credentials and avoids storing a long-term deployment key.
Role assumption issues short-lived credentials and avoids storing a long-term deployment key.
Public access does not restrict deployment to the CI/CD principal.
Public access does not restrict deployment to the CI/CD principal.
A cache key controls content behavior and is not an AWS API credential.
A cache key controls content behavior and is not an AWS API credential.
A root credential is unnecessarily powerful and dangerous to keep in an automation system.
A root credential is unnecessarily powerful and dangerous to keep in an automation system.
Check official documentation
Compare the following points with the official documentation.
AWS STS AssumeRoleとIAMロールの公式説明を確認する。
What to confirm
自動化サービスへ一時認証情報を提供できる。
Key points
- IAM role
- AWS STS
- Temporary credentials
Notes
- Environment: AWS公式IAM・STSドキュメントの確認
- Confirm current AWS service behavior in the official documentation.
Foundation review
Ephemeral authorization
Each pipeline run receives a bounded session instead of sharing a persistent secret.
Automation trust
The role trust policy identifies the CI/CD principal while its permissions policy defines deployment actions.