Support for IRSA for AWS Provider about external-dns-operator HOT 18 CLOSED

See #191 for a proposed change to support this feature

from external-dns-operator.

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

from external-dns-operator.

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

from external-dns-operator.

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

Thanks!

from external-dns-operator.

@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.

from external-dns-operator.

/remove-lifecycle rotten

from external-dns-operator.

@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.

from external-dns-operator.

@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.

from external-dns-operator.

@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.

from external-dns-operator.

@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.

from external-dns-operator.

@scottd018: then you can follow up on Grant's PR which had a different requirement (SharedVPC support) but will achieve it using --aws-assume-role flag.

from external-dns-operator.

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

from external-dns-operator.

/remove-lifecycle stale

from external-dns-operator.

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

from external-dns-operator.

@scottd018 : the assume role feature was shipped. However after looking closer at your request I doubt this will be enough for the IRSA support. The service account token is still not mounted to the operand's pod and the CredentialsRequest CR created for the operand doesn't have the IAM role. All this is a part of the STS support which was never requested for the ExternalDNS Operator. We will need a dedicated RFE for the STS support. Would you mind creating a feature request for OpenShift NetworkEdge team?

from external-dns-operator.

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

from external-dns-operator.