This automation tool is a series of two blogs. This is the first part which will use the following services:
— DynamoDB — Terraform
— 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.
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 sorted in a descend way by last sign in category. This will allow you to determine which user is actually using the AWS console.
I decided to divide this automation tool into two blogs due to its complexity and length. I wanted to keep it straight forward and simple. Hence, for this part we will only be dealing with the lambda function responsible for handling IAM user data and storing this data in a DynamoDB table.
The diagram below shows an example of the whole architecture for the automation tool. However, we are only going to be focusing on Part 1 on this post:
CloudWatch will only be there to invoke Lambda functions during certain times. During my previous article, I covered how to create an Event and how scheduling of events (crontab) work. So, we are going to be skipping that part for the sake of avoiding redundancy.
Lambda 1: Getting IAM Users Information
This function’s primary objective is getting relevant user’s data from IAM. The data we need is: User’s Password Last Used, and User Creation Date. Then in this same function, this data is sent to a DynamoDB table for storage and later usage.
In this function, we will be working with a Boto3 client and a resource, iam and ddb_table. Both of these variables will hold or receive the information needed to accomplish the job of pulling and putting data into the DynamoDB table.
It is important to notice that there are two for loops:
— One is for iterating through the list of IAM users, which will provide us with certain attributes about users. For the purpose of this blog, we are interested in the followings:
When iterating through the users, we have to consider people who have never signed into their AWS console account. If this is not taken into account, then the code is going to give logical error since it will try to look for an attribute that does not exist, this case is the PasswordLastUsed.
We save this information into a variable list so that we can use it in the next for loop.
— This for loop is going through the variable created from the step above and putting items into the DynamoDB table. The attributes that we will be using for items in the table are the following:
Lastly, we include the executionTime since it will be important to determine the list of current users in the account. For instance, suppose that the automation tool ran weekly every Monday. During one week, you have 5 users, but you may delete one of those 5 users due to inactivity or something else. By having the executionTime, we can filter more easily the DynamoDB table at the moment of getting the data for the current user list.