Add support for adding accounts via control tower

[simonweil]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

When utilizing control tower, new accounts need to be created via control tower or promoted from an unregistered OU to a registered OU (As described here).

This is not currently possible via this TF AWS provider.
Here is a provider that does allow creation of new accounts via control tower:
https://registry.terraform.io/providers/idealo/controltower/latest/docs/resources/aws_account

New or Affected Resource(s)

• aws_controltower_member_account
• aws_controltower_enroll_member_account

Potential Terraform Configuration

resource "aws_controltower_member_account" "account" {
  name                = "AccountNAme"
  email               = "aws-admin@example.com"
  organizational_unit = "Sandbox"
  role_name           = "Somerole"

  sso { # optional
    first_name = "John"
    last_name  = "Doe"
    email      = "john.doe@example.com"
  }
}

References

Didn't find any...

[johnthedev97]

Control tower doesn't have APIs, at least yet (Ref: https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-with-control-tower.html) so a straight forward implementation won't be possible.

The referenced provider is actually using the AWS service catalog product created by the control tower to create the account.

My quick thoughts:
You could probably (because I haven't tested it myself) achieve the same using the existing aws_servicecatalog_provisioned_product resource

WARNING: not tested, just to convey the idea

resource "aws_servicecatalog_provisioned_product" "example" {
  name                       = "example"
  product_name               = "AWS Control Tower Account Factory" # Referenced provider as well assumes the name
  provisioning_artifact_name = "AWS Control Tower Account Factory" # May have to use ID in case of versions

  # You can reduce the multiple provisioning_parameters using "dynamic" and for_each constructs
  provisioning_parameters {
    key   = "AccountName"
    value = "my-new-account"
  }

  provisioning_parameters {
    key   = "AccountEmail"
    value = "aws-admin@example.com"
  }

  provisioning_parameters {
    key   = "ManagedOrganizationalUnit"
    value = "Sandbox"
  }

  provisioning_parameters {
    key   = "SSOUserFirstName"
    value = "X"
  }

  provisioning_parameters {
    key   = "SSOUserLastName"
    value = "Y"
  }

  provisioning_parameters {
    key   = "SSOUserEmail"
    value = "john.doe@example.com"
  }
}

It might be helpful to enhance aws_servicecatalog_product data source to have filters that would help search the product by name and identify the active version so that we don't have to hard code the name of service catalog product name used by account factory.

[mbevc1]

Not strictly related to original suggestion, but we got first API for Control Tower and can enable Guardrails: https://docs.aws.amazon.com/controltower/latest/userguide/guardrail-api-examples-short.html

[CalvinRodo]

While not as nice as managing it using my own Terraform setup, Account Factory for Terraform is a decent alternative that allows you to create and enroll existing accounts through Terraform.

[mbevc1]

Note: using Idealo's provider might give you a better experience: https://registry.terraform.io/providers/idealo/controltower/latest/docs/resources/aws_account

But as soon as concurrency will be supported I think it will massively simplify all current approaches ;)

[bschaatsbergen]

Control Tower Landing Zone APIs are now picked up - hopefully the accounts itself will be released soon, I'll pick that up 👍🏼

[mbevc1]

Cool, yeah seems only LZ at the moment: https://docs.aws.amazon.com/controltower/latest/APIReference/API_UpdateLandingZone.html

[jylitalo]

You can launch new accounts with aws_servicecatalog_product (at least if your using Control Tower Account Factory). It creates 'AWS Control Tower Account Factory' under Products in Provisioning. Your enrolled accounts should show up as 'Provisioned Products'. For example, if you've enrolled something from Control Tower, it can show up there as Enroll-Account-ACCOUNT_NUMBER

[joelmccoy]

@jylitalo Are you saying you can provision an new AWS account that will be enrolled with Control Tower (if you already have Control Tower setup) with the aws_servicecatalog_product resource? If so, what would that look like?

[mbevc1]

Yes, you need to select/pick AWS Control Tower Account Factory product and provision it using req. parameters, e.g. email, SSO

[joelmccoy]

@mbevc1 Is there a documented schema somewhere for the expected parameters? Where are you getting the parameters like email, account name, etc.?

[mbevc1]

Names should match to what you see in Catalog when you check one of the provisioned products. I cannot find an example ATM, but will paste here if I can dig it out :)

[jylitalo]

You see them, if you go in ServiceCatalog into Administration -> Product list -> AWS Control Tower Account Factory -> click one of the "Product Versions" and check what it says in Template tab.

AWSTemplateFormatVersion: 2010-09-09
Description: AWS Control Tower Account Factory Template (DO NOT DELETE)
Parameters:
  AccountName:
    Description: "Account name, the new managed Account will be created with this name."
    Type: String
    AllowedPattern : ".+"
  AccountEmail:
    Description: "Account email, must be unique for each AWS Account."
    Type: String
    AllowedPattern : "[^\\s@]+@[^\\s@]+\\.[^\\s@]+"
  SSOUserFirstName:
    Description:  "SSO user first name."
    Type: String
    AllowedPattern : ".+"
  SSOUserLastName:
    Description:  "SSO user last name."
    Type: String
    AllowedPattern : ".+"
  SSOUserEmail:
    Description: "SSO user email. A new SSO user will be created for this email, if it does not exist. This SSO user will be associated with the new managed Account."
    Type: String
    AllowedPattern : "[^\\s@]+@[^\\s@]+\\.[^\\s@]+"
  ManagedOrganizationalUnit:
    Description: "Your account will be added to this registered organizational unit. The list includes top-level and nested OUs registered with AWS Control Tower. You can search for an OU by name or ID. To manage these OUs, go to AWS Control Tower."
    Type: String
    AllowedValues:
      - opco1 (ou-abcd-1234...)
      - opco1-dev (ou-abcd-5678...)

[jylitalo]

One interesting thing that I noticed a while ago was that ManagedOrganizationalUnit is really picky on what you give it as input.
Let's say that your organization's top level OUs are called L1, L2, L3 and under Root and you create L1a, L1b, L1c under L1. Account Factory happily accepts L1, L2 and other top level OUs as valid values, but if you try to give it L1a for example as a value, it will claim that L1a has not been enrolled in Control Tower. Same thing if you try to give "ou-abcd-1234..." of L1a as value for ManagedOrganizationalUnit. However, if you say that ManagedOrganizationalUnit is "L1a (ou-abcd-1234....)" then it will happily move your account under that L1a OU.

[jylitalo]

One topic related to AWS accounts creation with Control Tower is Control Tower's Blueprints.

It seems to be overly complicated process in a sense that if I have ControlTower account, Blueprint account and Target account and want to apply Control Tower Blueprint, what happens is that

• Blueprint account shares ServiceCatalog Portfolio to Target account
• something creates new IAM role into Target account that allows Blueprint account to execute terraform or whatever access Blueprint account requires to get Blueprint implemented
• Target imports that ServiceCatalog Portfolio that Blueprint account shared
• ... and something triggers the Blueprint operations into action

There might be some more steps that happens behind the scenes, since AWS Control Tower is the thing that orchestrates this whole show, but once it has been done, it shows up as Provisioned Product in Target accounts ServiceCatalog.

I really wish that AWS would give us decent API, because right now Control Tower feels like second-class service in big picture, which might be perfectly fine for ClickOps, but it is really frustrating if organisation wants to move from ClickOps into infrastructure as a code (IaC).

[mbevc1]

Just to add to the latest comment, I agree API implementation is quite not feature complete for CT, but there are also few other options to manage CT via IaC:

• AFT: https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html
• CfCT: https://docs.aws.amazon.com/controltower/latest/userguide/cfct-overview.html
• LZA: https://github.com/awslabs/landing-zone-accelerator-on-aws
• Blueprints that were mentioned
• or 3rd part providers, such as: https://github.com/idealo/terraform-provider-controltower

Currently I think LZA would give you best experience and not stopping you using TF later on.