Assigning a Group to a Trust Policy in an AWS IAM Role | by Teri Radichel | Cloud Security | Sep, 2022

ACM.45 How to assign a group to a trust policy indirectly to overcome AWS limitations

This is a continuation of my series on Automating Cybersecurity Metrics.

First a brief request: If you find any plagiarism of my blog posts or anyone else’s, please report it.

I already wrote about this topic in an earlier post where I explained that you can’t assign a Group to a Trust Policy an IAM Role. Instead we have to assign each individual user at the time of this writing. I’m going to show you one way to work around that problem in this post and mimic the functionality of adding a group to a role.

In a later blog post, I updated the role to avoid the Confused Deputy Attack and lock down who can assume the role a bit more stringently. I’m going to reference this version of our batch job role below:

If you are not familiar with different types of policies on AWS including Trust Policies, I wrote about them here:

Can’t assign a group to an AWS IAM trust policy

One of the problems I have frequently run into over the years when trying to create succinct and automated policies is that you cannot assign a Group in a trust policy or any AWS Policy for that matter. A Group is not a principal in AWS IAM as I explained previously. I have hit this problem so many times and seen so many questions about it that I’m surprised AWS hasn’t already provided a fix or work around. I’m not sure what the issue is behind the scenes that makes this hard to implement.

Here’s the problem with not being able to assign a group in my trust policy. Remember that nifty template we created for batch jobs I referenced above? It ensures that only the correct principles can get assigned in the trust policy. The problem is that it assumes there’s only one principle the way we set up our mapping. As already explained, I didn’t want to pass in a list because we are trying to ensure the wrong users are not accidentally assigned in the trust policy. Instead we have people pass in a type which restricts to creating roles that have an existing mapping. Well, hold that thought.

Obtaining a list of users in a group

That role template is a bit tricky when it comes to solving this problem. Let’s start with something easier. Let’s say we want to create a generic role that matches the name of a group and assign a policy.

What if we could create a CloudFormation output and export the list of users from our stack where we added users to groups and use that to add those users to the role trust policy. I explained here how I pass in a list of users to add them to the group:

I could just grab that list and output it at the end of the stack, right? Well, upon testing that theory we can’t do it since we can’t pass the parameter back out as an export.

Well, we could look up the parameter of the CloudFormation stack but how might that be problematic? If in any case the parameters passed into a stack change for a failed deployment, then we might be adding users that don’t actually exist in the group. I’m not 100% sure how that works so I’m reverting back to our original idea: we’ll delineate the users in the group in a command line script since (because that happens to be what I’m using at the moment) and add them to the trust policy.

Define a group role with a trust policy that contains users in the group

Define a generic role in a template called GroupRole.yaml with the ability to pass in the user ARNs as a comma separated list. Notice the second parameter below is the type CommaDelimitedList.

Create a function to retrieve the group users and deploy a the role

Next I’m going to continue on with the refactoring I’ve been doing in the last few posts. If any of the code below doesn’t make sense you might want to back up and read the last three posts — better yet read the whole series to see the evolution and get a lot of cloud security insights along the way.

Create a role_functions.sh script like we did in prior posts for our common functions to enforce our naming conventions. In this function we’ll retrieve the ARNs for users in the group to pass in as a parameter.

This is the query that will return the users in a group in a comma delimited format. We are replacing tabs with commas in the sed function at the end. You can test it out on the command line.

aws iam get-group --group-name IAMAdmins --query Users[*].Arn --output text | sed 's/\t/,/g'

We’ll replace IAMAdmins in the above command with whatever group name gets passed into our function. We’ll output the results to a variable and use that in the parameter variable that gets passed into the function that creates the stack.

Next we can create deploy.sh script in our role directory that calls this function. Notice that I’ve commented out the policy creation until I test role creation.

Note that if you try to deploy the stack when no users exist you’ll get an error so we’ll want to throw and error and exist in that case.

In my last post I never added any users to the KMSAdmin group so I went back and did that. I re-ran the group deployment, and then my role deployment.

Now you can search on GroupRole in the Role list to find any roles that are associated with Groups in your account created with this code. If you restrict creation to your approved IAM code you can ensure that this list will return every role associated with a group in your account. If you do not restrict your deployment pipeline to approved scripts or allow people to edit things in the console you cannot count on this list.

IAMAdminsGroupRole has the correct users in the trust policy:

KMSAdminsGroupRole also has the correct user:

Now you can uncomment the call to create a policy. We’ll change the function name deploy_role_policy and make sure that GroupRole is in the name to match our role name.

The function is pretty much the same as our group policy function:

You’ll need to rename each policy template to the appropriate name, create the policy, and ensure the policy is associated with the proper role.

For example, we can create an IAMAdminsGroupRolePolicy.yaml file that looks like this:

That policy allows my IAM administrators to do anything with IAM and it should allow them to deploy and delete any CloudFormation stack starting with the name IAM-.

I still need to test out the resource restriction but that might be helpful if we only account deployment of CloudFormation stacks using our code that enforces proper naming conventions.

Batch Job Policy Can’t Use Groups

What about our batch job policy above? Well I’m not quite to the point where I’m running batch jobs yet so I’m going to punt on that one for a bit and get back to what I want to be doing — creating a Lambda function that can decrypt the secrets we created and encrypted with our KMS key.

For now I created a function to deploy it almost as is with a few modifications.

Here’s the modified template for the Batch Job role. I just camel cased a few things and I went back and added some additional users and groups referenced here. I’ll write about those more later:

I also ensured the LambdaRole deploys properly. I’m going to write about changes to that role in an upcoming post where I deploy a Lambda function and modify the role to make it work properly.

I don’t love this for the reasons I wrote about in my blog posts on the confused deputy attack, however if you can restrict your cloud account to a secure automated pipeline, someone can’t come along and insert new users into a group or bypass the group and call the role template with some arbitrary list of users.

I’m sure I’ll be back to revise the batch job and Lambda roles but for now, you have an idea how to create a role that adds all the users in a group.

Teri Radichel

If you liked this story please clap and follow:

Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research

© 2nd Sight Lab 2022

All the posts in this series:

____________________________________________

Author:

Cybersecurity for Executives in the Age of Cloud on Amazon

Need Cloud Security Training? 2nd Sight Lab Cloud Security Training

Is your cloud secure? Hire 2nd Sight Lab for a penetration test or security assessment.

Have a Cybersecurity or Cloud Security Question? Ask Teri Radichel by scheduling a call with IANS Research.

Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts