[thenom]

Issue #, if available: None. Builds on #358 / #359

Description of changes:

Problem

route53_zone_id and auth_route53_zone_id must name hosted zones in the deployment account. Many organisations keep their public hosted zones in a central DNS account, so they have to set the zone IDs to empty and manage the certificate-validation and alias records by hand.

#359 handles a zone in another account through acm_certificate_arn plus the dns_target outputs, which leaves the records to be published by hand. This PR adds an opt-in path for the case where that zone is Route 53 and the deployer can assume a role in its account; the existing paths are unchanged.

Solution

• Add an optional dns_role_arn variable, validated as an IAM role ARN or empty.
• Add an aws.dns provider. It assumes dns_role_arn when set; otherwise it uses the deployment account's own credentials.
• Write every Route 53 record through aws.dns: certificate validation in modules/domain, the app alias records and the auth alias records. modules/domain declares the new configuration alias.
• Update the route53_zone_id description to say the zone may be in another account.

The role in the DNS account needs permission to manage records in those zones (for example route53:ChangeResourceRecordSets, route53:GetChange, route53:ListResourceRecordSets and route53:GetHostedZone) and a trust policy for the deploying principal.

Testing

• terraform fmt -check, terraform validate -no-tests and every terraform test suite from the Terraform workflow pass on Terraform 1.15.0 (auth-domain, waf, yjs, managed-environments, lambda-packaging). The SSO plan-privacy test also passes.
• These changes already run as a patch in our own deployment. There dns_role_arn is set and the zone is reached through the assumed role.

Impact

• With dns_role_arn empty, the records are created with the same credentials as before. The only plan difference is the provider address in state, which Terraform handles without replacing anything.
• If feat(terraform): add extra_tags to the providers' default_tags #600 (extra_tags) merges too, the new provider should merge extra_tags into its default_tags. I'll update whichever lands second.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.