IAM user monitoring — Part 2

Ed Reinoso

5 min readAug 14, 2020

Before Reading

— SES — Simple Email Service: Email service
— DynamoDB: NoSQL database service

Tech Stack

This automation tool is a series of two blogs. This is the second part which will use the following services:

— DynamoDB — Terraform
— SES
— Lambda — Boto3
— CloudWatch Events

I am not going to go into much detail of how DynamoDB/Terraform works since it is out of the scope of this post. However, I am going to provide some links in the reference section where you can be instructed more about these if you’d like. I will leave a subdirectory with all the .tf files that correspond the DynamoDB provisioning in the repository.

Take a look at the first part if you have not done so before proceeding.

AWS Automation: IAM user monitoring. Part 1

AWS Lambda, Python with Boto3, IAM, DynamoDB

medium.com

Goal

One of the challenges I was constantly facing during my previous company was monitoring whether users used their AWS account console. We wanted to make sure that security was well in place, hence providing only necessary access to our AWS console environment was a big requirement.

This might tend to be simple when presented with only couple of users. However, it is certainly not scalable when having to work with 120 users in the account. Furthermore, the IAM console does not make it easy to filter by Last Activity, only by User name.

Faced with this difficulties, I decided to build an automation tool that would email a report of user inactivity in the environment to the AWS administrator. This is just an example of how the email might look like once it is sent.

You would be able to find a list of users who have not signed in. This will allow you to determine which user is actually using the AWS console.

Logic

In the previous article, we covered how Lambda can work with IAM and DynamoDB to get and store data from users in the AWS environment. In this post, we are going to touch base on how we can send that data through an SES email to a recipient.

Again, this is the diagram with the whole architecture for the automation tool. However, this case we are going to be covering Part 2 on this post:

Lambda 2: Sending Emails About User Activity

This second lambda function will be pulling data from the DynamoDB table and send it as an email via SES. Before diving deeper into the function, we need to cover some housekeeping points related to SES.

Email Template Creation

For SES to work, it needs to have a template in its repository before sending an email to a recipient. Since we are using Lambda and Boto3, it’s best to keep a good practice on being consistent when developing these solutions. Therefore, we create the template for this automation tool using the following code.

create_template() takes a template argument which need to have 4 properties, TemplateName, SubjectPart, HtmlPart, TextPart. Both Html and Text part have to be the same underlying content. For instance, Html: <h1>Hello AWS</h1> — Text: Hello AWS.

The Html part may seem a bit messy, but it needs to be compressed in order to work. Iteration in this Html syntax works by using {{#each data}} at a start of the loop and {{/each}} at the end. I will leave some reference to each of these concepts below.

This email template will only create a table which will be populated with the data about the users (Username, Last Sign In, Created On) from DynamoDB.

Now that the template has already been created, we jump back into the main Lambda function that will get the data from DynamoDB and send it via SES.

These are the general steps to follow:

First, we pull the data out from DynamoDB.
Second, we sort it by the attribute Last Sign In, having the users that do not connect frequently first (we want to know who really needs access).
Lastly, the function will call SES, passing the sorted data to be emailed to the recipient(s).

FilterExpression=Attribute(executionTime) will only scan properties that correspond to the current date.

userdataSignIn={} variable which will hold data from the users who have Sign Into their account.

sortedUserData={} variable which will serve as a holder for sorted data with readable date format

completeUserData={} variable which will contain all data from IAM users, signed in and not signed in

There is an if-else statement to evaluate whether a user has signed in into their account. If not, the attribute Last Sign In will be assigned a value of “Have not signed in” instead of a date. This is a critical logic since it will avoid the function to run into logical errors.

The sorting algorithm used in this case was the bubble sort. There is a variable, keyComparison, which will be assigned a value of string — “lastSignIn”. This way, the algorithm can determine to sort attributes by lastSignIn. Once the data has been properly obtained and sorted, then it is passed to the SES client.

Lastly, SES client will be in charge of sending an email based on the template we created in the beginning of this Part 2 logic section. A source, a destination, a template and the data would have to be specified to send the email.