-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PMapper 1.1.5 builds edges that include role/AWSServiceRoleForSupport when performing authorization checks #108
Comments
Hello! To make sure I understand, you're running a query and one of the query results has a list of edges that looks like:
If that role can only be assumed by |
Hi! You're correct, that's the behaviour I'm observing. There's a handful of roles in the account I'm querying that have edge lists that include the If it would be helpful, I can try and replicate this behaviour with Localstack and provide a minimal example of the script I'm running my query with and steps to create the required IAM principals and policies. |
Ah, I know what's happening:
Because there are SCPs in play, PMapper does not assume that an admin can arbitrarily call a given action. Instead, if the admin node isn't directly authorized to call the action, PMapper generates There is a bug here, PMapper is assuming that IAM Users/Roles are able to gain access to service-linked roles (IAM Roles that start with the prefix |
Just pushed dc7ab36, would you be willing to let me know if that's working better? You'll need to regraph the account due to the version bump. |
Running the regraph now using v1.2.0-dev, I'll report back with the results! |
I'm no longer seeing edges being constructed that involve assuming the role/AWSServiceRoleForSupport role, however, I'm also not seeing any edges that I would expect to see there. This may be due to a faulty SCP I'm testing on my part, so I'll do some more digging and let you know what I find. I've had a look at the change, and I wonder if it's worth using the role's trust policy to exclude roles that only include service principals in their trust policy? That way it would correctly handle roles created by customers that can be assumed by a service that don't follow the AWS naming conventions, as well as roles that can be assumed by both service principals and other types of principals. |
The weird behaviour I was seeing where the principals I'd expect to be allowed to call the action I'm querying were being denied was because I forgot to also include the default Allow All SCP in my simulation. Now it behaves exactly as I'd expect. |
Excellent!
The concern with this approach is with service principals like |
Thanks for that explanation, that makes sense! Also thanks so much for building this tool! I've literally just finished giving my team a crash course in how to use PMapper to analyse AWS accounts and also this SCP simulation usecase to assess the impact of applying a new SCP without needing to 'do it live' and they loved it! |
#109 fixes this issue, hopefully this comment will autolink them |
…soler Address nccgroup#108: Add AWS Consoler permissions
Question
When using the
principalmapper.querying.query_interface.search_authorization_full function
to check if a principal is able to use 'cognito-idp:DescribeUserPoolClient' on a specific resource, it will build a chain of edges that includes 'role/AWSServiceRoleForSupport' in order to call the action being checked. Because the trust policy on this role only allows it to be assumed by the AWS service 'support.amazonaws.com', should this role be ignored when building graph edges if it isn't the starting node?Did the Wiki Have an Answer?
I'm not sure if this behaviour is a bug or not, but if the behaviour of
principalmapper.querying.query_interface.search_authorization_full function
changes, then noting it in the library reference page for that function would be useful.The text was updated successfully, but these errors were encountered: