- Unlimited Leave
- Posts
- Some ❤️ for Gov
Some ❤️ for Gov
GovCloud governance gets some much needed attention this last month.
Ross Wickman
November 04, 2022
Three weeks to re:Invent. The plan this year - "connection."
This year my focus is going to be Chalk Talks, Workshops, and Peertalks. On my last trip, I got the most out of sitting in a booth with 15-30 others, watching demos, and asking questions.
This year a former colleague of mine is giving a Workshop and admittedly using some of my past GitHub Workflow methodologies. You can bet I'm going to be in that session heckling the shit out of him.
Goodies for the week
Deploy Straight to AWS from GitHub
A Ridiculously and Disturbingly Accurate Documentary
BIG Updates for GovCloud
Problems Delegating CloudFormation StackSets
Revisiting Multiple Account Architecture
Deploy Straight to AWS from GitHub
Speaking of GitHub Workflows, this is one of mine.
It's an oldie but a goodie that still get the job done.
The leveraged AWS-owned GitHub Action (for deploying CFN Stacks) has been in public archived for some time. I suspect that won't be the case for very much longer.
I'll be making some modifications to this and moving to a new GitHub group eventually. In the meantime, my focus is on cleaning up and releasing a very similar setup for GitLab workloads.
A Ridiculously and Disturbingly Accurate Documentary
A couple of weeks ago a documentary (CLOUDED) about just how messed up the cloud landscape really is was released publicly after being made available at a “premier showing” back at the beginning of October.
As a cloud governance and compliance professional, a lot of this really hits close to home. I just deploy the environments. If leadership or a development team wants another account, if they couldn’t already deploy it themselves, they get it within minutes. No question.
Frankly, in my role, I don’t care what goes into it or how for that matter. Unless I’m told to place particular guardrails or billing alarms in an environment, the cost just starts accumulating. My job has almost always been enablement. All I can do is build solutions to quickly terminate the services and account if needed.
Making sure the architecture is optimized is usually an afterthought or someone else's responsibility. I always try to take these realities into consideration from the top down.
I need to give it another more focused viewing. If you haven’t seen or heard of it, the ~1hr of time is worth it.
BIG Updates for GovCloud
Fairly recent announcements I’ve got my eye on regarding Cloud Governance and Secure Workloads finally involve some updates to the GovCloud Regions.
Control Tower in GovCloud Regions - while not an identical configuration to the Commercial Setup, this has some potential, but you can quickly see all the frustrating nuances. If you understand the backend of how GovCloud accounts are linked and generated from Commercial accounts it's not so bad.
It’s substantially better than the previous Compliant Framework for Federal and DoD Workloads in AWS GovCloud which makes it obvious why they’ve made this “no longer available for new deployments.” I feel pretty bad for anyone that deployed this. It's a prime example of how using a 'reference architecture' that is just a hodgepodge of AWS services duct taped and bubblegumed together is likely a bad idea. Even when sold as a great one.
Neither of those two solutions are to be confused with the Landing Zone Accelerator on AWS which replaced the aforementioned Compliant Framework.
How the hell does anyone keep this stuff straight?
Answer: you don’t have to. That is why there’s Unlimited Leave
Problems Delegating CloudFormation StackSets
Every time AWS breaks out a service from the Management account to be delegated to a separate account I’m pretty excited. They’ve realized how dangerous access to the Management account can be and have really started stepping up service delegation.
Two of the most notable delegations for me have been IAM IC (formerly SSO) and CloudFormation StackSets.
While CloudFormation StackSet delegation is almost 2 years old, I haven’t dug into it until recently. I wish I had because I would have been able to find this annoying problem sooner.
Right now, the trust relationship doesn’t allow of the deployment of “Stacks” that deploy StackSets in the Delegated Account. Only a direct StackSet
SAY WHAT?…
Did you even know that was a thing?
That’s right.
If you didn’t know, just like you can create nested stacks you can actually deploy a StackSet with the AWS::CloudFormation::StackSet CloudFormation resource type.
This works great for so many reasons worthy of its own blog post. However, you can only do this from the Management Account. I’m guessing this is a service trust relationship issue or something along those lines, but I haven’t dug very deep into it. I have opened a support ticket with a TAM and will keep you posted.
UPDATE 10Nov22:
It looks like I neglected an API function of the `CallAs` property in the request. It was for a while CLI Only. Never noticed it on the resource documentation which is clearly documented here.
Revisiting Multiple Account Architecture
In early 2020 I wrote a blog series on Multiple Account Architecture within AWS Organizations. Fast forward almost 3 years, some of the concepts have changed and I have acquired many lumps, bumps, and bruises. This series could use some updating, but a lot is still relevant today.
There have been many posts like this since. I would love to hear your thoughts and issues with multi-account. Reply to this email with those.Just a reminder, I'm working on a post pushing for taking this a step further with multi-org.
Help us grow
Do you know someone else that could benefit from this content?Maybe they suck at AWS Architecture and you don't have the heart to tell them?
Forward them this email or tell them to subscribe 👇
It's not quite the same as sharing those wonderful family vacation photos, but they'll enjoy it a lot more.
