nccgroup
AWS IAM false positive "Managed Policy Allows All Actions"
In ScoutSuite 5.11.0, the rule "Managed Policy Allows All Actions" matches the AWS-managed policy "arn:aws:iam::aws:policy/AdministratorAccess". Of course that policy allows all actions, that's its whole point. And since it's an AWS-managed policy, users can neither edit nor remove it and every AWS account out there will match this rule.
I suggest that this specific AWS-managed policy be excluded from this check. If you want to have a check for principals that are administrators, then it should be called something like "Principals with administrator policies" to make it clear what you're warning about.
Agreed. Confused as to why this is being flagged by ScoutSuite. Does anyone know what we're meant to do here?
@rdegraaf @rorcores
This might be due to the fact that arn:aws:iam::aws:policy/AdministratorAccess is attached to users or roles. That is why it is flagged. Those policies which are attached and overly permissive, I suppose are flagged.
Thanks for raising this! This doesn't really make sense to me that this is flagged, either. We have to maintain at least one role that has these permissions attached in order to allow for that policy to be assumed through our IAM Identity Center setup for situations where we do need true Administrator permissions for a limited amount of time, after which the credentials expire. The AWS Docs actually recommend what we're doing as best practice. So I think desired behavior here, at least in our particular case would be for ScoutSuite to ignore cases where the policy is attached to an IAM Identity Center role. But I'm sure there's other cases where this shouldn't be flagged as well. In my searching around, I noticed @x4v13r64 has dealt with a couple cases like this in the past, so tagging them here in case they're able to clarify or help. Thanks in advance! ❤️
@austinorth Something that I learned since opening this issue: the CIS Benchmark for AWS unconditionally bans the use of administrator permission policies ("1.16 Ensure IAM policies that allow full "*:*" administrative privileges are not attached"). I guess that it's their position that every account has dedicated non-admin principals for every task, including deployment, and that the root user is used to bootstrap all of that and make changes when necessary. So this rule in ScoutSuite enforces that CIS requirement.
OTOH, I'm going to have to disagree with CIS here. Having non-admins for all routine tasks is certainly a good thing, but there should be an option for admin creds when needed without needing to dig root user creds out of cold storage; CIS also has a rule against using root user creds for "administrative and daily tasks" except for the handful of things that require root creds (https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-tasks.html). Nearly every account I've ever seen has an admin Role (or User, but that's usually indicative of poor management). Banning admin permission policies also invites workarounds: non-admins who can edit their own permissions, principals with "NotAction" statements allowing them to do anything except something that they don't care about in an obscure service, etc. While such permission policies may satisfy the letter of CIS, they violate its spirit and make accounts less secure. It's better to have an admin that's obviously an admin and everyone knows it than to have a wonky pseudo-admin that tries to conceal what it can do.
AWS Config has a rule that's nearly equivalent to CIS', the key difference being that it explicitly allows the built-in AdministratorAccess permission policy (https://docs.aws.amazon.com/config/latest/developerguide/iam-policy-no-statements-with-admin-access.html). I feel that this is the approach that ScoutSuite's default ruleset should take; the "no admins at all" rule should be restricted to a CIS-specific ruleset.
@rdegraaf wow, thank you so much for the context! I definitely agree; having a bunch of spooky pseudo-admins could make governance extremely difficult, and the complexity of such a setup would snowball over time. I'm going to do some thinking on how we might handle this situation in our environment in the near term, but fwiw, I do agree that ScoutSuite should only flag this for CIS specifically.