Bug 1759812
| Summary: | [RFE] Implement certificate based authentication for pacemaker_remote | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Andreas Karis <akaris> |
| Component: | pacemaker | Assignee: | Ken Gaillot <kgaillot> |
| Status: | NEW --- | QA Contact: | cluster-qe <cluster-qe> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 8.0 | CC: | cluster-maint |
| Target Milestone: | rc | Keywords: | FutureFeature, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Feature Request | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Andreas Karis
2019-10-09 07:54:01 UTC
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? |