[
https://issues.apache.org/jira/browse/CASSSIDECAR-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Burman updated CASSSIDECAR-407:
---------------------------------------
Description:
In the current implementation, the only way for a driver to read the
username/password combination required for CQL connection is to set them in the
configuration file. This does not work well in environments where such
information is stored in external systems, be it Kubernetes Secrets, Vaults or
any similar projects.
Most of them do support mounting the secrets to a filesystem however and this
provides a method to access them with approved methods. To make this change
more generic, the driver_parameters should accept auth_provider with a
class_name like the other configuration parts which have this type of ability.
I'm assuming in the future we might want to expose also driver's
withAuthProvider instead of only withCredentials, but this would make the
change far more complex (and risky) and might be better implemented in a future
ticket if the need arises. Sort of like the class_names are all required to be
in the sidecar at the moment instead of using ClassLoader to verify anything in
the classpath with the correct interface/annotations.
To maintain backwards compatibility, if the old parameters are used and new
ones are not set, we should still support them.
was:
In the current implementation, the only way for a driver to read the
username/password combination required for CQL connection is to set them in the
configuration file. This does not work well in environments where such
information is stored in external systems, be it Kubernetes Secrets, Vaults or
any similar projects.
Most of them do support mounting the secrets to a filesystem however and this
provides a method to access them with approved methods. To make this change
more generic, the driver_parameters should accept auth_provider with a
class_name like the other configuration parts which have this type of ability.
I'm assuming in the future we might want to expose also driver's
withAuthProvider instead of only withCredentials, but this would make the
change far more complex (and risky) and might be better implemented in a future
ticket if the need arises. Sort of like the class_names are all required to be
in the sidecar at the moment instead of using ClassLoader to verify anything in
the classpath with the correct interface/annotations.
> Ability to load Cassandra connection secrets from filesystem
> ------------------------------------------------------------
>
> Key: CASSSIDECAR-407
> URL: https://issues.apache.org/jira/browse/CASSSIDECAR-407
> Project: Sidecar for Apache Cassandra
> Issue Type: Improvement
> Components: Configuration
> Reporter: Michael Burman
> Assignee: Michael Burman
> Priority: Major
>
> In the current implementation, the only way for a driver to read the
> username/password combination required for CQL connection is to set them in
> the configuration file. This does not work well in environments where such
> information is stored in external systems, be it Kubernetes Secrets, Vaults
> or any similar projects.
> Most of them do support mounting the secrets to a filesystem however and this
> provides a method to access them with approved methods. To make this change
> more generic, the driver_parameters should accept auth_provider with a
> class_name like the other configuration parts which have this type of ability.
> I'm assuming in the future we might want to expose also driver's
> withAuthProvider instead of only withCredentials, but this would make the
> change far more complex (and risky) and might be better implemented in a
> future ticket if the need arises. Sort of like the class_names are all
> required to be in the sidecar at the moment instead of using ClassLoader to
> verify anything in the classpath with the correct interface/annotations.
> To maintain backwards compatibility, if the old parameters are used and new
> ones are not set, we should still support them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
