I manage a team of engineers in a single AWS account (I know we should be using multiple accounts, but let's set that aside for now). They're often facing red error messages and security warnings in the AWS Console because their roles lack permissions for read-only IAM actions. This makes it difficult for them to figure out if they need additional IAM permissions for their roles or the automation tasks they run. I'm considering whether granting blanket read-only permissions for IAM actions to these engineers and developer roles is a bad idea. Are there any security standards or concerns I should be aware of before doing this?
5 Answers
I'm usually comfortable with granting the managed SecurityAudit policy to almost everyone. It allows for read-only access to all configurations without exposing any sensitive data. This policy is safer than the general ReadOnly policy since it doesn’t grant access to actual data like S3 or DynamoDB. Ideally, developers should already know the policies through Infrastructure as Code, so it’s more about making sure they have visibility.
The principle of least privilege is key. If they don't need specific permissions, don't grant them. It might be challenging to implement this effectively. Maybe consider creative solutions like styling tweaks or scripts to modify the AWS Console display, so they don’t see unnecessary info!
Sometimes less is more. Keep it simple and only give what’s necessary!
I don't see any major issue with granting read-only access to IAM policies, especially if you narrow it down to a few specific policies. It can help engineers understand what they can do and what permissions they might need. Just be cautious that they don't have full visibility to all roles since a malicious user could use that information to identify weak points for exploitation.
I personally allow read access to IAM for most roles. It doesn’t really help to keep it hidden; instead, it could create bigger operational risks. If you decide to restrict some roles, think about using a naming convention for your roles and policies to manage that easily while still providing read access.
True, being able to describe certain policies can reveal sensitive information like external IDs, which is a security gap.