AWS StackSets

ACM.218 Taking a look at AWS StackSets as one alternative for multi-account deployments

Part of my series on Automating Cybersecurity Metrics. The Code.

Free Content on Jobs in Cybersecurity | Sign up for the Email List

In the last post I explained how to copy files between S3 buckets.

As we embark on building out a new AWS environment I want to take a look at AWS StackSets. They are a feature of AWS used by AWS Control Tower that organizations can used to deploy resources to multiple accounts.

My questions are:

• Is it secure?
• How is it managed?
• How much does it cost?
• Do we need it?
• Does it close or open more attack vectors compared to my framework?
• Do I still own and control my infrastructure as code?

I’ve already shown you with my existing code how we can:

• Deploy cross account roles
• Automatically create AWS CLI profiles
• Use a common naming convention that limits who can modify which CloudFormation stacks
• Created zero trust policies that require MFA
• Leverage an IdP to separate the responsibility of who gives permission from the those who use the permissions.
• Use common templates to reduce misconfigurations

Can we do all that with AWS StackSets? Let’s take a look.

Here’s the AWS StackSet documentation.

Does AWS StackSets use a Service Linked Role?

I’ve already written about the risks of Service Linked Roles

This was my first question as I do not want to give a service-linked role access to all my accounts to deploy permissions or change security controls. Luckily you can configure your own role, which you should definitely do for the reasons if the above post, if you are using AWS StackSets.

With self-managed permissions, you create the IAM roles required by StackSets to deploy across accounts and Regions.

With service-managed permissions, you can deploy stack instances to accounts managed by AWS Organizations.

Use a delegated administrator — not the root management account

You can use a delegated administrator account so luckily you can perform StackSet options in an account where your service control policies will be in effect. Do not run StackSet from the management account.

Performance benefits

You can create, update and delete stacks with AWS StackSet. Stack operations can run in parallel — which would be easy to do with our own code as well. Open a few different terminal windows and run commands. We could also run the scripts from multiple batch jobs which I’ve done for big data back office banking system operations. I don’t need that at the moment and minimizing complexity is best unless you need it. But if you do, AWS has handled it for you with AWS StackSets.

Disabled regions

You must enable disabled regions in regions disabled by default if you need to deploy things in them. That seems obvious. However, the wording might sound like you have to enable those regions. Don’t. Disable regions you are not using.

Role permissions

You can’t rename the role. I don’t like that because anyone who gets into an account will be able to easily check for this role:

No MFA for the StackSet role

You have to grant AWS Organizations permission to use the role. Because you’re giving access to a service, not a person, you won’t be able to enforce MFA in the trust policy for that role. However, you can enforce MFA most likely in the action that triggers the deployment of the StackSet. Make sure you do that and limit who can deploy your stack sets.

Policies

The policy looks like this. We’re allowing a principal to assume the role that performs the StackSet deployments. Which principle?

The trust policy looks like this — so CloudFormation can execute StackSets in your account.

You need to grant the same exact role name to every account where you want to use StackSets. The question I have now is what permissions are in that role? This isn’t very flexible if you want to say, only allow KMS keys or IAM users to be deployed in certain accounts.

You must add the S3 service action and resources to AWSCloudFormationStackSetExecutionRole policy statement for each target account for StackSets to work.

OK. To which buckets? I’m thinking about the Capital One breach right about now, where broad S3 policies existed.

According to the documentation, all buckets.

The documentation explains that you can limit assumption of your StackSet execution role to a certain administrative role like this:

And you have to grant PassRole:

This is where I’m going to bail out. I wrote about Pass Role here.

As you can see from my prior posts, I was able to deploy any resource using the policies I created without requiring PassRole. If I do grant PassRole I want a bit more control over how and where it is used.

Now, it may be that at some point I need PassRole to run batch job but I’m going to limit where that particular permission is allowed. And I’m not exactly sure I need it. We’ll see. If I do use it, I am going to restrict the use as much as possible to ensure any permissions allowed to deploy IAM resources are restricted to execution by a user who signed in with MFA. I have covered a lot of related IAM topics, attacks, and risks in these posts:

If you do decide to use StackSets, make sure you set up the keys required to prevent the confused deputy problem.

I wrote about that here.

Trusted access for AWSOrganizations

You will need to enable trusted access for AWS Organizations:

I mentioned in another post that I don’t use nested stacks because they require S3 buckets and things get complicated. So do StackSets:

Cost

The cost for AWS StackSets aligns with CloudFormation.

If you find that you are spending a lot for CloudFormation you will have less control over the inputs that drive the cost with AWS StackSets, but balance that with with other benefit you may achieve using StackSets.

Pros and cons

And it appears that it uses buckets on which you cannot control the policies. For those who don’t manage their S3 bucket policies well, that’s a good thing. For those who want to limit access to their own account and VPCs using VPC Endpoints, you can’t do that with StackSets. AWS should be restricting them to the proper networks but I’ll leave that to others to research.

The benefit of StackSets for those who don’t want as much control over deployments or to secure all the involved resources, or who don’t mind lack of MFA or or want to separate different resources and permissions into different accounts for separation of duties, this might be good option. It simplifies the deployment process across your organization, allowing you to deploy to the accounts and regions you specify.

Of course, you can do all that yourself with the code I’ve given you so far. It’s a bit more work, but you can require MFA, write tighter polices, and avoid giving AWS Organizations permission to S3 (and all of S3 the way the sample policies are written).

It may be possible to tighten those policies up a bit, but rather than spend time on that, I’m going to proceed with my framework which gives me more control over the policies in my account, the deployment code, security controls, and more flexibility. It’s a bit more work but with reusable templates we reduce the complexity. It’s just very important to deploy common code very carefully as I wrote about in this post:

So…just to get that out of the way, stacks sets are handy and make things easier but I’m not going to use them. I want to a bit more control and I like the way AWS works without them. For my purposes I don’t need them.

If you do use them, scrutinize the policies and roles and consider if and how someone could get a handle on them and what they can do with them.

For example, if you have an active session that can use the StackSets role and an attacker gets ahold of it — can they do — pretty much anything?

Stacks sets are one option. I’ll be writing more custom code for multi-account deployments in upcoming posts and hopefully show how to make them easier and more secure.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab