clients in go sdk and the cli should both have options for using custom CA

[krancour]

No description provided.

[vdice]

I may pull this in. Am I understanding the feature request right?

Add support in the Go SDK (which the cli uses, but of course the cli would get the necessary plumbing command(s) and/or flag(s)) for specifying a custom CA. The custom CA (root cert and private key?) would live on the server and then each client (cli/Go SDK) would need the same custom CA and the public key? (Or just one or the other)? I'm slightly rusty on the usual client/server setup here.

I take it the SSL assets for the server would be injected via the Helm chart. What do we envision the CLI support (command/flag(s)) looking like?

[krancour]

I'm second-guessing the extent to which this is needed. Let me get back to you on the great questions above.

[krancour]

@vdice after thinking about this more, I do still think we should do it.

My rationale is that if the default setup involves SSL and auto-generated certs to secure communication between components, that default setup can be improved slightly by using a CA instead of using the option to ignore cert issues. But this focuses on communication between internal components and not so much on the CLI.

As far as the CLI is concerned...

I have a feeling people will end up just using the -k option, but we should probably still add a flag for specifying a CA just to cover our bases...

That adds a new dimension to our configuration we store in "brig home" and it's making me start to wonder if we shouldn't make that brig config file a little more sophisticated-- more like the k8s config file-- with capacity to remember different contexts and allow the user to switch between them.

[vdice]

Ok, I'll check this out. I'm hesitant to tackle an overhaul of the brig config file for this feature, at least with regards to making it more like a kubeconfig file w/ contexts and such, but I'd be down to take notes and brainstorm on what that might look like for us as I add in the add'l config from this story (CA cert and/or public key?) Then we can collaborate on creating the feature request/issue around the updated config approach. How does that sound?

[krancour]

I'm hesitant to tackle an overhaul of the brig config file for this feature

We agreed in an offline conversation that this is actually out of scope.

Noting that here so that we don't lose track of that decision.