route53-patterns for cross account DNS delegation

[Florian Chazal]

PR	Champion
#

Description

Context

As mention in aws/aws-cdk#8776, It is quite common to securely manage DNS records in a multi accounts organization to have an APEX domain in a dedicated account and sub domains delegated to different accounts (per regions, per stages, per teams ...).

Objectives

• Easy setup
• Secure top level domain
• Developer freedom to create subdomains for new services

Glossary

In this RFC we will call the parent zone, the zone representing the higher level of the DNS domain (yourdomain.com for instance), and child zone the sub zone representing the sub DNS domain scoped to a specific sub account (such as dev.yourdomain.com for a dev account) and the service zone the sub zone representing the sub DNS domain scoped to a service instance in a specific child zone (app1.dev.yourdomain.com).

TL;DR;

This RFC propose the following flow

API flow proposal 1

DNS account CDK stack

1. create parent zone as usual

   const parentZone = new route53.PublicHostedZone(this, "TopZone", {
     zoneName: "yourdomain.com"
   });

2. create the subzones

   const devSubZone = new route53.DelegatableZone(this, "DevSubZone", {
     zoneName: "dev.yourdomain.com",
     parentZone: parentZone, // optional
     authorizedPrincipals: [accountPrincipals]
   });

The last call will create:

• a route 53 zone dev.yourdomain.com

• a NS record in parentZone pointing to NS servers given by the dev.yourdomain.com

• a role called <accounId>-<subzoneName>-dns-update assumable by the listed account principals and with the following permission:

    {
      resources: ["*"],
      resources: [devSubZone.hostedZoneArn],
      actions: [
        "route53:GetHostedZone",
        "route53:ChangeResourceRecordSets",
        "route53:TestDNSAnswer",
      ],
    }

Stage/team/region... specific account stack

const serviceDNSZone = new CrossAccountDelegatedZone(this, 'service1DNSZone', {
  parentZoneAccountId: dnsAccountId,
  targetRoleToAssume: targetRoleToAssume, // can potentially be deduced from defined roel name structure <accounId>-<subzoneName>-dns-update
  targetHostedZoneId: targetHostedZoneId, // can potentially deduced from zoneName ( with 'zoneName.split(".").splice(1).join(".")' ) + a ListHostedZonesByName call
  recordName: 'service1.dev.yourdomain.com'
        });

API proposal 2

Modify each record type (such as https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-route53.AaaaRecord.html) to have 1 new optional attribute: dnsAccountAssumeRole. This will enable cross accounts records creation and enable any kind of use case.

Maybe we can as well propose an additional trust principals to HostedZone https://docs.aws.amazon.com/cdk/api/latest/docs/@aws-cdk_aws-route53.IHostedZone.html to automatically create the assumeRole that allow its update.

Progress

• Tracking Issue Created
• RFC PR Created
• Core Team Member Assigned
• Initial Approval / Final Comment Period
• Ready For Implementation
  • implementation issue 1
• Resolved

[Roman Naumenko]

Hi,
I'm interested in this use case.

What do you think about levereging cdk pipeline for passing zone information around for delegation?
Pipeline can deploy sub-zones first, maybe even in parallel.
Then it runs cdk for tld and configures delegation using input from previous steps.

In this case there is no need for custom roles and cross account access, pipeline package can take care of it.
Thanks!

[ijemmy]

@OperationalFallacy

Hi,
I'm interested in this use case.

What do you think about levereging cdk pipeline for passing zone information around for delegation?
Pipeline can deploy sub-zones first, maybe even in parallel.
Then it runs cdk for tld and configures delegation using input from previous steps.

In this case there is no need for custom roles and cross account access, pipeline package can take care of it.
Thanks!

I'll prefer to have standalone solution that doesn't rely on cdk pipeline.

If we have that, we could create stack(s) with all required resources and use Pipeline's addApplicationStage(). From the diagram above, I could imagine an organization that wants a separate team to control DNS account and give access to developer team on requests. @flochaz 's proposal would support that.

Regarding the custom roles, how does pipeline package take care of that? I thought we need to create roles/permissions manually anyway.

[Roman Naumenko]

With workflow modeled in the pipeline, there is no need for custom or assumed roles. The pipeline itself would enforce segregation of duties, e.g for the new subdomain, you'd submit a pull request to add a subdomain.
The pipeline will run, create a zone in the target account... then update delegation in the apex domain.

The last call will create: a route 53 zone dev.yourdomain.com a NS record in parentZone pointing to NS servers given by the dev.yourdomain.com

If a subzone created and then it is allowed to change records in apex (even through assume role) - how do you envision enforcing or separating controls?

give access to developer team on requests
Maybe the team that manages apex can have some role with conditions to allow changing specific records based on principal/tag, which is the case in "API proposal 2" I think.

[Ayush Goyal]

Hi @flochaz and others,

An initial implementation of this functionality is pushed in aws/aws-cdk#12680
Please do check it out and give it a try. You can create new feature requests if more customizations are needed.

Thanks,
Ayush

[Florian Chazal]

Yeah just saw that, awesome ! I think that should cover what I wanted to achieve here . closing