-
Notifications
You must be signed in to change notification settings - Fork 246
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
clients in go sdk and the cli should both have options for using custom CA #1210
Comments
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? |
I'm second-guessing the extent to which this is needed. Let me get back to you on the great questions above. |
@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 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. |
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? |
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. |
No description provided.
The text was updated successfully, but these errors were encountered: