Prometheus Scaler Add custom headers and custom auth support

[prashant-shahi]

Checklist

• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added
• Changelog has been updated and is aligned with our changelog requirements
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Relates to #4206

Relates to kedacore/keda-docs#1064

[JorTurFer]

Thanks for the contribution! Looking good but I have one question:
Will these headers contain sensitive data? I mean, in the examples you have used "token". If these headers contain sensitive data, they should be read from TriggerAuthentication instead of metadata. We should avoid sensitive data as part of trigger metadata.
From the code pov, you should look for them config.AuthParams instead of config.TriggerMetadata (or maybe from both, joining them if there are headers from both places)

[prashant-shahi]

@JorTurFer yes, that makes sense for custom authentication header.

I have included changes related to the same and updated linked documentation PR as well.

[JorTurFer]

LGTM! Thanks for the improvement :)
wdyt @zroubalik ?

[JorTurFer]

/run-e2e prometheus*
Update: You can check the progress here

[zroubalik]

Generally looking good, what will happen if user specify both cortexOrgID option and a custom header where he specify X-Scope-OrgID header for Cortex but with a different value. Which one will be used and valid?

[prashant-shahi]

Generally looking good, what will happen if user specify both cortexOrgID option and a custom header where he specify X-Scope-OrgID header for Cortex but with a different value. Which one will be used and valid?

@zroubalik Currently, the value from custom header will be used over cortexOrgID, when both are specified. However, I do not think one would be more valid than the other when both are passed.

Ideally, cortexOrgID can be depreciated after this PR, since the same can be fulfilled using custom headers.
We can mention in documentation to pass cortexOrgID using X-Scope-OrgID custom header.
But yeah, it can co-exist along with custom headers if breaking changes are not desired for now.

[prashant-shahi]

@zroubalik @tomkerkhove Do let me know if there are any changes required for making the PR good to merge.

[zroubalik]

@prashant-shahi the PR is looking good, I agree that we should deprecate the cortex parameter. Could you please add log message here if this parameter is specified, that custom headers should be used instead?

[zroubalik]

@prashant-shahi please also add note to Deprecated section in Changelog about this change.

[prashant-shahi]

@zroubalik cortexOrgID parameter has been deprecated and relevant files are updated.

[zroubalik]

LGTM, great job @prashant-shahi !

@tomkerkhove is there anything else needed to be done wrt deprecation? Could you please double check? 🙇‍♂️

[zroubalik]

/run-e2e prometheus*
Update: You can check the progress here

[prashant-shahi]

@zroubalik Thank you! :)

I have also included checks for duplicate keys in custom headers as well as given higher precedence to authentication headers in case of collision with custom header.

[zroubalik]

/run-e2e prometheus*
Update: You can check the progress here

[tomkerkhove]

LGTM, great job @prashant-shahi !

@tomkerkhove is there anything else needed to be done wrt deprecation? Could you please double check? 🙇‍♂️

We're not there yet, we need to:

• Create GH discussion
• Create issue
• Document it with clear timelines

But we can do that after merging.

https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md#introducing-new-deprecations

I also noticed doc entry is not in our policy today so I have opened kedacore/governance#95

[prashant-shahi]

I also noticed doc entry is not in our policy today so I have opened kedacore/governance#95

That's great! I was not sure about format for deprecation, so I went along with what I had in mind.

[tomkerkhove]

No worries!