Feature request: AWS Organizations support

[hashibot]

This issue was originally opened by @bootswithdefer as hashicorp/terraform#12337. It was migrated here as part of the provider split. The original body of the issue is below.

---

AWS Organizations has gone GA and it would be very helpful to manage it with Terraform. Among other things, Organizations provides management of multiple accounts and lets you apply Service Control Policies (similar to IAM policies) to those accounts from outside of their administrative namespace.

https://aws.amazon.com/documentation/organizations/

[beginbot]

This would be great for my current companies needs. so If there is any testing that could be done to help move this along, I offer my services!

[asedge]

I haven't heard a thing. I also have a branch that can create an aws_organization_account but was hoping to get #903 merged first.

[rwdaigle]

Do we even know what HashiCorp’s stance on this functionality is? Are there strategic treasons they wouldn’t support this? I’ve just seen very little guidance or indication for this addition but also not sure what their MO usually is for such things?

[tamsky]

@rwdaigle asks:

Do we even know what HashiCorp’s stance on this functionality is?

I don't speak for anyone but myself, but, I believe their stance is at #903 (comment) from Jul 26, 2017:

Cases requiring a validation are always tough to handle. We try to avoid these complex stuff by either not allowing, either finding a way to do so.
Here, storing the handshake could bring a few drawbacks, since organisations are pretty new.
We started a talk with @catsby on that, will get back to you soon!

Thanks for being patient on this topic :)

[bflad]

Hi, everyone. 👋 Sorry for the long delay in supporting this functionality in the AWS provider and thanks for your extended patience. I'll be picking up the torch here to see this through (meanwhile catching up on the history). I have marked it for an upcoming release milestone, but it could happen sooner depending on how code review and acceptance testing works out. Hopefully, I'll have great news soon.

[jufemaiz]

Good to see this coming back on the agenda @bflad - literally just hit this again and once again blocked. Will await the v1.13.0 milestone.

[bflad]

An initial aws_organizations_organization resource has been merged into master via #903 and will be released with v1.11.0, likely in 2 weeks or so. Thanks to @asedge and all of you have been patient here. I believe @asedge may have an account resource lined up already, which I can try to get reviewed and merged in quickly as well (hopefully). We will have some challenges acceptance testing it on an ongoing basis as AWS currently counts deleted accounts against your service limit.

[asedge]

PR is in for aws_organizations_account. Thanks for the review/merge on the other PR @bflad!

[afeld]

We will have some challenges acceptance testing it on an ongoing basis as AWS currently counts deleted accounts against your service limit.

Raising this issue to our AWS reps, as it's a problem for us too.

[afeld]

You can ask for a service limit increase, so maybe worth asking for a large number with an explanation of the use case in the meantime.

[mwarkentin]

Glad to see this moving again! It would be nice if there was a data source for an organization as well which would let you get a list of accounts within it (along with ids), etc.

[ikoniaris]

+1 this would be a nice addition! Good to see it moving forward. What about AWS SCPs (Service Control Policies)? Are these going to be included in the v1.13.0 milestone?

[zimbatm]

A note for any followers: the current aws_organizations support is nowhere complete. It's lacking most of the interesting bits like account and unit creation.

[bentterp]

This is shaping up real nice! Could we please have the OU ressource also?
I think it would require adding an optional ou parameter to the aws_organizations_account ressourcee as well as to the OU ressource itself - all ressources belong to the organization by default, but can optinally be grouped under an OU.

Whoops! @afeld is right of course, this is covered by #4405 . My bad.

[afeld]

it would require adding an optional ou parameter to the aws_organizations_account ressourcee

See #4405.

the OU ressource itself

See #4207.

[rayterrill]

Also perhaps some mechanism to detach the FullAWSAccess policy from an account?

[rayterrill]

And enable Service control policies on the root?

[afeld]

enable Service control policies on the root

Already possible, though #4229 will allow the root ID to be retrieved dynamically.

[rayterrill]

@afeld I got an error when attempting to attach policies - I needed to manually go into the console and flip the "Service control policies" > "Enable" bit before I could use Terraform to manage policies. Maybe I didn't do it correctly?

[afeld]

Hmmm, not sure - I don't remember having to do that. Maybe best to open a separate issue, with screenshots/steps if you can?

[barundel]

any chance of a resource for creating and managing Organizational units?

[afeld]

@barundel See #4207.

[hhh0505]

@barundel Has anyone found a way to automate the creation of a sub account and dynamically creating a provider with the output to get into the account and continue on? I've gotten to the point where i need to get into the account without any manual intervention , but can't find a way to create a provider to assume role into the new account.

[ryanking]

@hhh0505 when you create a new account you can specify the name of the role which will automatically trust the master account. You should be able to assume that from the master.

[hhh0505]

@ryanking Hey Ryan, i've got that already but the issue is how do you take that role without any manual intervention and create resources within that account.

I've done the following so far:

1. Create AWS account (using variable maps which is updated with new account name and role name)
2. Account gets created and i want to be able to assume role into the account , but there is no way to dynamically create a provider (this is where im stuck). How can i assume role into the account right after the account is created without having to hardcode a provider.

[ruzin]

@hhh0505 You shouldn't need a provider to assume role. Your existing credentials will already be trusted to cross account into the account you just created. I may be wrong!

[ruzin]

@hhh0505 I misunderstood. I see the issue you're facing. Have you thought about outputing the account id and using terraform remote state to use it to configure an assume role provider in another set of tf to create additional resources?

[hhh0505]

@ruzin Thats a great idea, i'm currently creating different remote states per environment. I will test this out to see if it works in my use case.

[thefotios]

(Edited to fix typo pointed out by @tdmalone)

@hhh0505 My team is doing something similar and created some modules to bring up organizations and configure them with a base set of resources. This is a simplified version of how it works.

provider "aws" {
  ...
}

resource "aws_organizations_account" "subaccount" {
  ...
  
  // More about this below
  provisioner "local-exec" {
    command = "sleep 120"
  }
}

locals {
   role_arn = "arn:aws:iam::${ aws_organizations_account.subaccount.id }:role/OrganizationAccountAccessRole"
}

provider "aws" {
  alias = "subaccount"

  assume_role {
    role_arn = "${local.role_arn}"
  }
}

resource "aws_dynamodb_table" "lock_table" {
  provider  = "aws.subaccount"
  name      = "terraform-lock-table"
  ...
}

This works, but we've actually noticed something interesting. There's occasionally a race condition where the account isn't fully configured before trying to use the new provider on resources. So we get an error like:

* aws_dynamodb_table.lock_table: SubscriptionRequiredException: 
   The AWS Access Key Id needs a subscription for the service

We've added the sleep above to try to deal with that, but it would be great if there was a way for the resource to actually wait until it's done being configured (if that's at all possible in the API).

[tdmalone]

For anyone using @thefotios' idea, note that OrganizationsAccountAccessRole should be OrganizationAccountAccessRole (if you're using the default role created for new accounts set up in an Org)

[thefotios]

@tdmalone Good catch, thanks! I updated my example in case people miss your comment when copy/pasting.

[bflad]

Hi again, everyone! 👋 Thanks to @afeld and @bryanlalexander, we just merged a new aws_organizations_organizational_unit resource for managing Organizational Units, which will be released with version 2.10.0 of the Terraform AWS Provider, likely tomorrow. 👍

Just to provide a heads up, we will likely be closing this particular "catch all" support AWS Organizations service issue in the near future since these types of issues tend to not have a definition of done over time, however please be assured that we will try and gather all the remaining existing feature requests, create new GitHub issues for them if necessary, and reference them all in one comment here before closing this out.

Thanks everyone for your patience and the folks like the above that have been making this support possible. ❤️

[bflad]

Please find these reference feature requests (and if interested add a 👍 upvote reaction to the issue) for further tracking and prioritization of AWS Organizations enhancements to the Terraform AWS Provider:

• Support enabling Service Control Policies on the default Root (Organizations: Add Mechanism to enable Service control policies on the root #4545)
• New Data Source: aws_organizations_organization (including fetching account information) (New Data Resource for AWS Organization  #6842)
• Support moving accounts (e.g. root -> OU, OU -> OU) in aws_organizations_account resource (AWS Organizations Move Account support #8281)
• Add account information to aws_organizations_organization resource (Add Account Information to aws_organizations_organization Resource #8579)
• Add account information to aws_organizations_organizational_unit resource (Add Account Information to aws_organizations_organizational_unit Resource #8580)

For any additional feature requests or bug reports with the AWS Organizations service, please create new GitHub issues so we can triage them. Thanks!

[bflad]

The aws_organizations_organizational_unit resource has been released in version 2.10.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

[afeld]

Huge kudos to @bflad for the massive push around this the last few days. The number of big pull requests submitted around Organizations support is staggering. Thanks!

[hhh0505]

(Edited to fix typo pointed out by @tdmalone)

@hhh0505 My team is doing something similar and created some modules to bring up organizations and configure them with a base set of resources. This is a simplified version of how it works.

provider "aws" {
  ...
}

resource "aws_organizations_account" "subaccount" {
  ...
  
  // More about this below
  provisioner "local-exec" {
    command = "sleep 120"
  }
}

locals {
   role_arn = "arn:aws:iam::${ aws_organizations_account.subaccount.id }:role/OrganizationAccountAccessRole"
}

provider "aws" {
  alias = "subaccount"

  assume_role {
    role_arn = "${local.role_arn}"
  }
}

resource "aws_dynamodb_table" "lock_table" {
  provider  = "aws.subaccount"
  name      = "terraform-lock-table"
  ...
}

This works, but we've actually noticed something interesting. There's occasionally a race condition where the account isn't fully configured before trying to use the new provider on resources. So we get an error like:

* aws_dynamodb_table.lock_table: SubscriptionRequiredException: 
   The AWS Access Key Id needs a subscription for the service

We've added the sleep above to try to deal with that, but it would be great if there was a way for the resource to actually wait until it's done being configured (if that's at all possible in the API).

Hey , I'm wondering if you have handled any cases where your accountId is a list and you need to pass this to the provider. I have 10+ accounts and want to go through a list of accountID to provision resources dynamically. I've used your solution above which works great for one particular account, but is there way to pass a list of account id's to the provider and role through this?

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!