[Feature]: Add support of custom authenticators for jaeger cassandra storage about jaeger HOT 12 CLOSED

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).

from jaeger.

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

from jaeger.

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

from jaeger.

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.

from jaeger.

@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

from jaeger.

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

from jaeger.

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.

from jaeger.

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

from jaeger.

@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.

from jaeger.

@yurishkuro yes

from jaeger.

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!

from jaeger.

@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.

from jaeger.