-
Notifications
You must be signed in to change notification settings - Fork 56
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
feat: DSPO handle db tls connections and configs #575
feat: DSPO handle db tls connections and configs #575
Conversation
Signed-off-by: Humair Khan <HumairAK@users.noreply.github.com>
Signed-off-by: Humair Khan <HumairAK@users.noreply.github.com>
Signed-off-by: Humair Khan <HumairAK@users.noreply.github.com>
Signed-off-by: Humair Khan <HumairAK@users.noreply.github.com>
Signed-off-by: Humair Khan <HumairAK@users.noreply.github.com>
This change allows the DSPO to perform heatlh checks against a tls secured database. If the database is behind a self-signed cert, end user can provide a ca-bundle either as a global cert (configmap named "odh-trust-bundle" or via the ".caBundle" config option via the DSPA. This change also exposes the "ExtraParams" field for DSP, meaning users can now add ny DSN parameters when configuring a DB connection for DSP. These params are utilized in the same manner by the DSPO when conducting the health check to keep the behavior consistent. Signed-off-by: Humair Khan <HumairAK@users.noreply.github.com>
703f618
to
32d3e01
Compare
Change to PR detected. A new PR build was completed. |
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 was able to test and verify the first two test cases but not the last one with the new field "customExtraParams".
Confirm setting "customExtraParams" in the DSPA's ".spec.database.customExtraParams". Provide wrong ca bundle, confirm it fails to deploy dspa, then set ".spec.database.customExtraParams" to {"tls":"true"}, it should work.
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.
Tested the customExtraParams
after Humair's suggestion about the format. It works as expected.
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 have some thoughts and nitpicks ... all of which we can deal with in a follow up
/lgtm
@@ -1,6 +1,6 @@ | |||
apiVersion: kustomize.config.k8s.io/v1beta1 | |||
kind: Kustomization | |||
namespace: odh-applications | |||
namespace: opendatahub |
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.
nitpick, not related, should extract
.../bases/datasciencepipelinesapplications.opendatahub.io_datasciencepipelinesapplications.yaml
Outdated
Show resolved
Hide resolved
// Watch for global ca bundle, if one is added to this namespace | ||
// we need to reconcile on all the dspa's in this namespace | ||
// so they may mount this cert in the appropriate containers | ||
Watches(&source.Kind{Type: &corev1.ConfigMap{}}, |
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.
watching ConfigMap gobbles up memory doesn't it? Do we need to check for that and mitigate, possibly by increasing limits and or requests?
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.
We added a similar watcher for a pod, and didn't notice a major uptick (a lot of this is internally cached and heavily optimized in k8s I believe), and pod events work queue is likely to be insanely longer than the configmap events
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.
buut if it does cause issues, we will probably catch it in our perf testing and adjust accordingly
@@ -149,6 +151,9 @@ func (p *DSPAParams) SetupDBParams(ctx context.Context, dsp *dspa.DataSciencePip | |||
p.DBConnection.Port = dsp.Spec.Database.ExternalDB.Port | |||
p.DBConnection.Username = dsp.Spec.Database.ExternalDB.Username | |||
p.DBConnection.DBName = dsp.Spec.Database.ExternalDB.DBName | |||
// Assume default external connection is tls enabled | |||
// user can override this via CustomExtraParams field | |||
p.DBConnection.ExtraParams = fmt.Sprintf(config.DBDefaultExtraParams, true) |
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.
The extra params should be a struct that gets serialized to json when it needs to be. I guess it needs to by dynamic though, because you don't want to chase the mysql API. Hmm. Sprintf'ing the 'true' or 'false' specifically for tls feels weird when the field is named "DBDefaultExtraParams" and not "tlsEnabled". Not sure what the solution is but wanted to call out that it feels weird to me.
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 actually did it that way at first, i.e. Extraparams was of type map[string]string
but in our configmap template we need to render it as a string, the thing is we need to pass it in as a string anyways to render it in our go template configmap, I was torn on it, this method resulted in a lot less lines of code so I did it this way instead
log.Info(fmt.Sprintf("Encountered error when attempting to fetch ConfigMap: [%s], Error: %v", globalCABundleCFGMapKey, err)) | ||
return err | ||
} else { | ||
// Found a global cert, consume this cert, takes precedence over "cABundle" provided via DSPA |
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.
local usually overrides global ... pinged you in slack about it
Signed-off-by: Humair Khan <HumairAK@users.noreply.github.com>
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: amadhusu, gregsheremeta The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Change to PR detected. A new PR build was completed. |
The issue resolved by this Pull Request:
Resolves for v1.6:
Description of your changes:
This change allows the DSPO to perform health checks against a tls
secured database. If the database is behind a self-signed cert, end user
can provide a ca-bundle either as a global cert (configmap named
"odh-trust-bundle" or via the ".caBundle" config option via the DSPA.
This change also exposes the "ExtraParams" field for DSP, meaning users
can now add ny DSN parameters when configuring a DB connection for DSP.
These params are utilized in the same manner by the DSPO when conducting
the health check to keep the behavior consistent.
NOTE that before external connections made a connection via tls:false, now it's enforced by default. To disable it, users will need to set customExtraParams to:
{"tls":"true"}
string.Testing instructions
Deploy a secure/tls enabled s3/mariadb behind a self-signed cert (for example in a self-signed ocp cluster), provide these configs to the DSAP as external configs. Ensure they only accept tls based connections.
Deploy a cabundle as a configmap in the DSPA namespace:
Deploy DSPA configured to leverage these connections via external db/object store connections.
Confirm DSPO is able conduct successfull health checks (if it deploys the DSPA pods then health checks worked), if it didn't, log the error here.
Confirm DSPA comes up successfully, in this change DSPO willl udpate the DSP server's configs to enable "tls" for db connections. Confirm this behavior by running a successful pipeline.
Confirm DSPA "simple" v1 still works (no external db/s3 configured).
Confirm setting "customExtraParams" in the DSPA's ".spec.database.customExtraParams". Provide wrong ca bundle, confirm it fails to deploy dspa, then set ".spec.database.customExtraParams" to
{"tls":"true"}
, it should work. Because the value is a json string, you should use|
or>-
to format the yaml value, example:Checklist