ACM.126 Creating a permission set for DNS Administrators in AWS SSO
This is a continuation of my series on Automating Cybersecurity Metrics.
In my last post I explained how you can have better governance and control the risks associated with DNS configuration changes by segregating your domain names out to a separate account and only giving certain users access to that account.
Of course you can do that with separate roles within a single account as well but using a separate account may simplify permissions management in a large (or even a small) organization where IAM permissions can get confusing and complicated in a hurry. Perhaps separating out certain critical permissions to a specific account will help you simply access. You can even limit access to that account by disabling user accounts and only re-enabling them when required.
At this point in the series we’re going to branch out into using multiple accounts for different purposes. As described in the last post we’re going to put all our domain names in Route 53 in one AWS account. That way they will be easy to find and manage. Then we’re going to allow a set of DNS administrators to manage the domains in that account, and no one else.
We’ll let our IAM administrators grant users and roles permission to manage domains in the account. The IAM administrators should not be able to change their own permissions to grant themselves the ability to manage domains. Ideally IAM administrators also cannot get the password assigned to new users or get access to new roles we create. I’ll address those topics more later if I have time.
We’ve been using IAM but we’ll look at AWS SSO for a minute as a way to manage users across multiple accounts and allow users to access multiple accounts. You’ll ultimately want to automate creation of all permissions but for this post, I am going to manually add permissions for a domain name administrator in an organization to access an AWS account set up to manage domain names, just to demonstrate the concept.
Delegating permission to manage DNS configurations using AWS SSO (IIC)
AWS SSO is now called IAM Identity Center (which I’ll refer to as IIC below). I’m used to calling it AWS SSO so I might slip up below. I’m not sure why the name change. It’s just confusing and IIC functionality does not replace fully what you can do with AWS IAM as described throughout this blog series. Maybe it will some day.
However, I have been using and trying to get used to AWS SSO (I mean IIC) so let’s see how it works and how we might define user permissions to manage domain names (as opposed to the automation permissions I’ve been creating with AWS IAM).
The first two concepts in AWS SSO/IIC are familiar to those using AWS IAM:
Users: Typically a user is associated with an email address and it is a person (not a compute resource or application). You can use something other than an email address.
Group: A group of users. You can assign access to an account to a group instead of individual users.
Users, groups, and provisioning
This is where it gets unnecessarily confusing to me.
Permission Set: A collection of IAM policies. (They should have just called it a role or a role template.)
The same permission set can be used in multiple AWS accounts, so in other words, you define the set of permissions once and then assign it to users in different accounts.
As you’ll see, a permission set is essentially a role. Under the hood it’s like a CloudFormation template for a role that gets deployed to selected accounts, and then the role is assigned to the users you associate with the role in that account. What you end up with when you assign a permission set is a role in the account where you assigned the permission set to a user. It’s a role.
Why they don’t just call it a role template and roles, I don’t know. It would make the concept clearer as to what is happening when you create the resources I’m going to show you below.
I found permission sets confusing at first, and I also find the SSO UI a bit lacking, but it works. Let’s look at adding a new user and I’ll explain what I would change if I could. Maybe AWS is working on it.
Create an AWS SSO / IIC permission set
Let’s add a permission set so we can assign DNS administrators access to the AWS account we’ve designated for our domain name management.
Create a permission set for DNS administration — basically full access to AWS Route 53. You can see in the following screen shot that I’m going through the steps to create a new permission set and choosing the built in policy: AmazonRoute53FullAccess.
What happens next seems to be a bug. When I search for my new permission set it says not found via the search function:
However, if I go to the second page I find my new permission set which I named Route53FullAccess. I can click on it and see the details including which permissions are included in this permission set:
Assign the DNS administrators in the domains account
OK now I want to assign this permission set to my domain name administrators and only allow these permissions in the account where I manage domain names.
First of all I created a group and added the users I want to be DNS administrators to the group:
Now I can associate that group to the permission set and the account in which I want the permission set to apply.
You might think you could do this from the user in the console. But no, you cannot.
Nor can you do it from the groups screen.
Navigate to accounts and where you have to associate the user or group and the permission set to that account.
Search for and click on your account and then choose Assign users or groups.
Choose your DNS admin group and the permission set just created and submit the changes.
This is cumbersome because when I’m administering one user or — for security best practice in most cases — a group, I want to be able to select all the accounts that user or group can access at one time and which permission set (role) to apply. Instead I have to navigate into each account and set the permission on an account by account basis.
This seems to defeat the purpose of a service that would be a great way to centralize and make management of user and group permissions across an organization easier. Perhaps it has to do with the way AWS IAM works under the hood. If you are using AWS IAM, you have to log into each account and click on the user or group, and then add the permissions. Perhaps this is simulating that old experience of having you login and click on each account to add permissions due to some underlying architectural restriction but I hope they will fix this someday.
Here’s where it gets problematic from a security auditor’s point of view.
Let’s say you want to review all the permissions of a particular user. Let’s say you named your user DNS Admin and you assigned that person access to the domains AWS account and full route 53 access via the permission set we created as we did above.
You later want to see all the permission that the DNS Admin user has. The logical thing would be to navigate to that user in the console and click on it. However, when you click on the user all you can see are the group memberships but no holistic view of the user’s permissions or accounts to which the user has access.
Well it must be under groups, you think? No. Same thing. Click on groups and a particular group. You see no such information.
In order to review permissions you have to individually review each account. If you click on each account you can see who has permissions via the assigned user or group name plus permission set.
I try to imagine doing this at Capital One where we had 70 accounts…(other organizations have many more with the evolution of automated account creation). That’s not really going to work for a security professional.
Creating the permissions was easy. Reviewing the permissions as a whole is something that didn’t seem to be considered when designing the UI. I keep hoping AWS will fix this. #awswishlist. You’ll be better off using some other report or tool for this purpose.
Review what got created in the domains AWS account
Now let’s review what got created in our domains account to grant access to our SSO (I mean IIC) domain administrators. Navigate to the SSO dashboard using whatever account has IAM access to the domains account. You won’t be able to see this access with the domain admins user or group because we did not grant IAM access to that group.
Notice that we are navigating to IAM, not SSO (er. IIC) in this case. SSO/IIC is just facilitating the creation of a role in the account where you want to grant permissions. Your permission set is essentially a template for a role. You create the role in the accounts you select and associate the users or groups who can use that role in that account.
Why AWS did not simply call permissions sets something like roles I don’t know. It seems like that would have been less confusing. In fact, they could even provide the underlying CloudFormation template used to deploy the role and allow you to add your own CloudFormation templates instead of “permission sets”.
Also notice that AWS SSO/IIC is using SAML — for better or for worse.
AWS SSO/IIC is fine for granting users the ability to login and view things in the AWS console. It’s convenient for users who login and get a dashboard of all the accounts to which they have access. This one aspect of AWS SSO makes me use it for users who login to AWS.
However, I do not use it for automation. I’ll explain why in the next post.
We may want to grant DNS admins the ability to login and manually view or manage aspects of DNS in the AWS console. That would be the purpose of granting a user SSO access to the domains account as I’ve done in this blog post.
Risks to consider— who can grant permissions?
Now you might have only given the DNS administrators permission to manage domain names, but consider the following:
Who has access to add a user to the DNS administrator group?Who has permission to create a new permission set like we did here?Who has administrative access to the domains account and IAM who could create permissions directly in the domains account?Who has permission to reset user passwords and modify MFA devices such as those assigned to the domain administrators?
Any of the above permissions could essentially be used to grant someone new access to the domain name transfer functionality I wrote about in the last post. That is why I recommend that you have a separate group assigned specifically to managing IAM and SSO and you think about how you can create segregation of duties to prevent someone from granting themselves access to something whey should not be able to access.
Now that we have an AWS SSO user for DNS administration, we’ll look at how that user can execute commands with the AWS CLI in the next post (and why I don’t use that approach).
Follow for updates.
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:
Automating Cybersecurity Metrics (ACM)GitHub – tradichel/SecurityMetricsAutomation
____________________________________________
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
AWS SSO (IAM Identity Center) for Separation of Duties was originally published in Cloud Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
