By using AWS re:Post, you agree to the AWS re:Post Terms of Use

Grant permission to different account to update Route53

0

I have a nodejs script that builds a whole application infrastructure for new accounts in my organisation. The new hosts, api gateway, buckets etc. are within the new account, but the DNS records for these need to be in the account that administers the parent zone.

How can I grant federated access to a different account to allow them to create new public hosted zones as well as NS/SOA/A/CNAME records in the parent zone?

I've read loads about it but can't decide if it's actually possible ...

4 Answers
0
Accepted Answer

OK, I figured out Step 6: I don't have to "switch back", I need two Route53 clients, one with the original credentials to update my subdomain, and a second one to update the parent domain, configured with the credentials returned from the assumeRole() call.

BTW there was an AWS bug I had to work around in Step 4. Following https://github.com/aws/aws-sdk-js-v3/issues/3940 I changed my code that returns a service client for Route53 in the parent account like this:

async getParentRoute53Client()
 {   
        try {
            let roleArn = `arn:aws:iam::<parent_acc_id>:role/<role_id>`;
            
            let response = await this.#stsClient.send(new AssumeRoleCommand({
                                        RoleArn: roleArn,
                                        RoleSessionName: '<some_sessionname>',
                                        DurationSeconds: 900
                                }));

            // can't use the Credentials returned from the response directly as there's a bug: https://github.com/aws/aws-sdk-js-v3/issues/3940

            let credentials = {
                    accessKeyId: response.Credentials.AccessKeyId,
                    secretAccessKey: response.Credentials.SecretAccessKey,
                    sessionToken: response.Credentials.SessionToken
            };
            let parentRoute53Client = new route53Client({ region: this.getRegion(), credentials: credentials });
            return parentRoute53Client;
        }
        catch (e){
            throw e;
        }
    }

I can then use the

parentRoute53Client

to make changes in the parent domain.

And breathe :D:D

answered a year ago
0

Hello.

Wouldn't it be a good idea to allow the IAM user to switch roles to an account in the parent domain?
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_permissions-to-switch.html

If you have multiple accounts, it may be a good idea to use AWS Organizations to manage users with IAM Identity Center.
https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html

profile picture
EXPERT
answered a year ago
  • This sounds like what I thought I might do - thanks for the links. I'm using Organizations exactly as you suggest, so I think my answer might be to use DNS sub-domains as the previous answer suggested, then an IAM role to update the parent domain with the sub-domain NS as you've suggested here.

    Thanks!

    David

0

If possible I'd really appreciate a bit of help with this ... I've been reading so many docs I've gotten myself properly confused :) It almost makes sense, then it slips away again, and though I've tried many combinations I haven't worked out the correct combination of users/roles/permissions/policies.

To recap, I now have Account A which holds the parent zone records for example.com, and I want to programatically create subdomain acme.example.com in Account B.

Both accounts are in the same Organization if that's relevant - I think I should just use IAM for the users rather than IIC but I'm not 100% sure. From a different question it seems I should use one or the other, not both and as this use-case is for non-human users I've gone with IAM.

My nodejs program needs to do the following:

  1. Start as the "Account B" IAM user "builder";
  2. Create a public hosted zone for acme.example.com in "Account B" Route53
  3. Retrieve the NS record from Route53 for the new hosted domain
  4. Assume a role that allows it to create an NS record for the subdomain in the "Account A" Route 53
  5. Create the NS record in the "Account A" Route 53
  6. Revert to its original role
  7. Create more stuff in "Account B"

Steps 1-3 are all working fine and I know how to do Steps 5 and 7+. But Steps 4 and 6 have me stumped ... I've followed the logic from the IAM user guide above but I'm clearly missing something.

answered a year ago
0

I thought I'd add an update in case it helps anyone in the same predicament in the future :)

I solved Step 4 by:

  • creating an IAM role with AmazonRoute53DomainsFullAccess permission in Account A, using the Account ID for Account B to set up the trusted entity
  • creating an IAM user in Account B (without access to the AWS Console)
  • putting the security credentials for the Account B user in a shared credentials file so that Steps 1-3 of my program run as this user.

Once Step 3 is complete, I stsClient.assumeRole() using the Arn for the IAM role Account A to complete Step 4.

This lets me complete Step 5.

Now I need to figure out Step 6 :)

answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions