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
asked 3 years ago1087 views
1 Answer
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
answered 3 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions