KEYNOTE: JupiterOne -- Complex IAM Permissions Analysis Using Graphs

Akash Ganapathi
JupiterOne, Director of Solutions Architecture

Akash Ganapathi heads Solutions Architecture at JupiterOne. He comes from a data modeling and software architecture background and also operated his own startup prior to joining JupiterOne. 

Access control in AWS is done via IAM policies. Policies and permissions in IAM can get really complex really fast, leaving a ton of room for mistakes and misconfigurations. To put this in perspective:- There are six types of IAM policies- Policies can have a combination of Deny and Allow statements- Each statement includes Actions, Resources, Principal, Conditions- Each statement can also have negations (exceptions) such as NotResource or StringNotEquals in Conditions- And many other details and tricksIt is best practice to configure least privileged policies. However, to get it right is often more challenging than it looks. As a result, most policies are written with wildcards (*) in Actions, or Resources, or both, with no meaningful Conditions.It is also very difficult to understand the net effective permissions of a policy that contains both Allow and Deny statements, with seemingly contradicting conditions and exceptions. AWS provides an IAM policy simulator that helps, but only helps to a limited extent. With the IAM policy simulator, you have to specify the service(s), action(s), and/or resource(s) and get a “yes/no” answer back telling you if a policy grants the permission to that known combination. It cannot answer the broader question of “given a policy, what resource permissions does it grant access to” in general.