Skip to content
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

WIP: Add support for authentication via TLS certs to remote CIB operations #3738

Draft
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

clumens
Copy link
Contributor

@clumens clumens commented Nov 26, 2024

The issue to be solved is adding TLS certs to Pacemaker Remote operations. However, remote CIB operations are a more standalone area so it's easier to develop and test that out first. What I've tested out on this:

  • If certs are enabled on both ends, authentication without certs is not allowed.
  • If certs are enabled on the server and some of the environment variables are missing on the client, access is denied.
  • If certs are disabled on the server but the client tries to authenticate using a cert, access is denied (this could be a bug, or it could be user error).
  • If certs are disabled on the server, authentication proceeds as it always has.

What remains to be done:

  • Improve error reporting on the client side
  • Document the procedure for making your own CA, certs, and keys
  • Test certificate revocation lists
  • Test if each end gets a certificate but it's not signed
  • Figure out if we should restrict access to only certain distinguished names - this doesn't seem that important to me since we are already restricting access to those clients that have a signed certificate.
  • Figure out PKCS#11 support
  • Warn/log when a certificate is close to the expiration date
  • Should we allow storing certs encrypted?
  • daemons/based/based_remote.c doesn't appear to clean up any gnutls stuff on exit
  • Can we deprecate remote CIB operations without a cert?

The only actual code change here is moving setting the server/user/pass
variables down until just before they're needed.
Move all the function calls out from inside if blocks where they're
hiding, test for error afterwards, and jump to the done label if there
was an error.  This is just to make the flow of what's actually
happening easier to follow.
Note that the gnutls docs mention that larger logging levels (like 10
that we are using here) can potentially reveal sensitive information.
However, what we are doing here should be okay because it would require
the administrator to enable pacemaker logging at the debugging level and
if that's happening, they are probably trying to debug a problem that
could be helped by the increased gnutls logging.
This function just checks whether all the environment variables needed
to support x509 encryption are set or not.  Typically, they'll be set in
the sysconfig file.
No other changes for the moment - just allow taking this type and print
it out in the error message.
This just handles everything that needs to be done during initial setup,
before a remote connects and performs the handshake.  Log error messages
if they occur - there's plenty of opportunities for things to fail here.

Ref T365
...from the client.  Because we can only require an older version of
gnutls, we have to manually set up a verification callback function.
Once we can require a later version (see the patch), we can get rid of
most of this code and have gnutls automatically verify the cert.

Ref T365
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant