Bug 1759812

Hi,

To be specific, this is a request to identify nodes via TLS (X.509) public key certificates as an alternative to the current private shared key (PSK) method. I see two broad approaches:

1. Create self-signed certificates for each node, and install all the public certificates on all nodes. A node will approve connections when any of the certificates is used. This is the simplest approach but doesn't scale well.

2. Create a Certificate Authority (CA) and certificates signed by that CA for each node. Each node needs just its own certificate and the CA certificate. Ideally each node would also have a Certificate Revocation List (CRL) to be able to reject CA-signed certificates that have been revoked. This approach has two further possibilities for authentication. A node could approve connections using any certificate signed by the CA (effectively organization-wide trust, unless a separate CA is set up for each cluster), or each node could have a list of subject Distinguished Names (DNs) that are allowed to connect (fine-grained trust). I don't think there's a need for Pacemaker to support the local system's trusted CAs since we're identifying nodes and not users or public servers.

With either approach, there's the question of certificate and key storage. The simplest method is in unencrypted files. If we allow the private key files to be encrypted, that will make Pacemaker block on start for human passphrase input, and prevent automated recovery from daemon crashes. An alternative would be to store an unencrypted key on an encrypted disk, which would require human passphrase input at boot time -- daemon crash recovery would still be possible, and it wouldn't require any special handling on pacemaker's side. Since pacemaker uses the GnuTLS library, we should automatically get support for PKCS#11 (hardware crypto tokens and software key rings) as an alternative to files, so I think we can skip the encrypted file option.

Keep in mind, too, that certificates typically have an expiration date, and if the user forgets to update the certificate before then, Pacemaker Remote connections would suddenly stop working.

Any thoughts on what customer requirements and preferences would be regarding the design questions?

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.