Know Your Place

I found it frustratingly difficult to get the two IAM roles working for the Automation document. I’m pleased with the resulting config because, first, it works and, second, it doesn’t look as if permissions are unnecessarily loose. That said, especially if you’ve had more IAM experience than I have, you should look carefully at what I have working before blindly cutting and pasting the config into place. (For some cold sweats tonight, read this copy-and-paste horror story on the Life Plus Linux website.)

IAM complexity arises because a PassRole is used in IAM to provide the temporary instance certain permissions to complete its task. AWS explains how that works in a post on PassRole permission:

You can use the PassRole permission to restrict which role a user can pass to an EC2 instance when the user launches the instance. This helps prevent the user from running applications that have more permissions than the user has been granted—that is, from being able to obtain elevated privileges. For example, imagine that user Alice has permissions only to launch EC2 instances and to work with Amazon S3 buckets, but the role she passes to an EC2 instance has permissions to work with IAM and Amazon DynamoDB. In that case, Alice might be able to launch the instance, log into it, get temporary security credentials, and then perform IAM or DynamoDB actions that she's not authorized for.

Rather than make you fall asleep at this stage, I’ll look a bit more at using a PassRole after you’re armed with more information and it’s easier to digest.

End of Level Boss

Worrying less about theory and getting my document running, I begin by creating an IAM role that has unfettered AWS Systems Manager (SSM) access. The docs generally call this AutomationRole , and frankly, after the headache I had with IAM initially, unless you really have to change it, I would keep things simple and follow the convention. For complete clarity, this is the power role. The AutomationRole IAM role has several permissions greater than the role I’ll look at shortly.

Having created a role called AutomationRole in IAM, you should assign an AWS managed policy called AmazonSSMFullAccess to the role. Inside the AWS console and within IAM, click on the role name – it should be fairly obvious. Figure 2 shows the big blue button, in case the different policy types cause confusion.

Figure 2: Attach a predefined policy by clicking the Attach Policy button and choosing “AWS managed” under Policy Type, if you’re unsure.

The policy as shown in Figure 3 is what I want. Still working on the role I named AutomationRole , I now need to edit the Trust relationships for which services this role can access (see the tab in Figure 2). After clicking the tab, another big blue button appears called Edit trust relationship (Figure 4).

Figure 3: I’ve attached a managed policy (one that AWS looks after on my behalf but that I can’t edit without duplicating and renaming) to the role I called AutomationRole.

Figure 4: The AutomationRole trust relationship.

Inline Policy

Finally, I want to add the all-seeing, all-powerful EC2 permissions with an inline policy. Going back to the main screen for the role (i.e., the view in Figure 2), I want to create a custom policy of my own. To do so, I click the Add Inline Policy link and then the JSON tab to paste (and carefully check) the permissions I am relinquishing to the role (Figure 5). I name this inline policy whatever I like (e.g., AutoEC2inline ). If you get really stuck, add the permissions in the Inline Policy section without using the JSON editor. It’s relatively easy to get correct, even the first time you use it.

Figure 5: The inline policy for AutomationRole. Note that I’m missing the top bracket, and the bottom bracket is cut off. You should adjust the body of your JSON to get this correct (the editor will not let you save it if it’s formatted incorrectly).