route53-patterns for cross account DNS delegation

PR	Champion
#

Description

Context

As mention in https://github.com/aws/aws-cdk/issues/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

[ayush987goyal]

Hi @flochaz and others,

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

Thanks, Ayush

[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!