-
Notifications
You must be signed in to change notification settings - Fork 434
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
Darix/client cert support #14183
base: master
Are you sure you want to change the base?
Darix/client cert support #14183
Conversation
dd87a87
to
85b5881
Compare
JFYI: The reason to go the client certificate route and not SSL + Auth is because socket passing is not implemented for some parts of the backend. |
Just some general architecturla thoughts:
|
@@ -22,13 +24,52 @@ class Connection | |||
end | |||
end | |||
|
|||
def self.ssl_options() | |||
unless @@ssl_options |
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.
It'll probably be better to do this in an initializer once and store this in a class accessor. So this is per rails process (which we have many of) instead of per instantiated class (we do this often just for one call).
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.
as i said ... I am not sure what the best place is :)
but we also need to implement a clean way to reload the cert without restarting the app (ideally)
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.
but we also need to implement a clean way to reload the cert without restarting the app (ideally)
What for?
ssl_options[:cert] = OpenSSL::X509::Certificate.new(cert_data) | ||
|
||
# if you concatenate key and cert into one file you do not need to pass in source_client_key | ||
# and we can reuse the cert_data here. |
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.
Or we can just settle and document for one of those options...
the haproxy is only a workaround until we find a solution for the file descriptor passing problem in the backend.
the certs arent distro specific. a config option would be a good idea for those paths of course. and you can roll out certs with many different tools. |
I understood "the problem" is that this is just not implemented? Why do we workaround this with code and ha-proxy setup etc. instead of doing this then? :) I mean if we are going to throw this away and go with SSL + auth to talk to the backend in the future. We should make up our mind... |
|
This is not meant as a final implementation. all those TODOs need solving. This is just a rough untested sketch to see how one might be able to do this.
the basic idea is to talk to the back end via TLS and use client certificate for authentication.