Skip to content
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

Closed
wants to merge 73 commits into from
Closed

Add support for LDAP authentication #145

wants to merge 73 commits into from

Conversation

sbernauer
Copy link
Member

@sbernauer sbernauer commented Mar 9, 2022

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 tests

Review Checklist

  • Code contains useful comments
  • (Integration-)Test cases added (or not applicable)
  • Documentation added (or not applicable)
  • Changelog updated (or not applicable)
  • Cargo.toml only contains references to git tags (not specific commits or branches)
  • Helm chart can be installed and deployed operator works (or not applicable)

Once the review is done, comment bors r+ (or bors merge) to merge. Further information

@sbernauer sbernauer changed the title Draft: Support LDAP authentication Draft: Overall concept of LDAP authentication Mar 9, 2022
@sbernauer sbernauer requested a review from siegfriedweber March 9, 2022 11:37
@sbernauer sbernauer changed the title Draft: Overall concept of LDAP authentication Overall concept of LDAP authentication Mar 10, 2022
@sbernauer sbernauer marked this pull request as draft March 10, 2022 10:21
@siegfriedweber siegfriedweber requested review from a team and removed request for siegfriedweber March 11, 2022 14:04
rust/crd/src/authentication.rs Outdated Show resolved Hide resolved
rust/crd/src/authentication.rs Outdated Show resolved Hide resolved
// 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
Copy link
Member

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!?

Copy link
Member Author

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

Copy link
Member

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.

Copy link
Member Author

@sbernauer sbernauer Mar 21, 2022

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)

Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should be fine.

Copy link
Member Author

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

rust/operator-binary/src/config.rs Outdated Show resolved Hide resolved
rust/operator-binary/src/superset_controller.rs Outdated Show resolved Hide resolved
rust/operator-binary/src/superset_controller.rs Outdated Show resolved Hide resolved
rust/operator-binary/src/superset_controller.rs Outdated Show resolved Hide resolved
) -> Result<ConfigMap> {
let mut cm_conf_data = BTreeMap::new(); // filename -> filecontent

for property_name_kind in rolegroup_config.keys() {
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member Author

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

rust/operator-binary/src/superset_controller.rs Outdated Show resolved Hide resolved
@sbernauer
Copy link
Member Author

Thanks for your review @teozkr!
Only open issue is to create a release of the commons-operator so that we can reference a fixed tag version.
I will work on that but requires some time (we decided to move the common structs into operator-rs - see Architecture meeting notes)

@sbernauer
Copy link
Member Author

@teozkr I added the needed common structures to operator-rs 0.16 and upgraded to it.
So everything should be finally done™

examples/superset-with-ldap.yaml Outdated Show resolved Hide resolved
rust/crd/src/lib.rs Outdated Show resolved Hide resolved
rust/crd/src/lib.rs Outdated Show resolved Hide resolved
rust/crd/src/lib.rs Outdated Show resolved Hide resolved
rust/crd/src/lib.rs Outdated Show resolved Hide resolved
rust/operator-binary/src/config.rs Outdated Show resolved Hide resolved
rust/operator-binary/src/main.rs Show resolved Hide resolved
rust/operator-binary/src/superset_controller.rs Outdated Show resolved Hide resolved
rust/operator-binary/src/superset_controller.rs Outdated Show resolved Hide resolved
@sbernauer
Copy link
Member Author

Thanks again for another round of feedback, it should be addressed by now.
integration-tests run successfully.

@sbernauer
Copy link
Member Author

Thanks for approving @teozkr!
As we already merged the new config validation mechanism by @siegfriedweber in #173 i need to adopt the implementation to use the new approach.
I created #180 for this, i will request review when it is ready to be reviewed. The actual implementation should not change, only using the new validation mechanism.

@sbernauer
Copy link
Member Author

Closed in favor of #180

@sbernauer sbernauer closed this Apr 22, 2022
bors bot pushed a commit that referenced this pull request May 13, 2022
## 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
@sbernauer sbernauer deleted the feat/ldapAuthN branch April 27, 2023 11:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants