AWS Organisations: an offer you can’t refuse
Ladies and gentlemen welcome to the greatest day of your lives, today we are covering AWS Organisations; the absolute Godfather of permissions. Organisations are a simple and easy way of managing multiple AWS accounts, you can still use them to manage single accounts and use some of the super useful features that way, but multiple account management is where AWS Organisations really start to shine.
So far we’ve looked at Identity policies and resource based policies. These are for managing access to and from resources and principals, but what if I said this was just the beginning, that there was a way to manage a managed policy, something that determines if a policy can even have certain permissions?
There are a few ways of doing this and one way, aside from using Organisations, is IAM Permission boundaries.
Permissions boundary
It is what it sounds like: a permission boundary. This is an advanced feature, I know, advanced, we in the big boy leagues now 😎. You can only apply Permission boundaries to an IAM identity, and NOT to a resource policy, and once set there is a maximum limit to the amount of permissions a policy can be granted.
Note: This is very important, Permission boundaries are a limit. They say what you can have, they don’t and can’t grant your IAM entity any permissions. For permission you will need an explicit ALLOW in your identity based policy and either no permission boundary or one that grants access to whatever you’re trying to do.
The overall access you have is an intersection of your Identity based policy and the permission boundary 👌
Here’s a really nice little Venn diagram I put together to help explain this point:
Think of it like a ringed fence, you can play wherever you want in the ringed fence (permissions boundary), but only within the ringed fence, you can’t play outside, no matter how much you want to, even if I said you could (managed policy), you can’t get out of the ringed fence.
This works really well when you want to make sure certain services in your account aren’t used by specific IAM Identities. Maybe you have a team that you want to give the permission to provision IAM roles, BUT, you don’t want them to be able to create any IAM roles that are above their own permissions. You can set a permission boundary that limits the permissions they can assign in whatever roles they are creating.
Thereby allowing them to do what they gotta do unimpeded and in a controlled and regulated manner. Winner winner chicken dinner 👌
The scenario
Now, as cool and interesting as Permission boundaries are, they are only applicable within the same AWS account. What if you’re a hot shot cloud architect designing (I tried harder than you think to not use ‘architecting’ here haha) and implementing a multi account infrastructure for a semi large-ish client?
This used to be an uncomfortable thought, multiple accounts mean segregated control, if you were using Permission boundaries, for say your devs, to keep them from removing CloudTrail, you wanna make sure CloudTrail (an AWS service that tracks any and all API calls, think a ‘security camera’), then you gotta copy and paste this across all of your accounts. And now you want one of your accounts to not have access to IAM roles, and the other not to be able to launch EC2s and suddenly you’re looking at some serious policy drift.
You’re smart though, you wanna make sure every time a change is made to a permission boundary you keep this documented, so you are aware and on top of things. So you keep an excel sheet, we’ve all been there, that excel sheet you promised you’d keep updated, tracking all the changes 👍
But now you have 1, 2 or even 3 other admins that can administer accounts, they know what they’re doing but the permission boundary drift, it’s increasing and maybe one of them isn’t super diligent at keeping the spreadsheet up to date. The system is falling apart.
Enter stage left — AWS Organisations.
Welcome to the Organisation — may I take your coat?
Here we have a hierarchical view of our example Organisation. It kinda looks like an upside down tree, sprouting from the top. With our Root/ Master account, 2 OU’s and a total of 4 accounts. In the green we have SCP’s applied to different entities, some, not all.
SCPs are like permission boundaries you assign to accounts (Master or member) and OU’s that work across accounts but still within the Organisation.
Providing, amongst many other things:
- consolidated billing for all your AWS accounts
- centralised management of your accounts
- Policy and tag management across accounts
All of this is done from within your master account. This is the grand daddy, the Godfather 🙌🏼
The Root of all your problems
We start off with the root account, aka the Master account, the head of the Family. The top dog. This is where the everything begins, and you can only have one. Your root account is the only place where you can add new accounts, invite new members, remove members — no one leaves the mob, but you can leave the AWS Organisation.
The root account of an organisation is immutable. You can’t change out for any other account. To do so you gotta delete the Organisation and recreate it all. Once you are the head of a mob family, welcome to the rest of your life, members come and go, but this is for life 👊
As well as a place for managing invitations, root accounts are also designated as the money handlers, remember a little thing called consolidated billing? Well as the head of the family, it’s no surprise this is where the money flows through the Organisation. All the relevant charges wracked up by the member accounts are aggregated into a single bill that is handled and paid for by the root account. Wow, what an absolute gentleman. This is a pretty fair deal because the root account, as well as having to foot the bill, is in charge of saying what goes and what doesn’t.
Besides the root account, you have the member accounts, these are either directly associated with the root account, like Account A above, or as part of an Organisation Unit like the other accounts shown above.
Organisation Unit
An organisation unit, or OU as we know it from the streets, is a container for accounts. A simpler way of ‘organising’ and grouping your accounts.
An account can only belong to one single entity, and that entity can be either the Root account or an OU. That means you can attach the member account directly to the main man; the root account OOOORRRRR you can create an OU under the root account, or under another OU and assign the member account there. What you CAN’T do, like big can’t do that’s why it’s all capitalised and everything, is link two member accounts. Clearly marked by that huge and obvious crossing out in the diagram above. We here at Hamzah blogs do not condone the use of member account linking… mostly because you can’t actually do it.
Note: an account can only be a member of one Organisation at any one time. And can only have one parent node — as seen in the useful diagram above. You can’t have an account that shares parents, sorry parents reading this 🤷♂ you gotta pick your favourite.
Getting back to OU’s, as a container they have a few useful, very very useful, qualities:
- They can ‘contain’ other OU’s
- And those OU’s can hold other OU’s or accounts…
- They can hold one or more accounts, and the big-ish one
- If you apply a Service Control Policy to an OU it applies to everything within the OU, that includes ALL entities in any subsequent OU and account, no matter how far down the tree you go
This last point is rather important. Say you apply SCP3 on Account C, that’s sitting at the bottom of our upside down tree. With nothing below it SCP3 has nothing to cascade down to besides the account itself. Seems easy, means that Account C only has to fulfil the permissions set in SCP3… well… unfortunately it isn’t that simple. Remember when we said SCPs cascaded down?
Well this is best shown in the diagram above, the accounts you are assessing the permissions for are a culmination of all the SCP’s applied to any and all parent nodes (nodes being any entity — root accounts, member accounts and OU’s in the diagram) that you can trace back up the tree to the Root. This includes any SCPs applied to the root account too.
However, an IMPORTANT distinction that has to be made is that attaching an SCP to a root applies it to the Organisation as a whole and all the member accounts within that Organisation but NOT the root account itself. That is all, as you were 😊
Say SCP1 stops a user from launching any EC2 by explicitly denying the ec2:runInstances action, this means that no one in OU-A, OU-B and Account C can launch EC2 instances. Even if they have an explicit allow in their SCP and the IAM Identity has an Allow too.
Remember: an EXPLICIT Deny trumps ALL EXPLICIT Allows
This means, any actions in Account C will be validated against the logical result of the permissions granted in SCP1, SCP2 and SCP3.
Wow, ok, I know I know, that was a lot, I’m literally shaking although I attribute like 70% of that to caffeine jitters but the other 30% is defo for this! *nodding profusely* You’re doing amazing though, this is a big topic and we are flying through a lot of awesome things!!
Remember: an SCP applied to an OU will cascade down and get itself on everything. I once got a curry stain on my favourite white shirt… like the SCP, that curry stain did not budge… bye bye Giorgio Armani shirt that made it look like I worked out when I never did 😔
I don’t know Marlon Brando… I don’t know. How DID things ever get so far?!?
SCPs — Super Cool Policies
Damn… ok maybe it doesn’t stand for that but how cool would it be if it did?!? Service Control Policies (the not as hip version) are super charged Permission boundaries, they are applied to accounts and OU’s from the Root account. They can also be applied TO the Root account and come in two super cool flavours:
- Allow List Strategy — explicitly specifying access is allowed
- Deny List Strategy — explicitly specifying access is not allowed
For the Allow List Strategy, you are essentially using a whitelist, any actions specified here are explicitly allowed and anything not specified is implicitly blocked (think: YOU SHALL NOT PASS…). You basically have a blanket DO NOT ALLOW policy… except those few actions that you specify. This is hella useful when you want to limit what services your organisation can use and that is a relatively short list, using the Allow List Strategy to add an SCP on the Root account and say bye bye to all the unwanted services that cost WAY too much and aint nobody got money for that.
Note: by default the FullAWSAccess AWS managed policy is added to all accounts and OUs. Remember AWS managed policies? The ones you ain’t gotta worry about keeping up to date on services as AWS will do that for you? This just means by default all services are available to use, its a free for all!! So when you start restricting access using SCPs you are basically replacing this default policy with yours.
Next up we have the Deny List Strategy, this is the default when you open up that fresh new account. Everything is allowed, because of the AWS managed policy FullAWSAccess. The difference here is that, unlike Mr Allow List Strategy, instead of replacing the AWS managed policy and blocking EVERYTHING and then allowing only specific services, here you explicitly block specific services and actions and everything else is allowed. This is basically applied on top of the FullAWSAccess and then relies on the EXPLICIT deny to block any unwanted services.
Note: SCPs can not grant permissions, they simply say what can happen and are evaluated along with Identity and Resource policies. Restricting actions by applying SCPs to the root account restricts the actions for the whole organisation, so if you can’t reintroduce any permissions at a lower level if you decide there’s one specific account that needs them so be weary of that.
The Handshake 🤝
For those people who are unaware of this phenomenon, it was mainly practised by pre-coronans meeting each other, a form of greeting expressed through the interlocking of ones hands for a brief 2–3 seconds… I had to shake my own hand to calculate how long a normal handshake should last… It’s been a while. What is now just a remnant of the past for us is still a very valid way of doing things between a member account looking to join the mob… I mean the AWS Organisation**.
Handshakes in AWS happen between the Root account — the inviter — and the member account looking to join — the invitee. Invites can only be sent by the Root account and are sent to the account ID or the email address associated with the member account.
Handshakes messages ensure that both parties are kept up to date in the process of the invitation, as messages are passed back and forth to update the status of the process at every stage. These are visible only when you are working with the AWS Organisations API or CLI, so you gotta get your hands dirty to see this handshake… that is a really odd sentence 😂
Note: to delete an Organisation you gotta delete the Root account, makes sense, to take out the mob you gotta take out the top dog. Then you become the top dog… except in AWS where you just don’t have an Organisation anymore.
Another time you’ll see the handshake used is when you, as the master account, are switching from using only the consolidated billing features to using the all feature set option… which is a nice Segway intooooooo
Feature Sets
I know… that’s was super smooth 😎
You know we have the two options for feature sets:
- All features, which is the default, and,
- Consolidated billing
So far we’ve talked a lot about the benefits of having an Organisation, focusing around the permission controls, for this you need to have All Feature set enabled, and this comes as default which is great, AWS once again reading our minds. Some folks may choose not to have this for whatever reason, maybe they just don’t need the other features so why introduce unnecessary overhead? 🤷♂️
For these folks we have the consolidated billing feature set, with this you only have access to the consolidated billing side of things, which is a MASSIVE plus still. BIG benefit of consolidated billing is you can wrack up the bill across all of your accounts and benefit from AWS’s lovely volume discounts — did someone say KA’CHING $$? I THINK SO!
And the best part yet? (I’m beginning to sound like an informercial… I know haha I’m hearing it too 🤦♂️ ) Once you decide you want to take on the advanced feature set of All Features, you can just enable this in your account. One small caveat is that you’ll have to re-invite and re-handshake the member accounts before they are susceptible to this new law being imposed. Kinda cool right? *nods profusely*
Note: we spoke about leaving an Organisation earlier and yes that is all good, BUT, big “but” here, the Root account can apply an SCP preventing any member accounts from leaving by preventing access to the organizations:LeaveOrganization action… wow… not so different from the mob after all huh 🤔
So if you have an account you can’t afford to leave due to governance or security or whatever reason, you can make sure it never leaves the family.
Tag Policies
Before we finish off this awesome post, I want to quickly cover tagging policies. These are applied in a similar fashion to SCPs from the Root account to other entities, including the Root account itself.
Once applied these are enforced on specified resources. Tagging policies help you to standardise tagging across your accounts, to help with monitoring, logging, billing etc.
Tagging rules are defined in the tag policy and in doing so tags that are defined in the tagging policy, for example TeamName can be made to have specific values. And should any troublemaker decide to use this tag key of TeamName without one of the specified teams from the tagging policy list then the action of creating the resource will be prevented from completing.
One small caveat is that this works on Tag keys that are specified in the tagging policy, untagged resources and resources using tags not specified are not evaluated or acted upon by the tagging policy.
This doesn’t make anyone tag anything, this just makes sure IF they are using certain tag keys they use specified values for standardisation.
A golden nugget I will bestow upon you before we conclude that would likely be something that may cause some confusion unless you already know about it: AWS Organisations, though accessible in all regions, operates only in US East Region (N. Virginia). You know… like the song… country rooads, take me home, to the place I belong, West Virginia… except this is North Virginia — where AWS tends to launch most of their new services first, also the region that has the most reliability issues so avoid when possible. All this means for your Organisations, is that for any CloudTrial logging or Cloudwatch eventing you’ll need to have access to that region and then you’ll be ballin’ 😎
Conclusion
And there we have it folks, this has got to be the most fun I’ve had yet writing up a blog post. I don’t even know why, I think it’s because Organisations are such a cool topic, there is so much happening and the whole multi account structure is so common place in the industry right now that knowing how it is managed is a very rewarding journey.
Filled with aha’s and oh’s and ooohhh’s I really enjoy learning about Organisations and realising it isn’t all that hard to set this stuff up once you understand why you’re doing it.
Thank you again for joining me on this journey. Stay safe, wash your hands, and have a damn great weekend!! 😊 Or else 😏
