Add TLS support for Pacemaker Remote connections #3759
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For Pacemaker Remote connections, both ends are daemons and will therefore read the TLS environment variables out of the sysconfig file. However, one end is a client and one end is a server. So using that to decide where to read the variables is not helpful. Instead, just try both locations regardless of which end of the connection we're checking. If the PCMK_ version of a variable isn't set, try the CIB_ version instead.
This fixes a double free that can happen in the Pacemaker Remote code paths but that didn't turn up in the remote CIB testing.
If the right environment variables are set in the sysconfig file, enable TLS certificates on the server side of a Pacemaker Remote node connection. This works exactly like the remote CIB operation support did, except here the remote node is the server and the cluster is the client. Name your certs appropriately. Ref T365
If the right environment variables are set in the sysconfig file, enable TLS certificates on the client (cluster) side of a Pacemaker Remote node connection. Because we have both sync and async versions of everything, this has to be done in two different places. Fix T365
kgaillot
reviewed
Dec 10, 2024
Move the authorization key settings below the X509 settings to de-emphasize them, and mention the preference for using X509 certificates in the comment block.
If we're not setting up a TLS connection that uses anon credentials, don't add the anon priority. Similarly, only add the PSK priorities if we're setting up a TLS connection that uses PSK credentials.
kgaillot
approved these changes
Dec 10, 2024
|
I think the testing has been sufficient enough to backport this to 3.0 |
kgaillot
reviewed
Dec 18, 2024
| - The location of a file containing trusted Certificate Authorities, used to | ||
| verify client or server certificates. This file must be in PEM format and | ||
| must be readable by Pacemaker daemons (that is, it must allow read permissions | ||
| to either the |CRM_DAEMON_USER| user or the |CRM_DAEMON_GROUP| group). |
There was a problem hiding this comment.
Is this correct? The controller and executor both run as root, and I don't think any other daemons need access
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tested:
I did not explicitly test expirations or CRLs, but it's the exact same code as on the remote CIB connections and both worked there so I have no reason to think they wouldn't work here.