Cross-account Route 53 access using IAM Identity Center permissions

0

I'm trying to make changes to a Route 53 hosted zone in one account (Account A), from a different AWS account (yep – Account B). The two accounts are enrolled in the same Organisation. We use IAM Identity Center to sign in (so not vanilla IAM).

I have edited the permission set for the Identity Center user, with an inline policy to allow access to the Route 53 hosted zone:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "route53:GetHostedZone",
                "route53:ChangeResourceRecordSets",
                "route53:ListResourceRecordSets"
            ],
            "Resource": [
                "arn:aws:route53:::hostedzone/<zoneid>"
            ]
        }
    ]
}

However, I keep getting permission denied errors:

% aws route53 get-hosted-zone --profile staging --id <zoneid>

An error occurred (AccessDenied) when calling the GetHostedZone operation: User: arn:aws:sts::<account-b>:assumed-role/AWSReservedSSO_AdministratorAccess_<etc>/<identity-center-user> is not authorized to access this resource

I've checked the user is correct with aws sts get-caller-identity --profile staging.

The same request from my Identity Center user signed in to Account A (aws route53 get-hosted-zone --profile develop --id <zoneid>) works as it normally would, with a description of the zone.

As a sanity-check I also made a role in Account A to allow a trust relationship with the Identity Center user, and group, and account root, but still get the same error.

… which makes me wonder if there are some Route 53 wrinkles that make x-account access a bit trickier. AWS seems to think it should be doable though!

Will appreciate any guidance, thank you.

1 Answer
0

I don't see in the documentation where it says that you can do what you're trying to do.

To clarify:

  • You have a Route 53 zone created in account A.
  • You want a user in account B to manage the zone in account A.

The way to do this is:

  • Create a role in account A that has the required permissions.
  • Give permission to the role in account B to assume the role in account A.
  • When authenticated as the role in account B (which it appears you are); assume the role in account A.
  • Use the new credentials to perform the Route 53 actions in account A.

The documentation you've linked to does mention this in the section that starts with Attach a permissions policy to a role (grant cross-account permissions).

profile pictureAWS
EXPERT
answered a year ago
profile pictureAWS
EXPERT
kentrad
reviewed a year ago
  • Thanks Brettski-AWS … makes sense and this is how I've done it in the past for a normal IAM user.

    I'm clearly missing something, but the reason I went this way is that I don't see anyway to associate a role with an IAM Identity Center user. That's why I was trying to set up the permissions using an inline policy on the Permission Set.

    You had this bullet point:

    When authenticated as the role in account B (which it appears you are); assume the role in account A.

    I'm authenticated as an Identity Centre user, belonging to the admins group, which through AWS Accounts has permissions for the Administrator Access permission set. I can apply policies to the permission set, but not roles.

    Again, I'm clearly missing something – you may be able to enlighten me.

  • Oh, it's probably relevant to mention that I am trying to this as part of updating a Cloudformation template. So I can't completely switch roles.

    • I update the stack with an updated version of the Cloudformation template
    • The stack is modified within the current AWS account, Account B
    • Some changes require changes to DNS, which is hosted in Account A
    • So I want the current user, running a Cloudformation template in Account B, to be able to modify DNS settings in a zone in Account A.
  • Ok - so because you're trying to do this as part of CloudFormation, the answer is to use a custom resource although it might be possible with a StackSet. Personally, I think a custom resource is better because you're trying to update DNS which is usually something that requires a little more logic.

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