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
andaws_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
intocore
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 leverageiam.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.
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.