Support for IRSA for AWS Provider

[scottd018]

As per https://github.com/openshift/external-dns-operator/blob/main/api/v1beta1/externaldns_types.go#L260 IRSA is not currently supported. This should allow a consumer of the external-dns to pass in a Role ARN and have the service account annotated as follows for an AWS provider:

metadata:
  annotations:
    eks.amazonaws.com/role-arn: "arn:aws:iam::<ACCOUNT>:role/<ROLE>"

[scottd018]

See #191 for a proposed change to support this feature

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[andyrepton]

This is something that I also have a customer requesting. Can this be reviewed please?

Thanks!

[alebedev87]

@Seth-Karlo , @scottd018 : sorry for the late reply. I'm interested in exploring specific customer cases that require this change. As far as I understand, IRSA only functions with EKS, so please correct me if I'm mistaken. Additionally, since kiam is currently in maintenance mode, it would be challenging to depend on it in the API provided by the operator. However, I'm uncertain about kube2iam.
Having a customer using OpenShift who requires this feature would help to move this request forward. However we will need to go through the RFE process regardless.

[alebedev87]

/remove-lifecycle rotten

[scottd018]

@Seth-Karlo , @scottd018 : sorry for the late reply. I'm interested in exploring specific customer cases that require this change. As far as I understand, IRSA only functions with EKS, so please correct me if I'm mistaken. Additionally, since kiam is currently in maintenance mode, it would be challenging to depend on it in the API provided by the operator. However, I'm uncertain about kube2iam. Having a customer using OpenShift who requires this feature would help to move this request forward. However we will need to go through the RFE process regardless.

@alebedev87 Traditionally, you are correct in that IRSA is an EKS construct. However, ROSA (Red Hat OpenShift Service on AWS) also employs the IRSA standard and uses the same webhook that EKS uses in order to provide pod-authentication to AWS services via STS. Most customers like the idea of using ROSA in STS mode so that they do not have to use hard-coded access/secret keys, so this would be useful for customers using ROSA in STS mode (today, most customers use STS rather than non-STS).

Understood on the kiam/kube2iam front. I decided to put that in there because it was a simple change and lots of folks on raw Kubernetes use it (my background is raw Kube, so still learning OpenShift specifics). I could definitely see leaving that off, but IRSA would be extremely useful for ROSA customers.

[alebedev87]

@scottd018: do you think that externaldns's aws-assume-role flag would do the same job? Maybe even a little more generic way as it doesn't expect any third party deployments (kiam/kube2iam) and can work on ROSA, standalone OpenShift or even any other Kubernetes cluster.

[scottd018]

@alebedev87 That's a great find! I've used external-dns a lot (even contributed to it) and did not even realize that existed. I would anticipate that would pretty easily work and should satisfy all use cases.

[scottd018]

@alebedev87 That's a great find! I've used external-dns a lot (even contributed to it) and did not even realize that existed. I would anticipate that would pretty easily work and should satisfy all use cases.