Exclusive management of aws_organizations_policy_attachments

[lorengordon]

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

I am noticing some limitations between how the AWS SCP API is implemented and the implementation of aws_organizations_policy_attachment...

• AWS documents a couple strategies for managing SCPs, using DenyLists or AllowLists
• There is a limit of 5 on the number of policies that can be direct-attached to any object
• AWS auto-attaches the FullAWSAccess managed policy to every object in the OU hierarchy (root, each OU, and each account). This policy allows all access to all AWS services and cannot be modified
• aws_organizations_policy_attachment doesn't have any way of removing the auto-attached policy, so the limit is suddenly 4
• The AllowList strategy requires removing the FullAWSAccess policy from every object, so only the DenyList strategy is actually viable
• All objects must have at least one policy attached, so simply removing the FullAWSAccess policy does not work. Another policy must be attached first, then the FullAWSAccess policy can be removed

I would like to be able to:

• Use either the DenyList or AllowList strategy
• Use all 5 policy attachments

I think both of those would be possible with a couple mechanisms:

• Ability to remove a policy attachment
• Handle the dance around the requirement for at least one policy to always be attached to the object

I am not entirely sure what the "best" or most "canonical" way of getting there might be, but I was considering the "exclusive" management feature that some resources have for some attachments/rules, such as IAM Roles and Security Groups. I could see such a feature being implemented in the aws_organizations_account and aws_organizations_organizational_unit resources, as a new policy_ids argument, or perhaps as a new "plural" resource aws_organizations_policy_attachments?

Happy to adjust this feature request if there is a more preferable approach!

New or Affected Resource(s)

• aws_organizations_account
• aws_organizations_organizational_unit
• aws_organizations_policy_attachments

Potential Terraform Configuration

resource "aws_organizations_account" "account" {
  name  = "my_new_account"
  email = "john@doe.org"

  policy_ids = [
    aws_organizations_policy.example.id
  ]
}

resource "aws_organizations_organizational_unit" "example" {
  name      = "example"
  parent_id = aws_organizations_organization.example.roots[0].id

  policy_ids = [
    aws_organizations_policy.example.id
  ]
}

resource "aws_organizations_policy_attachments" "account" {
  target_id = "123456789012"

  policy_ids = [
    aws_organizations_policy.example.id
  ]
}

References

• https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_strategies.html
• https://docs.aws.amazon.com/organizations/latest/APIReference/API_AttachPolicy.html
• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/iam_role#inline_policy
• https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group#egress

[lauraseidler]

Adding one limitation that we're running into:

• Even when using a DenyList strategy, as the FullAWSAccess policy is automatically attached, it can't be managed by Terraform without importing it for each new account (which is not really feasible with a large number of accounts), so it will also not be re-created if it's accidentally deleted manually

[bulebuk]

If the aws_organizations_organizational_unit and aws_organizations_account resources offered nested policy attachments, it could solve this problem. Terraform would remove any policies not explicitly listed in the nested list of policies, including the FullAWSAccess policy.

[lorengordon]

@bulebuk Give the issue a 👍 if you want to help prioritize it!

[lorengordon]

Not a solution for the exclusive management component of this request, but we just published a lambda terraform module that will replace one SCP with another. It has logic to handle the condition when there is a single SCP attached, as is the case with the FullAWSAccess policy when an account or OU is first created. Using this module in the Organizations account, we're able to utilize the max number of SCP attachments (5), and also effectively able to utilize the AllowList strategy by replacing the FullAWSAccess policy with our own custom allow list.