Analyze IAM access patterns programmatically
This blog has moved from Medium to blogs.tensult.com. All the latest content is available there. Subscribe to our newsletter to stay updated.
Imagine you are the cloud administrator in your organization, overlooking the permissions and roles for each employee in your cloud environment. When the company was in its initial days, everyone had broad access for the various services in the cloud. Later, when everyone got settled in their roles and company started functioning smoothly, you started thinking about restricting user access to the AWS cloud services. That process is quite natural in an organizational environment because minimal access means lower risk of data leaks, lower risk of data hack and limited exposure to unnecessary information.
Now, the challenge that one will face in such a situation is to know which role/user to monitor for limiting his/her permissions to access AWS cloud services. Amazon Web Services has the perfect tool which will help us create a report which gives the info about the last time that an IAM entity (user/role) attempted to access a service. This is known as ‘service last accessed data’. We can leverage this data to modify the policy to allow access to only the services that the entities use. For example, if an entity (user or role) uses S3 bucket to only read data and not write anything in it, then we can remove the write access for this user/role and provide with him S3 read access.
An advantage of using this feature is that we can create a report for each type of resource in IAM. In each case mentioned below, the report covers allowed services for the given reporting period :
- User — View the last time that the user tried to access the service.
- Group — View information about the last time that a group member attempted to access the service. This report also includes the total number of members that attempted access.
- Role — View the last time that someone used the role in an attempt to access the service.
- Policy — View information about the last time that a user or role attempted to access the service. This report also includes the total number of entities that attempted access.
We can use the generated report to identify unused and also rarely used permissions in associated policies. We can then choose to remove permissions for unused services or reorganize users with similar usage patterns into a single group. This practice of organizing users and roles helps improve account security. This report is helpful in a way because there is less effort in removing unnecessary permissions and hence securing the infrastructure better.
I will share my experience of testing this report using below mentioned commands. But before we start running commands to get the report, we need to make sure that the Amazon CLI is updated and pip is installed. Installing pip is easy and if you’re running a Linux machine, it’s usually already installed. If it’s not installed or if the current version is outdated, we can use the packet manager to install or update it.
On Debian or Ubuntu :
$sudo apt-get install python-pip
On Fedora :
$sudo yum install python-pip
If you’re using a Mac, you can easily install it through easy_install :
$sudo easy_install pip
We also need to make sure that the EC2 machine that we are using has AmazonEC2FullAccess, AmazonS3FullAccess, and IAMReadOnlyAccess roles attached to it.
Now let’s discuss the new IAM Access Advisor APIs:
- generate-service-last-accessed-details
The above command can be used to generate the service last accessed data for an IAM resource (user, role, group or policy). Upon calling this API, a job is started that in turn generates the service last accessed data for the IAM resource. The result of this API is a JobID which is to be used in other APIs, such as get-service-last-accessed-details, which we will discuss next. Check out the screenshot of the above-mentioned command.
- get-service-last-accessed-details
This command is used to check the service last accessed data for an IAM resource. It takes the above-mentioned JobID as an argument.
- get-service-last-accessed-details-with-entities
We can use this API call to retrieve service last accessed details for specific entities/services. This provides you with last accessed date and the list of all IAM entities who have access to the service.
Notice in the above command, we gave the service-namespace argument IAM as well along with the command. That is required for this command to run.
In the above set of screenshots, we can see that the role TestRole-DeleteLater accessed the S3 service to complete a job. If this role accesses more services like EC2, DynamoDB, then that info will also be shown in the result as below:
In the above screenshot, we can notice a role named DBAdminRole has accessed both DynamoDB and S3 services in the past 6 months. Using such detailed information, the admin can modify access to specific services for particular roles.
Conclusion
In this blog, we reviewed IAM access advisor APIs and checked how we can use them to determine service last accessed information programmatically. So in a production environment, you can leverage this command and create a program to perform an audit, remove unused permissions, or give appropriate permissions across your accounts.
Kindly post your valuable feedback or doubts in the comments section. If you wish to see more of our work, please visit us at Tensult.
Thanks to Sandeep and Dilip for the inputs.
