'Limiting other AWS IAM roles from interacting with resources/privilege escalation

I have two IAM roles in AWS; A and B. In role A I have an explicit deny to prevent certain permissions from being performed in Elastic Map Reduce(EMR). How can I prevent a scenario where Role B could be updated to have an allow on the permissions that were denied in Role A?

I am not very familiar with our IAM federation but my understanding is that users access a federated portal URL and are presented with an initial role that they can select from a radial button based on the AD groups that they are in. From there users can change role/assume role if permissions are setup properly. Currently we have ~150 roles that I would need to ensure do not have the ability to circumvent the explicit deny in Role A.



Solution 1:[1]

If possible, it is always better to avoid Deny policies because they often do not work the way people expect. AWS has "deny by default" behaviour, so it is better to control access by limiting Allow permissions.

Unfortunately, many organisations use "Grant All" permissions, such as granting s3:* permissions and giving people Admin permissions. These examples grant too many permissions, which might then need a Deny to override.

Some services (eg Amazon S3, Amazon SQS) also have the ability to apply service-specific policies (eg S3 Bucket Policies) that can grant permissions in addition to IAM.

A good place to start is to strongly limit who has iam: permissions. Only admins should have the ability to use IAM (and that should only be granted via an IAM Role that the admins need to Assume). By controlling such access, it will avoid your scenario where you are worried that an IAM Role could be modified to permit unwanted access.

For worst-case situations where it is vital that access to certain resources are strictly controlled (eg S3 buckets with HR information), a common practice is to create a separate AWS Account and grant limited cross-account access. This way, access will not be granted via generic Admin policies.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 John Rotenstein