AWS: Skip hosted zones, if GetHostedZones returns AccessDenied

[totallyunknown]

I'll have the problem, that I have private and public route53 zones. If the IAM policy has restrictions to specific zones, external-dns will fail. This PR tries to make a GetHostedZone-Call in Zones() and exclude all Zones where we don't have access.

This will fix #230.

[totallyunknown]

Any feedback on this? Next I'll update the doc and the Changelog.

[linki]

Thanks @totallyunknown

Some remarks

• This creates a lot of API requests (n+1)
• I was wondering if there's a better way to know if we have access to a hosted zone
• We could fetch the list of zones less often

[ideahitme]

Thanks for the PR. The approach is aligned with #230, but now looking at it seems this approach does not suit everyone needs:

1. It creates additional n (number of hosted zones) requests per each synchronisation loop. Knowing the strict limit for AWS API requests this will create potential problems for people with many hosted zones (100s of them) where no synchronisation will ever succeed
2. It makes user to use IAM policies as a way to regulate the behaviour of External DNS. In my mind IAM policies are not the best way to achieve this for multiple reasons:
   a. Not all DNS providers can be configured this way
   b. IAM policies can be updated at any moment without External DNS knowing it - hence more ways for the system operation to be not traceable and more flaky.

[ideahitme]

@totallyunknown as mentioned in the comment above we will have certain issues with AWS rate limiting. We were thinking of tagging hosted zones to select hosted zones to manage. What are your thoughts on that, or if you think you want to try that approach instead?

[totallyunknown]

Thanks for the feedback. I had already the same thoughts about the API request volume. In the longer run it might useful, to have a prometheus metric exposed, counting the API requests for AWS.

We could implement some kind of internal caching for GetHostedZones, to avoid unnecessary API calls.

With the current behaviour external-dns is broken, if any of the domain names is restricted by a IAM policy. So we need this check somehow anyway?

#322 might solve our problem, but leaves the problem above with the permissions.

I think we should introduce a new flag for filtering zones, who external-dns might be responsible for.

I would like to introduce zone filter (--zone-filter). The zone filter is for filtering by zone ID or zone zone exact name.

Example:

Hosted Zone ID: ABCDEFGHIJK
Host Zone Name: example.com

Ingress/Service Hostname: foobar.team-a.example.com

With --zone-filter ABCDEFGHIJK or --zone-filter example.com we allow crud operations of alle records in this hosted zone. --domain-filter team-a.example.com will tell external-dns, that we only want to update records in this subdomain.

[linki]

@totallyunknown Would a filter for private/public hosted zones work for you? If yes, you can give #329 a try.

[sstarcher]

@totallyunknown metrics for http requests are already implemented http_request_duration_seconds_count

I currently alert when we get enough failures from aws
max(increase(http_request_duration_seconds_count{component="external-dns",status=~"4.*"}[1h])) BY (host, path) > 10

I use the above as I currently hit limits with to many instances of external-dns running on multiple clusters

[linki]

@totallyunknown @ideahitme One year anniversary for this PR 😞

What's the current opinion about this? Did any change of mind happen since last year?

[njuettner]

IT seems the PR is stale. I'll close it. Feel free to create a new one.