Update AWS documentation

[otterley]

Using EC2 Instance Roles to provide Route 53 permissions is overly
permissive and dangerous. Emphasize using alternatives such
as EKS IAM Roles for Service Accounts, kiam, or kube2iam that
limit access to the ExternalDNS pod.

[k8s-ci-robot]

Welcome @otterley!

It looks like this is your first PR to kubernetes-sigs/external-dns 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/external-dns has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[Raffo]

Hi @otterley , thanks for your PR.
I don't think that the changes that you proposed would be right for our user base. We have many users that use ExternalDNS on AWS by running kops or other tools and not using EKS. Given that this project is a community project not affiliated with any cloud provider, I would love to keep our AWS tutorial as generic as possible.
For that reason, I'd ask you to change what your proposed to instead list the options that are available (i.e. have the node have the "right" permissions, use one between kube2iam, kiam, etc.) or use whatever EKS provides. I would also not mark the EKS option as "recommended" as it is really only recommended if you are running on EKS 😄

[Raffo]

It's great to use the right terminology, thanks!

[otterley]

Hey @Raffo, thanks for the feedback.

I created this PR after my experience using ExternalDNS for the first time and saw the existing documentation that suggested we apply the IAM Policy to all nodes in the cluster. This is really bad advice -- we need to change that ASAP to tell users to apply the Policy only to the Pod running ExternalDNS.

I went with the IRSA approach because that's the approach I know, and it's the one AWS officially recommends and supports.

I can try to change the verbiage a bit, but I have never used any alternatives to IAM Roles for Service Accounts such as kube2iam. So I wouldn't be able to provide documentation regarding other approaches with the same level of confidence.

Keep in mind, too, that the scope of the PR is limited to the AWS tutorial, so we're not doing anything like recommending AWS over other cloud providers -- but I admit a bias that customers use EKS for their control plane than trying to manage K8S clusters themselves. :)

[otterley]

@Raffo I've taken another stab at the PR to make it more neutral-sounding and offer some alternative options, while emphasizing the danger of granting the trust relationship to the entire node. WDYT?

[Raffo]

I created this PR after my experience using ExternalDNS for the first time and saw the existing documentation that suggested we apply the IAM Policy to all nodes in the cluster. This is really bad advice -- we need to change that ASAP to tell users to apply the Policy only to the Pod running ExternalDNS.

Yes, I understand the security implications of the issue, it's worth noting that the risks still depend on what gets deployed to the cluster and the isolation of the AWS account. That said, it's true that it is generally bad advice.

I've taken another stab at the PR to make it more neutral-sounding and offer some alternative options, while emphasizing the danger of granting the trust relationship to the entire node. WDYT?

The changes look much better from my point of view and I'm happy with how they look like now.

[Raffo]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: otterley, Raffo

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Raffo]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment