Is our new authentication backwards compatible?

[tomkerkhove]

While working on the docs we were not sure if the new authentication is backwards compatible (and thus supports configuration on ScaledObject) or not?

From what I'm seeing I'd say it is.

Either outcomes are fine but would just be good to know so we can align the docs.

/cc @jeffhollan

[zach-dunton-sf]

When adding TriggerAuth support for AWS Cloudwatch, I was asked to remove the scaled object configuration #397 (comment)

I have done the same for AWS SQS Scaler. I can add them back if necessary.

[zach-dunton-sf]

I found this today, there is now an official pod identity provider for AWS https://github.com/aws/amazon-eks-pod-identity-webhook it's a mutating webhook that injects the AWS_ROLE_ARN into the pod based on an annotation from the Service Account of the pod. Maybe we should consider re-adding pulling at least AWS_ROLE_ARN from the pod, possibly only if podIdentityProvider == "aws"

[tomkerkhove]

I've created #457 for that - Even if we keep the environment variables I think we should make it automagically for AWS customers.

My comment (#397 (comment)) was based on the assumption that we were killing backwards compatibility but @jeffhollan brought this up and I'm not longer sure if my assumption is correct - If this is the case, I'm sorry for asking you to remove it @zach-dunton-sf

I personally would not go there for sake of simplicity but I don't want to block this.

[zach-dunton-sf]

I have a PR ready for #457 that is pulling the annotation from the service account. I’m waiting on one of the other two to be merged first so I can rebase to that branch and push it.

…

On Thu 14. Nov 2019 at 12:22, Tom Kerkhove ***@***.***> wrote: I've created #457 <#457> for that - Even if we keep the environment variables I think we should make it automagically for AWS customers. My comment (#397 (comment) <#397 (comment)>) was based on the assumption that we were killing backwards compatibility but @jeffhollan <https://github.com/jeffhollan> brought this up and I'm not longer sure if my assumption is correct - If this is the case, I'm sorry for asking you to remove it @zach-dunton-sf <https://github.com/zach-dunton-sf> I personally would not go there for sake of simplicity but I don't want to block this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#453?email_source=notifications&email_token=AEH7ZDLZ6YGFZ6P4AL42JNLQTUYG5A5CNFSM4JNG4PJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEBQBFQ#issuecomment-553844886>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEH7ZDLU3NTCR3WMV5B2ZK3QTUYG5ANCNFSM4JNG4PJA> .

[jeffhollan]

Yes I think in general we’ve preserved the way to inline authentication to both preserve backwards compatibility and also to provide an easy way to create a scaled object with secrets. I don’t know if there’s a compelling reason to force trigger auth and somewhat like what other scalers have done to show you can do both

https://keda.sh/scalers/azure-service-bus/

Thanks @zach-dunton-sf thesr PRs are awesome

[tomkerkhove]

Sounds good to me, but then we'll have to do a sweep to ensure that all scalers use this approach!

[balchua]

Ive kept the environment variable auth for redis while TriggerAuthentication takes precedence.

[tomkerkhove]

I think we can close this, ok?

[zach-dunton-sf]

Yes. I believe so. Tom Kerkhove <notifications@github.com> schrieb am Mo. 9. März 2020 um 09:27:

…

I think we can close this, ok? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#453?email_source=notifications&email_token=AEH7ZDPHZ2CAWNBNRXKVIVLRGSR6DA5CNFSM4JNG4PJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOGDXFQ#issuecomment-596392854>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEH7ZDJYJFXBPXI4CHWZLETRGSR6DANCNFSM4JNG4PJA> .