Terminology and Concepts
An organization is the entity that you create to consolidate your AWS accounts
The root is the parent container that is automatically created when you create an organization. Currently, you can only have one root.
Organizational Unit (OU)
An organizational unit is a container for accounts within a root. You can create a hierarchy by creating an OU within an existing OU. You can then add AWS accounts to an OU. An account can be in only one OU in a root
Setting up Organization Structure
To have a play with organizations, I logged into one account (Root Account) and created an organization. I then invited another account (Second Account) to join, which I accepted. Next I created a new OU called
Production and assigned the Second Account to it.
One of the first things to note was that a default
FullAWSAccess policy was attached to the root, all OUs and all accounts. The policy itself looked as follows:
The important fact to remember is that this doesn’t actually grantthe permissions. Instead, it enables adminstrators in those accounts to delegate access by attaching standard IAM policies to users, roles or groups in those accounts.
Service Control Policy
Service Control Policy (SCP) is a type of policy used to manage an organization. They provide central control over the maximum available permissions for all accounts in your organization. It essentially defines a guardrail for what actions accounts can do.
As mentioned above, by default a
FullAWSAccess policy is already created and attached. I wanted to demo some simple tasks that can be carried out.
The first one was to block anyone in the
Production OU from launching an EC2 instance (remember the future is serverless). I quickly created a simple policy that denies any action on EC2 by any resource:
An alternative would have been to whitelist approved services by only allowing access to them, and removing the
FullAWSAccess policy. When I tried to start up a new EC2 instance I got the following in the console:
A second test was to allow a service but only in a specific region. I used the following sample policy provided by AWS:
This policy uses the
NotAction element with the Deny effect to deny access to all the actions not listed in the statement. The services in the statement are examples of AWS global services that have a single endpoint physically located in the us-east-1 region.
I got the same error message in the console when in a region outside Ireland or London. However, when switching into one of those two regions I was able to launch an instance.
Out of curiousity, I amended to the policy to remove
iam:* as a global service endpoint. Now when I logged back into the console and went to IAM I got the following:
Control Instance Type
The final example was to use a condition to restrict EC2 instances being launched to an instance type of
t2.micro. This used the following policy:
As expected, when I launched an instance that was not a
t2.micro I got the following error message:
This is also an example of why knowledge of policies and specific actions is important. What I was able to do was to launch an EC2 instance of type
t2.micro, stop it, change the instance type, and then restart. The reason this worked is that
ec2:RunInstances is the action when an EC2 instance is launched for the first time. To stop someone from being able to shutdown an instance and restart with a difference instance, it was just a case of adding
ec2:StartInstances as an action to the policy. When I then tried to change the instance and restart, I got the following error message: