Add support for GSSAPI in Kafka scaler

[novicr]

Added Kerberos authentication to Kafka scaler. TriggerAuthentication can now accept additional parameters that will be passed to Sarama to authenticate scaler via Kerberos.

Checklist

• [N/A] When introducing a new scaler, I agree with the scaling governance policy
• 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
• [N/A] A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #4836

Relates to PR: kedacore/keda-docs#1201

[github-actions]

Thank you for your contribution! 🙏 We will review your PR as soon as possible.

🏖️ Over the summer, the response time will be longer than usual due to maintainers taking time off so please bear with us.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Learn more about:

• Our contribution guide

[JorTurFer]

Nice contribution!
Can we cover this new feature with an e2e tests somehow?

[novicr]

My changes only consider the kafka scaler (based on sarama). The change is to collect relevant information in TriggerAuthentication and pass it along to sarama. Not sure about the e2e test - would require standing up kerberos infra as part of the test. I'd rather trust that sarama will do the right thing with inputs (it does). Unit tests ensure that correct values are passed along.

[JorTurFer]

Is there any way to add an e2e tests which tests this?

[sansmoraxz]

FYI As far as I see as of yet strimzi doesn't have support for kerberos: strimzi/strimzi-kafka-operator#3088

[zroubalik]

Also, how do we deal with the token refreshment? I am not Kerberors expert at all, though I think that it needs to be refreshed after some period of time.

[novicr]

Also, how do we deal with the token refreshment? I am not Kerberors expert at all, though I think that it needs to be refreshed after some period of time.

Sarama takes care of it. We just provide the path to key tab

[novicr]

I moved temp kerberos files into dedicated directory, just in case someone already mounts /tmp into their container. Don't think we are likely to run into any conflicts with /tmp/kerberos, especially since kerberos isn't supported by keda yet

[sansmoraxz]

Once this merges, I will take a dig with kafka-go

[novicr]

What are next steps on this? There were couple small commits after approval. Need someone to approve again. Also, how do we make sure this goes hand in hand with docs and charts PR's?

[sansmoraxz]

E2E tests run by one of the core maintainers. Ignore my above approval, that was a misclick.

[sansmoraxz]

They are still on vacation. So progress is slow.

[JorTurFer]

What are next steps on this? There were couple small commits after approval. Need someone to approve again. Also, how do we make sure this goes hand in hand with docs and charts PR's?

We check that all the PRs are ready to merge before merging it on any repo. It's a manual action that we do before merging.
I guess that during next days we will address all the reviews that we have because we have slowed the speed during summer vacations (personally, I had more than 100 notifications waiting review in GH xD)

[zroubalik]

I am still not sure we should add another mount point. If the file needs to be stored, can't we use some in-memory go filesystem implementation?

[novicr]

I am still not sure we should add another mount point. If the file needs to be stored, can't we use some in-memory go filesystem implementation?

Not sure what you mean, but open to any suggestions. I can spin up in-mem fs in the code and create a file in there, but I don't see any way to pass that file to sarama. Sarama accepts a parameter that if a file system path to the required files (kyetab and krb5.conf). Any files created in my in-memory filesystem will not be visible to sarama.

[zroubalik]

I am still not sure we should add another mount point. If the file needs to be stored, can't we use some in-memory go filesystem implementation?

Not sure what you mean, but open to any suggestions. I can spin up in-mem fs in the code and create a file in there, but I don't see any way to pass that file to sarama. Sarama accepts a parameter that if a file system path to the required files (kyetab and krb5.conf). Any files created in my in-memory filesystem will not be visible to sarama.

Right.

@sansmoraxz how does kafka-go client deal with kerberos auth? Does it need a file in a filesystem as well?

[sansmoraxz]

Strictly speaking it's not something that's there in the official repo. Well there was a PR but not much progress was made.

The sasl interface should be loose enough to implement without issues. Have to look more in dept.

[zroubalik]

@novicr Hi, the PR is looking good. The only concern is the new volume mount to host Kerberos files.

We talked about the issue on our community call today and the suggestion is:

• don't make this feature default (the volume mount part in config/manager.yaml
• in the documentation add a section with an explanation, that if users want to use GSSAPI in Kafka scaler, they need to update the deployment with the volume mount (a code snippet that can be copy pasted is the way to go)
• the scaler code should reflect this and print an error message in case kerberos files are not available with a suggestion on adding a mount
• the existing Helm Chart supports adding arbitrary volume mounts, so it should be good from this side, CC @JorTurFer to confirm

Thanks!

FYI we plan to do a release on Wednesday

[JorTurFer]

• the existing Helm Chart supports adding arbitrary volume mounts, so it should be good from this side, CC @JorTurFer to confirm

yep!
https://github.com/kedacore/charts/blob/274c330fa559e594d2eab1e897b581de6bc23e6d/keda/values.yaml#L475-L492

[novicr]

Removed kerberos mount from config/manager.yaml
Added instructions to keda-docs to add dedicated mount when turning on kerberos auth (both via manager.yaml and charts). Not sure my description in the docs is sufficient, please provide suggestions there.

When /tmp is not writable and no writable /tmp/kerberos is provided, error message now has instructions to follow documentation.

[zroubalik]

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

[zroubalik]

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

[zroubalik]

LGTM, thanks for the contribution!