Description of problem: Currently, pacemaker_remote uses PSK only for authentication (KCS 4484841). Consider implementing authentication based on certificates. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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?