[Feature]: Add support of custom authenticators for jaeger cassandra storage

[quantumlexa]

Requirement

as a Jaeger power user I want to use cassandra that uses custom authenticator as a storage for jaeger traces

Problem

Jarger uses BasicAuthenticator from config with no AllowedAuthenticators set. That makes gocql to use default set of Authenticators.

https://github.com/jaegertracing/jaeger/blob/main/pkg/cassandra/config/config.go#L144-L149
As the result all cassandra instances that uses custom Authenticators can't be used as a storage for jaeger traces
Here by custom authenticators I mean not included in the following list: https://github.com/gocql/gocql/blob/master/conn.go#L26-L39

Proposal

Add ability to set authenticator by an user.

Open questions

No response

[yurishkuro]

What does it mean to allow those custom authenticators from the list you mention? If it's just an option we need to pass to gocql driver, then it's reasonable to support. If it requires integrating with another dependency, then it gives me a pause. E.g. we intentionally stayed away from integrating with AWS AIM because it requires taking dependency on their custom SDKs (and increases the binary size like crazy, although that ship may have sailed now since OTEL collector wasn't as diligent).

[quantumlexa]

What does it mean to allow those custom authenticators from the list you mention? If it's just an option we need to pass to gocql driver, then it's reasonable to support.

Yes, that is exactly what I want in this issue: just to pass another option to gocql driver

[ayushrakesh]

Hey @quantumlexa I want to work on this issue. Please assign to me.

[yurishkuro]

As the result all cassandra instances that uses custom Authenticators can't be used as a storage for jaeger traces
Here by custom authenticators I mean the following list: https://github.com/gocql/gocql/blob/master/conn.go#L26-L39

@quantumlexa why do you refer to these as "custom"? I think it's creating confusion, we have two PRs going about this ticket in completely different directions: #5628 and #5637. When I hear "custom" I think more of the approach in #5637 where we implement an authenticator API. Whereas #5628 simply adds a CLI flag to pass on of those "approved" authenticators from the list. The documentation in gocql is lacking on this front.

[hellspawn679]

@quantumlexa why do you refer to these as "custom"? I think it's creating confusion, we have two PRs going about this ticket in completely different directions: #5628 and #5637. When I hear "custom" I think more of the approach in #5637 where we implement an authenticator API. Whereas #5628 simply adds a CLI flag to pass on of those "approved" authenticators from the list. The documentation in gocql is lacking on this front.

@yurishkuro I think the use of passing "approved" authenticators let's say you are using instacluster cassendra db so now they have there own custom auth for that so to connect to that you can either specify the auth you are allowing

cluster.Authenticator = gocql.PasswordAuthenticator{Username: "Username", Password: "Password", AllowedAuthenticators: []string {"com.instaclustr.cassandra.auth.InstaclustrPasswordAuthenticator"}}

it would still work if you don't pass any allowed auth

cluster.Authenticator = gocql.PasswordAuthenticator{Username: "Username", Password: "Password"}

as you can see the func approve
https://github.com/gocql/gocql/blob/master/conn.go#L26-L52
if no allowed auth is passed it will try all the defaultApprovedAuthenticators one by one in most case it will use the default auth
org.apache.cassandra.auth.PasswordAuthenticator
but when you are using cassendra in scylladb(discussed in this issue) or some cloud provider AWS(Helenus Authenticator), instacluster which have there own auth you can specify the exact auth you want to use for that it would be fine even if you don't pass the allowed auth

[quantumlexa]

As the result all cassandra instances that uses custom Authenticators can't be used as a storage for jaeger traces
Here by custom authenticators I mean the following list: https://github.com/gocql/gocql/blob/master/conn.go#L26-L39

@quantumlexa why do you refer to these as "custom"? I think it's creating confusion, we have two PRs going about this ticket in completely different directions: #5628 and #5637. When I hear "custom" I think more of the approach in #5637 where we implement an authenticator API. Whereas #5628 simply adds a CLI flag to pass on of those "approved" authenticators from the list. The documentation in gocql is lacking on this front.

@yurishkuro I'm sorry for such a badly formatted issue description.
By custom authenticators I mean not included in the following list: https://github.com/gocql/gocql/blob/master/conn.go#L26-L39

Looking at #5628 it seems that it should solve this issue

[yurishkuro]

By custom authenticators I mean not included in the following list: <>
Looking at #5628 it seems that it should solve this issue

are you sure? According to #5627 (comment), the default list is used regardless of whether we specify them or not. Even if that conclusion is wrong, the PR does nothing to enable authenticators that are NOT on the list.

[hellspawn679]

By custom authenticators I mean not included in the following list: <>
Looking at #5628 it seems that it should solve this issue

are you sure? According to #5627 (comment), the default list is used regardless of whether we specify them or not. Even if that conclusion is wrong, the PR does nothing to enable authenticators that are NOT on the list.

no if you specify the default list won't be used it will only try among the provided auth
https://github.com/gocql/gocql/blob/master/conn.go#L43-L43

[yurishkuro]

@hellspawn679 our current code leaves this field empty, which causes the default list to be used https://github.com/gocql/gocql/blob/34fdeebefcbf183ed7f916f931aa0586fdaa1b40/conn.go#L44

So if someone wants to use one of these approved authenticators, no changes is needed in Jaeger. Only if someone wants to prohibit using the full list would we need a user-configurable option to allow user to provide the exact list, OR to provide some name that is not even on the list. I think your PR is still on point, but given the utter lack of documentation in gocql about that I want to (a) understand it myself and (b) write adequate CLI flag description that is unambiguous.

[hellspawn679]

@yurishkuro yes

[quantumlexa]

are you sure? According to #5627 (comment), the default list is used regardless of whether we specify them or not. Even if that conclusion is wrong, the PR does nothing to enable authenticators that are NOT on the list.

@yurishkuro
yes, I just doublechecked the implementation of #5628 and all further comments in this PR, that looks good to me.
Thanks!

[ayushrakesh]

@yurishkuro @quantumlexa, I understood the problem it in a wrong way, I have read the whole description above why I am wrong. By the way thanks for it. Looking forward to contribute more.