aws / aws-cdk-rfcs

RFCs for the AWS CDK

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

AWS Organizations L2 Construct

pflorek opened this issue · comments

Description

I would like to have AWS Organization L2 constructs implemented.

As of CDK v2.51.0 generated L1 constructs aws_organizations.CfnAccount and aws_organizations.CfnPolicy are available (CFN spec v97.0.0). CfnOrganizationUnit will be available with CFN spec v98.0.0

We are looking for an API Bar Raiser 🚀

It would be really great to have CDK support to manage the Organization hierarchy like

    const organizationalUnit = new OrganizationalUnit(stack, "OrganizationalUnit", {
      organizationalUnitName: "AnyOrganizationalUnitName",
    });
    const account = new Account(stack, "Account", {
      accountName: "AnyAccountName",
      email: "patrick.florek+cdk@gmail.com",
      parent: organizationalUnit,
    });
    const policy = new Policy(stack, "Policy", {
      policyName: "AnyPolicyName",
      description: "AnyDescription",
      content: {
        // ...
      },
      targets: [PolicyAttachmentTarget.ofAccount(account)],
      policyType: PolicyType.SERVICE_CONTROL_POLICY,
    });

The L2 constructs may also help a lot to maintain the sequential dependency chain. Either by Aspect cdk-organizations or explicit in the L2 constructs.

There are already two custom AWS construct libraries to manage AWS Organizations with the CDK:

Here is a draft PR aws/aws-cdk#23001

There are some design decision to be discussed like inversion of parentship

organizationalUnit.addOrganizationalUnit(childOU);
organizationalUnit.addAccount(childAccount);
organizationalUnit.attachPolicy(policy);

vs.

const organizationalUnit = new OrganizationalUnit(stack, "ChildOrganizationalUnit", {
  organizationalUnitName: "AnyOrganizationalUnitName",
  parent: parentOU,
});

Writing integ.tests wouldn't be easy, since closing an account underlies some limitations.

To get a first working increment it's enough to get the organization root and postpone Organization, EnablePolicyType, DelegateAdministrator, EnableAwsServiceAccess into a follow-up. Also later on we can easily add L2 constructs for AI, Backup, Tag and Service Control Policies.

This topic has a lot of votes aws/aws-cdk#2877

I strongly believe having this in the CDK is more valuable instead of a custom construct library, so we can focus in the construct libraries on opionated constructs, while having the same interfaces shared by the aws-cdk-lib.

Ideas 💡

  • Organization Root as AwsCustomResource'
  • Organization Root via cx-api
  • IAccount into core useful for SSO, IAM, ...
  • Managing dependencies as Aspect
  • Managing dependencies by node.addDependency
  • Import existing Organization into CFN Stack
  • Using Account, OrganizationalUnit, Policy standalone
  • Distinct constructs for AiPolicy, TagPolicy, BackupPolicy, ScpPolicy
  • ScpPolicy may leverage iam.PolicyDocument (SCP is more restrictive)

See aws/aws-cdk#23001 (comment)

Roles

Role User
Proposed by @pflorek, @hoegertn
Author(s) @pflorek, @hoegertn
API Bar Raiser @Naumel
Stakeholders @alias, @alias, @alias

See RFC Process for details

Workflow

  • Tracking issue created (label: status/proposed)
  • API bar raiser assigned (ping us at #aws-cdk-rfcs if needed)
  • Kick off meeting
  • RFC pull request submitted (label: status/review)
  • Community reach out (via Slack and/or Twitter)
  • API signed-off (label api-approved applied to pull request)
  • Final comments period (label: status/final-comments-period)
  • Approved and merged (label: status/approved)
  • Execution plan submitted (label: status/planning)
  • Plan approved and merged (label: status/implementing)
  • Implementation complete (label: status/done)

Author is responsible to progress the RFC according to this checklist, and
apply the relevant labels to this issue so that the RFC table in README gets
updated.

commented

any update on this? 👀

What is needed to get some movement on this RFC? Can someone please provide either approval or feedback about what needs to be improved? The original PFR can be considered as starting from the time aws/aws-cdk#2877 was opened in July 2019.

It appears @Naumel self-unassigned in July of this year. If you were impacted by layoffs or PIP, sorry for that... but is there anyone we can escalate this to? @TheRealAmazonKendra ? re: aws/aws-cdk#23001 (review)
cc @MrArnoldPalmer

Closing this ticket. We believe the functionality is beneficial, but does not intersect with the core framework and should be vended and maintained separately.