-
Notifications
You must be signed in to change notification settings - Fork 283
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
certificate checking for clusterd #4628
certificate checking for clusterd #4628
Conversation
54803df
to
782eb93
Compare
@@ -1008,8 +1008,6 @@ functor | |||
debug "Pool.enable_tls_verification sleeping on fistpoint" ; | |||
Thread.delay 5.0 | |||
done ; | |||
Db.Cluster.get_all ~__context | |||
|> List.iter (Xapi_cluster_helpers.Pem.maybe_write_new ~__context) ; | |||
all_hosts | |||
|> List.iter (fun host -> | |||
do_op_on ~local_fn ~__context ~host (fun session_id rpc -> |
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.
Since you loop over all hosts then this should be Client.Host.enable_tls_verification, not Client.Pool.enable_tls_verification (unrelated to clusterd changes, perhaps fix it in a separate commit).
If it was really a pool level operation then it should've taken a pool as an argument and do the looping internally (but you'd still need a host-level API to 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.
This code pings all hosts in a pool before enabling TLS verification on the local host. These functions are not available on the host level - so moving the code is not trivial.
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 like this easier to reason about than the previous attempt, as well as the solution to certificate generation
fbe11d3
to
5a7056a
Compare
Certificate checking for clusterd is implemented by relying on the certificates xapi uses for intra-pool communication. This implies that only hosts part of a xapi pool can form a cluster. Each host in the pool has a certficate (public and private key) and knows the public keys of all hosts in the pool. These are kept in PEM bundles. We remove code from a previous design where clusterd used a single certificate generated by xapi which was passed to clusterd. A tls_config, sent to clusterd, contains the essential information: * The common name (CN) * Path the server certificate * Optional path to bundle with trusted certificate or None if clusterd should not perform certficate checking. The tls_config is global per cluster and hence the CN has to be a global value and can't be specific per host. For now, use a simple string to avoid confusion. Signed-off-by: Christian Lindig <christian.lindig@citrix.com>
Signed-off-by: Christian Lindig <christian.lindig@citrix.com>
Signed-off-by: Christian Lindig <christian.lindig@citrix.com>
Certificates for xapi's API clients and internal pool communication are generated by gencert.service, which invokes gencert for this. The certificate for the API clients requires the IP of the management interface (obtained by gencert), which might not be yet available and causes this to fail. The certificate for the pool communication does not suffer from this dependency. So generate it first to have it available. If the second call then fails, the systemd will run it again. But gencert is idempotent such that the already created certificate for pool communication won't be overwritten. Signed-off-by: Christian Lindig <christian.lindig@citrix.com>
Signed-off-by: Christian Lindig <christian.lindig@citrix.com>
5a7056a
to
de6ee60
Compare
Just to collect some comments - changes in xapi to enable certificate checking in clusterd. Clusterd uses the certificates used also by xapi.
The protocol/IDL between xapi/clusterd and clusterd/clusterd changes to include a TLS configuration which holds the paths to the files containing the certificates. This simplifies the previous design which involved using single certificate for the cluster.