Open DanHatesNumbers opened 2 years ago
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:
<Principal 1> -- Edge 1 --> <role/AWSServiceRoleForSupport> -- Edge N --> [...]
If that role can only be assumed by support.amazonaws.com
, could you drop info on how another principal in the account is able to gain access to that service role? i.e. the reason
field of that Edge
where that role is the destination?
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 role/AWSServiceRoleForSupport
role and the reason field for those edges is: role/codebuild-role-eu-west-1 can access through administrative actions role/AWSServiceRoleForSupport
.
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:
cognito-idp:DescribeUserPoolClient
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 Edge
objects linking to all other Node
objects to continue searching.
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 AWSServiceRoleFor
). That is not true (https://aws.amazon.com/blogs/security/introducing-an-easier-way-to-delegate-permissions-to-aws-services-service-linked-roles/), and we should be excluding these roles as destinations. I'll implement a fix in the v1.2.0-dev
branch.
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.
Now it behaves exactly as I'd expect.
Excellent!
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 concern with this approach is with service principals like lambda.amazonaws.com
, ec2.amazonaws.com
, glue.amazonaws.com
, codebuild.amazonaws.com
, and sagemaker.amazonaws.com
. These are all accessible by other users/roles in AWS accounts and the list may expand as AWS adds new services. However, per #104 and discussions elsewhere, we do know that service-linked roles can be determined by that common prefix and handled with their special cases as in here.
The concern with this approach is with service principals like
lambda.amazonaws.com
,ec2.amazonaws.com
,glue.amazonaws.com
,codebuild.amazonaws.com
, andsagemaker.amazonaws.com
. These are all accessible by other users/roles in AWS accounts and the list may expand as AWS adds new services. However, per #104 and discussions elsewhere, we do know that service-linked roles can be determined by that common prefix and handled with their special cases as in here.
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!
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.