AutoScaling using an AMI created in another account

0

When attempting to use Autoscale to launch Instances in one account (acct2) that are using an AMI in another account (acct1) , I run into the following error (seen on the terminated instance)
State transition reason: Server.InternalError
State transition message: Client.InternalError: Client error on launch

Is there an exact location I can put the suggested policy? which will allow me to run the 'aws kms create-grant ' as documented? I see they give the policy, but it's not 100% clear where this applies and all my attempts have failed.

Keep in mind, These AMI's are successfully launched in acct1 if I do it manually.

Below are the details of everything I have done

Hello,

I am attempting to use an autoscaling group in account (acct2) 051878XXXXXX which is using an encrypted AMI ami-04eeff30998ec5863 which belongs to account (acct1) 535298XXXXXX

I am having problems with getting the AMI to unencrypt. We are able to use the AMI in that acct2 for regular EC2 launches, just not autoscaling.

The details for some of the steps taken are below.

The initial and current issue is our servers end up with the following error:
State transition reason
Server.InternalError
State transition message
Client.InternalError: Client error on launch

Uppon hitting that error, we search for Amazon provided documentation on what needs to be done for autoscaling

https://docs.aws.amazon.com/autoscaling/ec2/userguide/key-policy-requirements-EBS-encryption.html
https://aws.amazon.com/premiumsupport/knowledge-center/kms-launch-ec2-instance/

This Auto Scaling Group
arn:aws:autoscaling:us-west-2:051878XXXXXX:autoScalingGroup:ed7799a5-7a00-4667-93be-44317df73960:autoScalingGroupName/prod-marvin-2021-44-2-AutoScalingGroup-LO2L18YDTGR7

Several attempts were made to get this to work

  1. The policy key for the principle
    "arn:aws:sts::051878XXXXXX:assumed-role/OrganizationAccountAccessRole/awsmfa_20211104T135016"
    action "kms:Create*"

  2. I added to arn:aws:iam::05187XXXXXX:role/OrganizationAccountAccessRole (Since REmoved)
    The policy KMSPolicyForAutoScaling
    "Statement": [
    {
    "Sid": "Test",
    "Effect": "Allow",
    "Action": "kms:CreateGrant",
    "Resource": "arn:aws:kms:us-west-2:535298XXXXXX:key/b9b06a39-f963-4786-a66b-df5f1aXXXXXX"
    }

  3. I added this policy directly to our MFA policy (Since removed)
    arn:aws:iam::535298XXXXXX:policy/SwitchboardAdministratorWithMfa
    {
    "Sid": "testkms",
    "Effect": "Allow",
    "Action": "kms:CreateGrant",
    "Resource": "arn:aws:kms:us-west-2:535298XXXXXX:key/b9b06a39-f963-4786-a66b-df5f1ab5a97f"
    }

  4. Here is the attempt to grant the permission from account 051878XXXXXX
    I get the failure An error occurred (AccessDeniedException) when calling the CreateGrant operation:

aws kms create-grant --region us-west-2 --key-id arn:aws:kms:us-west-2:535298XXXXXX:key/b9b06a39-f963-4786-a66b-df5f1aXXXXXX --grantee-principal arn:aws:iam::051878507259:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling --operations "Encrypt" "Decrypt" "ReEncryptFrom" "ReEncryptTo" "GenerateDataKey" "GenerateDataKeyWithoutPlaintext" "DescribeKey" "CreateGrant"

Here is the cloudtrail showing the failure.
"eventSource": "kms.amazonaws.com",
"eventName": "CreateGrant",
"awsRegion": "us-west-2",
"sourceIPAddress": "99.88.41.224",
"userAgent": "aws-cli/2.0.48 Python/3.7.4 Darwin/20.6.0 exe/x86_64 command/kms.create-grant",
"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:sts::051878XXXXXX:assumed-role/OrganizationAccountAccessRole/awsmfa_20211104T142204 is not authorized to perform: kms:CreateGrant on resource: arn:aws:kms:us-west-2:535298210113:key/b9b06a39-f963-4786-a66b-df5f1aXXXXXX because no resource-based policy allows the kms:CreateGrant action",

  1. I also attempted to grant the permission (step 4) from the root login to account 051878507259 as well but to no avail.
Zsolt
질문됨 3년 전1058회 조회
1개 답변
0

This was resolved. by revisiting this set of steps and instead of integrating the permissions given with the permissions listed in
Example 2: Key policy sections that allow cross-account access to the customer managed key
We actually added the permissions verbatim with Example 2 (changing out the external and managed key accounts with our values).

This allowed the next step of running the grant from the command-line to properly work.

Zsolt
답변함 2년 전

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.

질문 답변하기에 대한 가이드라인

관련 콘텐츠