Instances might have to call certain API actions or access certain resources during an AWS Systems Manager Automation execution. What if you don’t want to apply the additional permissions to the instance’s existing instance profile?
In this post, I show you how to provide temporary permissions to instances when executing an Automation within the document content. First, I create an example custom IAM policy. Then, I demonstrate how this policy can be used within the Automation document to create a temporary instance profile. The profile is attached to the target instances during Automation execution and removed at the end of the execution.
AWS Systems Manager provides the AmazonSSMManagedInstanceCore managed IAM policy that enables an instance to use Systems Manager core service functionality when added to an instance profile. Depending on the Automation workflow, additional permissions may be required to successfully execute that Automation document.
By creating dedicated IAM policies for each Automation workflow, you can incorporate instance profile creation and attachment in custom Automation documents for the target instances, without modifying the existing instance profiles.
This can be helpful if you prefer to avoid modifying instance profiles that are attached to instances long term. The instance profiles only contain the core permissions required for Systems Manager functionality but have Automations that require access to resources like Amazon S3 or AWS KMS.
For example, I’ve created a custom IAM policy named expandedPermissionsForAutomation that contains expanded permissions for S3, which can be seen in the upcoming code. For more details, see Creating IAM Policies.
Now that the policy with the desired permissions has been created, you can incorporate the role creation, instance profile creation, and association with the target instances in the Automation document primarily using the aws:executeAwsApi plugin. For more details, see Systems Manager Automation Actions Reference.
I’ve demonstrated in the following code how these steps can be ordered for execution in a custom Automation document. onFailure properties have been defined for several steps to assist with cleanup should the execution fail.
In the initial steps, you gather details from the existing instance profile associated with your target instances. Then, the temporary instance profile is created and associated with the target instances using the AWS-AttachIAMToInstance Automation prior to continuing to the steps that require the additional permissions. Generally, these steps would precede the actions taken by the instances that require the applied permissions of your newly created policy, depending on the details of the step.
After associating tempAutomationInstanceRole, use the aws:waitForAwsResourceProperty plugin to make sure that the State value reflects the associated value before continuing to steps that require the permissions being applied. Also, gather the details from the temporary instance profile associated with your target instances, which are used later for the reassociation of the original instance profile.
Next, to demonstrate the use of the expanded permissions provided by the temporary instance profile, run the AWS-RunRemoteScript command.
After the actions requiring the expanded permissions have been completed, you can replace the temporary instance profile with the original instance profile. To accomplish this, use the outputs from the earlier steps. Following the reassociation, you can then delete the tempAutomationInstanceRole, as it is no longer needed following the execution. For more details, see Deleting an IAM Role (AWS API).
In this post, I walked you through how to provide temporary permissions to target instances during Automation execution through temporary instance profiles. This avoids modifications to instance profiles that are attached to instances long-term, and which only contain the core permissions required for Systems Manager functionality. For more information, see AWS Systems Manager Automation in the User Guide.
About the Author
Caleb Gutierrez is a Cloud Support Engineer in AWS Premium Support. He specializes in Amazon EC2 Windows, AWS Directory Service, AWS Systems Manager, and Microsoft PowerShell. Outside of work, he enjoys volunteering, hiking, and rock climbing.
from AWS Management & Governance Blog: https://aws.amazon.com/blogs/mt/providing-temporary-instance-permissions-with-aws-systems-manager-automations/