-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for LDAP authentication #145
Conversation
01c8961
to
6e43c27
Compare
937a535
to
98d0c33
Compare
rust/operator-binary/src/config.rs
Outdated
// We don't calculate the secrets here directly, as the operator should not be able to see the actual credentials. | ||
// Instead we add a env-var which gets it's value from the secret with the credentials and read that with Python. | ||
let common = r#" | ||
# common configs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Is it worth pulling this out into a file that we include_str!
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you take a look at the current config.rs it now has a lot more format strings and i think i would make it difficult to read if we pull all of them out into separate files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah.. those are all currently completely unescaped (https://github.com/stackabletech/superset-operator/pull/145/files/e54c1406da7ca2eb76db0f1558750c8d3e67d656#r826035108). I'd much rather stick them in through a secondary channel (either env vars or a JSON file we deploy next to the config.py perhaps?) and deploy the same config.py everywhere which then reads that secondary channel.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to establish like a "common pattern" of how to do that in all the products supporting LDAP.
And not all products support executing arbitrary code to collect the Env/Json i guess. Maybe we should do a proper validation/escaping in the AuthenticationClass so that we validate all properties in a single place and the operators can behave all the same way? (I'm afraid we need proper validation/escaping anyhow)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most product operators that don't support turing-complete configuration languages already use a common and well-defined configuration format where this isn't a problem anyway (JSON, XML, Java properties, whatever). This is just adapting Superset to follow the same convention.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm would be ok for me to put this into env vars and than read them with Python
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine for now because @siegfriedweber is working on an overhaul of the configuration for Superset and escaping Python-Strings and so on
) -> Result<ConfigMap> { | ||
let mut cm_conf_data = BTreeMap::new(); // filename -> filecontent | ||
|
||
for property_name_kind in rolegroup_config.keys() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any value in piping through the product-config machinery if we don't actually use it anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good question which came also to my mind. Maybe I'm doing it wrong but i haven't understand the benefit of the product-config machinery yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can ignore this for now as @siegfriedweber is working on an overhaul of the product machinery for Superset and we focus on getting the feature in at the moment
7c0c91c
to
b672bb8
Compare
Thanks for your review @teozkr! |
@teozkr I added the needed common structures to operator-rs 0.16 and upgraded to it. |
Co-authored-by: Teo Klestrup Röijezon <teo@nullable.se>
Co-authored-by: Teo Klestrup Röijezon <teo@nullable.se>
Co-authored-by: Teo Klestrup Röijezon <teo@nullable.se>
Co-authored-by: Teo Klestrup Röijezon <teo@nullable.se>
…erator into feat/ldapAuthN
Thanks again for another round of feedback, it should be addressed by now. |
Thanks for approving @teozkr! |
Closed in favor of #180 |
## Description Superseding #145, completely reworked to use new configuration mechanism introduced in #173 For #5 Integration-Tests: https://github.com/stackabletech/integration-tests/pull/175 Use `./create_test_cluster.py --kind --operator superset=0.4.0-pr180` before running the tests
Description
For #5
Integration-Tests: https://github.com/stackabletech/integration-tests/pull/175
Use
./create_test_cluster.py --kind --operator superset=0.4.0-pr145
before running the testsReview Checklist
Once the review is done, comment
bors r+
(orbors merge
) to merge. Further information