Automating the AWS Identity Lifecycle with unSkript (Part 2)

This week, AWS is celebrating all that is AWS at their RE:Invent conference in Las Vegas. Here at unSkript, we are celebrating all that is AWS by highlighting how to automate common AWS tasks with our xRunBooks. In our last post, we began the process of building an Identity Management lifecycle workflow — by using the open source Create IAM User workflow, and configuring it for our exact needs.

However, just adding a user’s identity to AWS is not enough to be useful. Once this user is created with a default password, the first thing that happens at login to AWS is that the user must change their password. But without enough permissions, this new user cannot even change their password

screenshot showing password change page with message showing lack of permissions
User with no policies cannot even change their password

With no permissions or policies connected to the user — this fails! So, we must go about adding the appropriate permissions to the identity profile.

Least Privilege

The idea of least privilege is to give each user/identity *just* enough access to do their tasks, and no more. Giving the finance team access to AWS to pay the bill is important — but that team *probably* doesn’t need to configure EC2 instances or build a load balancer. By limiting the finance team’s scope — we prevent accidents from happening (“I was poking around, and I think I deleted the production database”), but also lessenes the attack surface if credentials are lost in any way.

For example, if we were to give every new user “AdministratorAccess” — they would certainly be able to do everything they needed in AWS, but they might have a bit too much power. Should the credential be lost, or the user to become a bad actor in any way, serious issues might occur in your AWS environment.

AWS offers a number of Policies that are predefined — offering out of the box profiles that fit most use cases. For example, for your team building on AWS Lambda, there are many managed policies, including (in order of decreasing permission levels):

  • AWSLambda_FullAccess
  • AWSLambdaRole
  • AWSLambda_ReadOnlyAccess

So, we should add the ability to add Permissions to each IAM policy, in a safe, effective way to ensure the least privilege.

Adding a Permissions Policy to our IAM workflow

In our last post, we created a workflow that created a new user, gave them a temporary password, and then announced the user creation in Slack. We will build on this workflow to automatically add a Policy to the user’s account.

The cool thing is that we can do this with no coding — there is a predefined Action built into unSkript that does this work for us!

Open the xRunBook you created as a part of the last blog post. In the Actions navigation on the right side (close any configuration you might have open to get back to the Action search) search for ‘AWS Attach New Policy to User.”

Action search in unSkript
Search results in the Action search bar

Click on the box in the search results, and drag it into your existing xRunBook (anywhere after the “Create login Profile” Action).

You can also add a text description above your new Action by clicking “Add” -> “Note” in the Top Menu.

Screenshot showing added Note and Action into the xRunBook.
New note and new Action added to the Create IAM User xRunBook

Configuring the Action

Since this Action interacts with your AWS account, you’ll need to add an AWS Credential (if you did not do this in part one — here are the instructions). There are 2 input fields for this Action:

  1. User Name: place the variable user_name here. This will utimilze the input parameter from the xRunBook, and add the Policy to that User Name
  2. Policy Name: We have 2 options here:

a. You can hardcode the policy, and create different versions of the runbook. (one Runbook for admins, another for Billing, etc.)

b. We can parameterize the Policy, and create a new input parameter for the RunBook.

Hardcoding the Policy

If you choose to hardcode the policy, you can simply place the policy in quotes in the “Policy Name” input.

Parameterizing the Policy

To parameterize the Policy Name, we will want to add another Parameter to the xRunBook. In the top navigation, click “Parameters” -> “Add Parameter” We’ll name it policy, and to give a very low default permission level, we’ll default the policy to “IAMUserChangePassword.”

In the new Action, place the variable policy in the “Policy Name” input.

input parameters for the new Action

Update Slack Action

Finally, we can change the Slack announcement to add the Permission policy that is attached to the user.

f’New IAM user {user_name} added by {caller[“Arn”]} with Access Policy {policy}’

When we run this xRunBook, a new IAM user is created, given a password, and provided a default access policy.

Securing Access Control

Now, with a parameterized Access Control Policy input — it becomes very easy for anyone with access to add a new IAM user — with little to no oversight to the addition (other than a close monitoring of the Slack channel for messages).

To further secure this xRunBook, it should be set to “Require Approval.” This forces every run of the xRunBook to be approved or rejected by another member of the team — adding the required oversight and preventing accidental over-reach of IAM identities.

Enabling an Approval Path

Note that feature is not available in the unSkript Sandbox and is only available to SAAS customers.

To enable Access Control, close the xRunbook (and save it) and then reopen it to the details page. At the top of the screen is a “Requires Approval” checkbox.

requires approval checkbox

Upon clicking this button, the xRunBook can no longer simply be run, and immediately get results. Now, every run becomes a request that is sent to the users with approver access (Read more on Access Control in our docs). Approvers can review the queue of requests and either approve or reject each request.

A list of my request queue
A users’ request queue
Approval queue for admins and those with Approver access.

This added functionality further secures your AWS IAM credential management by preventing one user from creating many profiles with inappropriate access controls.

Conclusion

In this second post in our AWS IAM automation blog series, we added access controls to the new user creation xRunBook, giving the new users immediate access to the features in AWS that they will need to be successful in their role.

We also looked at placing a manual approval process around each running of this xRunBook, giving the access team additional oversight into each credential & policy being granted to new users.

In our next post, we’ll turn the xRunBook we just created on it’s head in order to continue the identity lifecycle. With just a few small code tweaks, our “add a new user” xRunBook will become a “remove an existing user xRunBook.

Interested in learning more about how unSkript can help you build internal tooling for your team? Check out our free trial, star our GitHub repository of xRunBooks and Actions, or join our Slack Community!

Share your thoughts