AWS Organizations

Terminology and Concepts

Organization

An organization is the entity that you create to consolidate your AWS accounts

Root

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:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

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

A 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.

Blacklist EC2

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:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyEC2",
            "Effect": "Deny",
            "Action": [
                "ec2:*"
            ],
            "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:

Restrict Regions

A second test was to allow a service but only in a specific region. I used the following sample policy provided by AWS:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllOutsideUKI",
            "Effect": "Deny",
            "NotAction": [
               "iam:*",
               "organizations:*",
               "route53:*",
               "budgets:*",
               "waf:*",
               "cloudfront:*",
               "globalaccelerator:*",
               "importexport:*",
               "support:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "eu-west-1",
                        "eu-west-2"
                    ]
                }
            }
        }
    ]
}

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:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireMicroInstanceType",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotEquals":{               	
          "ec2:InstanceType":"t2.micro"
        }
      }
    }
  ]
} 

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:

• IAM
• Policy
• Organizations