Managing Organizations with Takomo

Managing Organizations with Takomo

In my previous post I introduced Takomo – a new tool to handle CloudFormation deployments [1]. In the second post of the series we’ll take a look how Takomo can help you manage your AWS Organizations and help deploy base infrastructure.

Managing Organizations with Takomo

I have had my own personal AWS account for over half a decade now. Back in 2015 I didn’t have any need for multiple accounts. All my workloads were running fine within a single account. Nevertheless, my appetite grew and in 2017 I migrated to AWS Organizations. I was able to separate different functions from one another. After a while I had separate accounts for backups, shared services etc. Creating accounts is fast. However, management of all these different accounts was rather cumbersome and time consuming. Luckily Takomo can change this.

Steps taken on this post assume you are already running AWS Organizations. If not the case, you enable Organizations either via console/cli or using command tkm org create .

Please keep in mind that the default limit for accounts in Organizations is 4. If you are planning to test the features, make sure you raise the limit via support beforehand!

Creating a new account

I have been working for a while migrating my personal website from Lightsail into VPC. Things are already running smoothly on my development account and I am now ready to create a separate production account.

Before I can create a new account I need to tell Takomo I want the application to support AWS Organizations. This is done by creating a new directory (organization) and configuration file (organization.yml). Below is a bare minimum of what the configuration file should look like.

masterAccountId: "123456789012"
organizationalUnits:  
  Root:
    accounts:
      - "123456789012" #master

masterAccountId is used to define the organization master. It is used to ensure that organization management operations target the correct AWS organization. 

organizationalUnits define the OU structure. In this example we simply define just our Master account to appear on the root OU. We’ll take a closer look at organizational units later in the post.

Now I am ready to create a fresh account.

lauri$ tkm org accounts create --name my-aws-prd --email aws-prd@organization.com

Account information:

  email:                       aws-prd@organization.com
  name:                        my-aws-prd
  role name:                   OrganizationAccountAccessRole
  iam user access to billing:  true

? Continue to create the account? Yes
2020-06-08 14:55:08 +0300 [info ] - Initiate account creation
2020-06-08 14:55:09 +0300 [info ] - Wait account creation to complete...

Account information:

  id:   678901234567
  name: my-aws-prd

Completed in 22.1s with status: SUCCESS

Output of creating a new account with Takomo

My new account is now ready to be taken into use. I could access it with OrganizationAccountAccessRole. However, I want to add some core functionality to the account first.

Managing Organization

Creating new accounts is easy. I could do the same from within the console, CLI or various 3rd party tools. However, not many tools give me capability to manage the entire organization and store the entire organization structure into a configuration file.

First thing I want to do is to organize accounts into organizational units (OU). OU can be used to administer accounts as a single unit. For example, I might want to attach service control policies (SCP) to an OU. Once enabled, these policy files would affect all accounts within the OU.

masterAccountId: "123456789012"
 
trustedAwsServices:
 - cloudtrail.amazonaws.com
 - config.amazonaws.com
 - ram.amazonaws.com
 - sso.amazonaws.com
 
serviceControlPolicies:
 FullAWSAccess:
   description: AWS managed default policy
   awsManaged: true
 AllowedRegions:
   description: Set allowed regions
 
organizationalUnits:
  Root:
   serviceControlPolicies:
     - FullAWSAccess
   accounts:
     - "123456789012" #master
     - "234567890123" #shared
     - "345678901234" #bc
 
  Root/WebProject:
   serviceControlPolicies:
     - AllowedRegions
   accounts:
     - "567890123456" #dev
     - "678901234567" #prd

organization.yml

This is the first step of configuring my organization. Next we’ll walk thru the new parameters on the configuration file:

trustedAwsServices defines trusted access for various AWS services. Takomo will enable all services by default when organization is deployed. Since I don’t want to enable everything I can list only the ones applicable for my use case.

serviceControlPolicies defines SCPs used in the organization. I have defined two policies: FullAWSAccess and AllowedRegions. First is awsManaged, meaning we use policy defined by AWS (FullAWSAccess is the default SCP. It is attached to all accounts in your Organization by default). The latter is a custom policy. The actual policyfile, called AllowedRegions.json, is located in the service-control-policies directory. In this example I limit my accounts to only use European regions and us-east-1.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllOutsideAllowedRegions",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                    "us-east-1",
                    "eu-central-1",
                    "eu-west-1",
                    "eu-north-1"
                    ]
                }
            }
        }
    ]
}

AllowedRegions.json

Last changes are made on organizationalUnits. I need to define all my accounts on the configuration file in order for Takomo to work correctly. I don’t want to create a difficult structure for my existing accounts (master, shared, bc). I will keep my old accounts on Root OU. I will add a new OU (“WebProject”) where I add my development and production accounts. I will also enable additional AllowedRegions SCP to limit which regions can be used on workload accounts.

Now I can start deploying my organization with tkm org deploy command. Tool will display changes about to be done: few new OUs will be created, accounts are about to be moved to new OUs and some SCPs will be attached to accounts. Few seconds later I have my new organization structure ready!

Deployment summary
==================

Task                         Status   Message
---------------------------  -------  -------
Deploy basic configuration   SUCCESS  Success
Deploy policies              SUCCESS  Success
Deploy organizational units  SUCCESS  Success
Clean organizational units   SUCCESS  Success
Clean policies               SUCCESS  Success
Clean basic configuration    SUCCESS  Success


Completed in 1m 16.6s with status: SUCCESS

Deployment summary after running takomo org deploy

Entire Takomo Organizations guide can be found at Takomo documentation [2].

Adding beef on top of the bones

Being able to define organization units and service control policies for accounts within AWS organization is great but let’s be honest, it only gets you so far. The real struggle is to create your base infrastructure. Perhaps you want to deploy IAM users or cross-account roles for your administrators. Or maybe you want to create a VPC and network resources into your workload accounts to limit the burden of your development team. This can be accomplished with config sets.

In the next example I will utilize Takomo to deploy a VPC stack to my development and production accounts. Once my base infrastructure is in place I could hand over these accounts to the actual development team. By default, Takomo will use OrganizationAccountAccessRole to perform this. However, I can define any role available if needed. 

masterAccountId: "123456789012"
 
trustedAwsServices:
 - cloudtrail.amazonaws.com
 - config.amazonaws.com
 - ram.amazonaws.com
 - sso.amazonaws.com
 
serviceControlPolicies:
 FullAWSAccess:
   description: AWS managed default policy
   awsManaged: true
 AllowedRegions:
   description: Set allowed regions
 
organizationalUnits:
  Root:
   serviceControlPolicies:
     - FullAWSAccess
   accounts:
     - "123456789012" #master
     - "234567890123" #shared
     - "345678901234" #bc
 
 Root/WebProject:
   serviceControlPolicies:
     - FullAWSAccess
     - AllowedRegions
   accounts:
     - id: "567890123456" #dev
       vars:
         CidrBlock: 192.168.1.0/18
         EnvironmentName: dev
     - id: "678901234567" #prd
       vars:
         CidrBlock: 192.168.2.0/18
         EnvironmentName: prd
   configSets:
     - baseConfiguration
    
configSets:
 baseConfiguration:
   commandPaths:
     - /base

organization.yml with modified account information

Looking at the existing WebProject OU, we can see first changes in the configuration. I have changed the formatting of my dev and prd accounts. I have also added new sections, “vars” with CidrBlock and EnvironmentName definitions. These variables are passed to my configuration set when I want to deploy my accounts. This way I can define different CIDR blocks for my development and production VPCs.

Let’s continue to the bottom of the file. I have added a new block, “configSets”, where I define my base configuration (baseConfiguration). Naming isn’t important here, I could call it whatever I want. What is important is that I also have something on my commandPaths. In this case “/base” reflects a directory in my stacks folder. configSet is also added to my organizationalUnits configuration for my development and production accounts.

The last thing is to define the actual VPC stack. If you read my previous blog post [1] or have tried Takomo you should already be familiar with how standard Takomo stack configuration looks like. We defined baseConfiguration commandPath to be /base. After this we just need to create a new directory inside the stack configuration directory. I will create a new stacks/base/vpc.yml file and define the required parameters as below.

template: base/vpc.yml
parameters:
   CidrBlock: {{ var.CidrBlock }}
   Project: {{ stackGroup.project }}
   Environment: {{ var.EnvironmentName }}

stacks/base/vpc.yml

If you find the text above confusing here is the whole directory tree:

lauri$ tree
.
├── organization
│   ├── organization.yml
│   └── service-control-policies
│       └── AllowedRegions.json
├── stacks
│   ├── base
│   │   └── vpc.yml
│   ├── config.yml
└── templates
   	 ├── base
    		└── vpc.yml

Now we are ready to deploy the new VPC stacks with tkm org accounts deploy -command. The tool will present me a list of stacks about to be deployed. I am able to review my changes and proceed with the deployment. Once done, I will get a nice deployment summary telling me how my deployment went.

Accounts deployment summary
===========================

Organizational unit  Account       Config set         Command path  Stack path                Stack name    Status   Reason          Time     Message
-------------------  ------------  -----------------  ------------  ------------------------  ------------  -------  --------------  -------  -------
Root/WebProject      567890123456  baseConfiguration  /base         /base/vpc.yml/eu-north-1  web-base-vpc  SUCCESS  CREATE_SUCCESS  1m 3.5s  Success
Root/WebProject      678901234567  baseConfiguration  /base         /base/vpc.yml/eu-north-1  web-base-vpc  SUCCESS  CREATE_SUCCESS  56.6s    Success

Now I am ready to start working with my new accounts!

If you are looking for more guidance how to manage Organizations with Takomo, take a look at official Takomo example [3].

In the next part of the series we will take a look at the advanced features of Takomo, including custom stack resolvers. Stay tuned!

[1] https://webscale.fi/blogi/introducing-takomo-a-new-cloudformation-deployment-tool/

[2] https://takomo.io/config-reference/organization.html

[3] https://takomo.io/examples/managing-organization.html

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *