- 최신
- 최다 투표
- 가장 많은 댓글
If you create a profile through SSO using the AWS CLI with aws configure sso
[1], you should be able to then use this profile name within Terraform, either by setting it within the Terraform provider [2], or by setting the AWS_PROFILE
environment variable in the shell before you run terraform apply
.
[1] https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html#sso-configure-profile-auto [2] https://registry.terraform.io/providers/hashicorp/aws/latest/docs#shared-configuration-and-credentials-files
The existing answers are good, I'm just going to give you a warning about actually using Terraform + AWS SSO... The role that is used to create resources in AWS will be the owner of certain resources (like your EKS cluster). This situation is worse with KMS keys! if your SSO administrator deletes and recreates the permissions set that Terraform uses, you could be left with KMS keys that you have no access to. I ran into this! The AWS Identity Center permissions sets got refactored, and the KMS keys that were created via the terraform-aws-modules/eks module were left 'orphaned'. Not even the root account can recover these. I need to contact AWS Support, but since this is not a production account I do not have it on a paid support plan. (AWS Support, unlike Billing, is not consolidated under an AWS Organization, it's a per-account charge)
Just authenticate and export the AWS_PROFILE, terraform will automatically use the temporary credentials you obtained stating ss login in the CLI.
To operate on different account do as usual, using multiple profiles aliases.
If you use ControlTower you need to deploy a custom role, moreover the use of AWS_PROFILE in team is a mess because you must have the same profile name set on each local machine that run that code. Also in a pipeline could be a problem.
관련 콘텐츠
- AWS 공식업데이트됨 일 년 전
I am interested in why the KMS keys could not be recovered.
AFAICT KMS keys do not themselves have the notion of a role owner. I could see how a key policy might be constructed to deny administrative rights to the key to everyone but the role that created the policy &/or key and if this role is deleted, then problems ensue.
Would the answer in this case, not to run terraform directly from an SSO managed role, but instead use the SSO-managed role to acquire a permanent role managed via other means that is never deleted in this way?
I am guessing the gotcha was using SSO roles exclusively for the key owner and key administrator parameters of this terraform module https://github.com/terraform-aws-modules/terraform-aws-kms
key_owners = ["arn:aws:iam::012345678901:role/owner"] key_administrators = ["arn:aws:iam::012345678901:role/admin"] key_users = ["arn:aws:iam::012345678901:role/user"] key_service_users = ["arn:aws:iam::012345678901:role/ec2-role"]
Is the take away, to take care to ensure the owner set always includes at least one role that is not managed by AWS Identity Center?