skip to Main Content

Allowing access to specific hosted zones with Route 53 and IAM

  • By , Director of Engineering, Culture Foundry

How can you allow a trusted third party to access a subset of your Route 53 hosted zones?

DNS is fundamental to the internet and to the website and web applications that Culture Foundry builds. We prefer to use Route 53 for our DNS solution, though it isn’t perfect (I wish there was a better way to do a redirect). I recently have been in multiple situations where I was either dependent on someone else to make DNS changes or someone was dependent on me. (Not all of these situations involved our Route53 setup, but some did.) Changes, which had to happen on a tight timeframe, typically involved scheduling a phone call between multiple parties. If there was some debugging or propagation time involved, there were multiple phone calls. In some cases granting access to modify DNS records would have solved issues more quickly.

If you want to allow a third party temporary access to some of your hosted zones in Route 53, follow these steps.

  • Create a group.
  • Create a user, add them to that group. Record the username/password for this user. This is what you are going to share with the third party.
  • Find the IDs of the hosted zone. The easiest way to do this is to go to the hosted zone in the console and look for the string at the end of the URL: https://console.aws.amazon.com/route53/home?#resource-record-sets:Z29APBN11MP5JB . In this case, Z29APBN11MP5JB is the hosted zone ID.
  • Attach the below policy to the group. This policy allows unfettered access to two and only two hosted zones.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"route53:GetHostedZone",
"route53:ListResourceRecordSets",
"route53:ListHostedZones",
"route53:ChangeResourceRecordSets",
"route53:ListResourceRecordSets",
"route53:GetHostedZoneCount",
"route53:ListHostedZonesByName"
],
"Resource": "arn:aws:route53:::hostedzone/<id>"
},
{
"Effect": "Allow",
"Action": [
"route53:GetHostedZone",
"route53:ListResourceRecordSets",
"route53:ListHostedZones",
"route53:ChangeResourceRecordSets",
"route53:ListResourceRecordSets",
"route53:GetHostedZoneCount",
"route53:ListHostedZonesByName"
],
"Resource": "arn:aws:route53:::hostedzone/<id2>"
}
]
}
  • Share the username and password and link with the third party. They won’t have permission to list hosted zones using this policy, so you will want to provide them with each hosted zone URL.
  • After they are done making their changes, revoke access. How much to revoke depends on how often you think the third party access will need to make changes. You could leave the user around, you could leave the group around, or you could remove the user and the group. If this is a one time migration, remove everything. If the third party needs to debug a few more times, leave them access for a known period of time or remove the user from the group and have them request access each time. If it is a long term consulting contract, leave the IAM user in the group.

Note that the above policy lets them do anything they want to the hosted zone. Anything!

This includes changing existing DNS records. So don’t hand this to any third party, only one you trust. I was unable to find a Route 53 IAM permission granular enough to allow only adding record sets. If that is your desire, this post has some suggestions, but I haven’t tried them. Another alternative would be to build an API wrapper scripte which examines the action of the ChangeRecordSets API call and disallows certain actions.

Letting someone else have access to your DNS is giving them a lot of authority. But there may be times when it makes sense. Using IAM and Route 53, we can limit access to one or more hosted zones.

Back To Top