Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AWS Organizations L2 Construct #465

Closed
3 of 11 tasks
Tracked by #23001
pflorek opened this issue Nov 20, 2022 · 3 comments
Closed
3 of 11 tasks
Tracked by #23001

AWS Organizations L2 Construct #465

pflorek opened this issue Nov 20, 2022 · 3 comments
Labels

Comments

@pflorek
Copy link

pflorek commented Nov 20, 2022

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: "[email protected]",
      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.

@Abdu03
Copy link

Abdu03 commented Oct 16, 2023

any update on this? 👀

@mbeacom
Copy link

mbeacom commented Dec 8, 2023

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

@awsmjs
Copy link
Contributor

awsmjs commented Dec 14, 2023

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

@awsmjs awsmjs closed this as completed Dec 14, 2023
@mrgrain mrgrain added status/rejected and removed status/proposed Newly proposed RFC labels Dec 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants