On 27/03/19 14:30 -0400, Brian Reichert wrote:
> I'm putting together some tooling to automate provisioning a cluster.
>
> All examples I've seen so far call out using 'pcs auth' as a precursor
> step, but to use this pragmatically, I need to pass around the
> password in the clear.
(as an aside, there was a CVE assigned to the case this password
was hardcoded in some publicly available deployment scripts of
some SW leveraging the cluster stack, so your precaution is
legitimate)
> As I already have the means of using SSH identities of moving data
> across the hosts in question, is there perhaps some means of
> pre-populating /etc/corosync/authkey, and copying that around?
>
> I'm looking at the manpage for corosync-keygen(8), but it's not
> clear to me that I'm on the right path here...
If you intend to stick with pcs for managerial tasks around the
cluster, handling the corosync messaging in isolation wouldn't
win you anything. It works in the opposite direction, once you
have undertaken the authentication step for pcs peers network,
it can then be leveraged as a springboard also to get your initial
cluster (comprising also configuring the corosync layer for you,
authkey generation and distribution being part of it) set up.
Unfortunately, there's currently no supported (and long term
supportable) way to just share some files around (or have them
pregenerated in a dry run or something) so as to leverage existing
trusted infrastructure (e.g. SSH as in your case, although that
just shifts the problem around, you then need a secure way to
circulate the SSH keys, which is commonly also credential based...).
Blurry memories combined with hard data search, I've actually opened
this topic with the original pcs maintainer 5 years back, since the
experience of the time indicated that there's indeed an interest for
such security-seemless automated deployments as you appear to be asking
for (and for instance, Red Hat previously adopted HA solution even
allowed for that to some extent as a side-effect of its certificate
based approach[1]), but AFAIK, the actual pcs implementation
(respective durable/on-disk artefacts) should rather be deemed
a "dont't touch" thing.
Short term, the next best thing you can do is perhaps using something
like this (experiments needed):
SEND-PASSWORD-CMD \
| ssh root@node1 -c 'pcs host auth node1 node2 node3 -u hacluster'
where SEND-PASSWORD-CMD can be as simple as "echo PASSWORD" or
something as elaborate as "gpg -d encrypted.key" (point is that
the password will not be exposed in usually world-visible arguments
to the command at node1 (and not even on the originating machine
if "echo PASSWORD" is avoided).
Long term, perhaps best to follow up at the issue already raised
to that effect if something convenient can be devised:
https://github.com/ClusterLabs/pcs/issues/179
[1] for posterity only:
https://www.redhat.com/archives/linux-cluster/2013-January/msg00033.html
--
Hope this helps,
Jan (Poki)
pgpaG_zEo24tu.pgp
Description: PGP signature
___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home: https://www.clusterlabs.org/
