Cross account ssm param AMI ID updates.

[sholtomaud]

trafficstars

image-builder-lambda-update-ssm.py is nice if you only have one account and ImageBuilder is in that account.

But ImageBuilder pipelines offer AMI distribution accross accounts which is a typical use case.

Please update the example code to distribute the AMI IDs to SSM Params in a cross-account mode to show how the update of SSM Params takes place.

[mdgm88]

There are a few ways to do this, that I can think of:

One would be to use StackSets

Another would be to use an Advanced SSM parameter and RAM share it to other accounts: https://aws.amazon.com/about-aws/whats-new/2024/02/aws-systems-manager-parameter-store-cross-account-sharing/

[sholtomaud]

"ImageBuilder pipelines offer AMI distribution across accounts which is a typical use case."

"an Advanced SSM parameter" would probably be the mechanism the AWS ImageBuilder team could use to provide the complete solution.

As it stands, AMI distribution is a mess in AWS.

[EmmanuelTsouris]

Another way might be to use a step function which could assume a role in the target account and call the SSM parameter API, all using service integrations.

[austoonz]

A few weeks ago we launched integration with SSM Parameter Store. See the What's New post for more information, but this can do what you're asking.

You will need to provide a custom IAM Role for the execution, a Distribution Configuration can now include an SSM Parameter in each region.

[ctrahey]

@austoonz If you are or know the PM, I think there is a bug with the new setup (for which I'm excited!). The gist is that the managed permissions policy for Image Builder does not include ssm:putParameter. This would be minor, but I tried all the following:

1. Attach an additional policy to the managed role - not allowed
2. Attach the managed policy to a custom role - not allowed
3. Copy the JSON of the manage policy to a custom policy - too large and limit not adjustable
4. Hand edit the JSON to cut size in half, likely expanding permissions too much for comfort in the process, but ultimately achieving a size reduction that allows adding ssm:putParameter. Use this custom policy in a new role and set my pipeline to use that. Results pending (pipeline running as I type this and I am headed to bed ) - will follow up tomorrow.

[austoonz]

I've created a custom execution role for my use by doing the following. Not saying this is the best option, but simply what I had done for my account.

1. Create a new IAM Role
2. Set the trust policy to allow the "Service": "imagebuilder.amazonaws.com" access.
3. Copy the permissions from the AWSServiceRoleForImageBuilder service role and add them as an inline policy
4. Add new policies as required, eg I had additional policies to allow ssm:SendCommand and ssm:GetDocument to allow a custom workflow to invoke Run Command directly (eg to use the AWS-UpdateSSMAgent document), and policies for ssm:GetParameter and ssm:PutParameter to allow retrieving and updating SSM Parameters.
5. I use this role when creating an Image Pipeline, or when calling CreateImage directly.

If/when our service role is updated, it will not allow a global ssm:PutParameter, so even once that happens, you may require a custom role depending on the naming convention of the SSM parameters in use.

[ctrahey]

Yeah, this is really similar to what I did with one glaring exception: the JSON I found in my account's AWSServiceRoleForImageBuilder was 12kb, and my account's limit on policy size is about half that and reported as not adjustable. I achieved similar by removing many of the conditions and consolidating some enumerated permissions into wildcards. It did work! Naturally though I'll prefer a managed policy.

Was your AWSServiceRoleForImageBuilder much smaller than mine? I'm on version 20 circa 4 months ago.

[mdgm88]

I am on v20 too.

There was something in the documentation saying that a new version was released at the end of April, but I think that was published early in error.

I am waiting for a v21 to start using this new feature.