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.
KEYNOTE: JupiterOne -- Complex IAM Permissions Analysis Using Graphs
- PSTJoin on Hopin
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.