Proposal for supporting connections.max.reauth.ms configuration for SCRAM listeners

[tinaselenge]

Related to: strimzi/strimzi-kafka-operator#5639

[scholzj]

Thanks for the proposal ... I think that in general this would work fine.

But I wonder if we should consider some alternatives before we decide to add some new API field for this ...

• Should we let users to configure this cluster-wide in .spec.kafka.config? Are there usecases where it should be configured on a per-listener basis?
• Should we find a way how to allow users configure per-listener options in .spec.kafka.config? (Right now, we can make it configurable at the cluster level, but not with the per-listener prefixes)
• Users can probably use the custom authentication for this. Isn't that sufficient? Given Kafka has this disabled and does not seem to see this as an important option, maybe it is niche thing among Strimzi users as well?

Might be worth adding these at least to the alternatives for everyone's consideration.

It is also worth noting that strimzi/strimzi-kafka-operator#11764 suggests considering deprecating the Oauth authentication exactly because it became just a huge pile of various options. While this proposal does not do this for SCRAM-SHA, it is a reason to consider if we want to handle these options through new API fields or not.

[tinaselenge]

Thanks @scholzj for the feedback.

Should we let users to configure this cluster-wide in .spec.kafka.config? Are there usecases where it should be configured on a per-listener basis?

Actually users can already configure this cluster-wide in .spec.kafka.config. So perhaps the proposal should be "support this configuration at listener level" as currently it seems to suggest that we don't support this config at all.

Should we find a way how to allow users configure per-listener options in .spec.kafka.config? (Right now, we can make it configurable at the cluster level, but not with the per-listener prefixes)

Can we maybe add this config to the exception list, to allow something like listener.<>.connections.max.reauth.ms?

Users can probably use the custom authentication for this. Isn't that sufficient? Given Kafka has this disabled and does not seem to see this as an important option, maybe it is niche thing among Strimzi users as well?

I suppose that could be sufficient but I wonder if user wants to enable this config for their existing listener, would they want to reconfigure their entire listener to make it custom type? I think it could still be useful for adding this configuration for their specific listener.

It is also worth noting that strimzi/strimzi-kafka-operator#11764 suggests considering deprecating the Oauth authentication exactly because it became just a huge pile of various options. While this proposal does not do this for SCRAM-SHA, it is a reason to consider if we want to handle these options through new API fields or not.

Given that we decided to deprecate OAuth authentication type for the reason of having too many options to handle, maybe proposing maxSecondsWithoutReauthentication field does not make sense anymore.

[scholzj]

Can we maybe add this config to the exception list, to allow something like listener.<>.connections.max.reauth.ms?

Yeah, something like this. But we right now don't have any support for the <> part. So that would need to be figured out. The obvious choice might be some form of regular expression. But that might be pretty expensive doing it again and again on large amount of configuration options.

Given that we decided to deprecate OAuth authentication type for the reason of having too many options to handle, maybe proposing maxSecondsWithoutReauthentication field does not make sense anymore.

I think it should be taken into consideration. But at the same time, this is a single option. So the question also is how many other options like this are waiting to be requested by someone. The OAuth also did not looked that bad early on. But got worse as users needed it to work with this and that etc.

---

TBH, I have thrown here all these alternative approaches. But I'm not really sure that any single one of them is somehow the obvious winner for me.

[PaulRMellor]

The configuration seems useful, but there might still be a question mark over the agreed approach, especially with the potential for using type: custom for authentication configuration (as will happen with OAuth). I’ve left a few comments as I read through.

[PaulRMellor]

Suggested change

	# Support `connections.max.reauth.ms` configuration for SCRAM listeners
	# Add support for `connections.max.reauth.ms` configuration for SCRAM listeners

[PaulRMellor]

Do we want a summary to lead into the proposal?

Something like:

This proposal adds support for configuring the Kafka connections.max.reauth.ms parameter at the listener level for SCRAM authentication in Strimzi.

[tinaselenge]

So the question also is how many other options like this are waiting to be requested by someone. The OAuth also did not looked that bad early on. But got worse as users needed it to work with this and that etc.

I don't see that many per listener configurations, especially for SCRAM so it might not end up as bad as oauth.
(Other per listener configurations: max.connection.creation.rate, max.connections)