I saw a reference to that PKI package in the linked article, but it doesn't really answer the question.

A newly brought up server can generate its own private key and issue a key signing request to a certificate authority, but how does the CA server authenticate the request? You still need a shared secret (perhaps implicitly through the username / password of an administrator doing things manually).

Any way you cut it, I don't see how you avoid this problem outlined in the article: "Common practices include putting secrets in config files next to code or copying files to servers out-of-band. The former is likely to be leaked and the latter difficult to track."

I do take the point made by some of the sibling comments that this allows for better mitigation of the damage in the case of the loss of the bootstrap shared secret, and I can certainly see the value in that.

Perhaps similar to how new versions of puppet let you provide custom attributes (like a pre-shared key) as part of the request so you can do verification on your issuer and build the secret into your boot strap process. A key compromise would simply require a rotation on your issuer and your boot strap process.

You can solve this by having a bootstrapping process that issues the appropriate credentials when bringing up a new server.

And how do you trust the identity of the new server/instance during boot strapping?

You could leverage the TPM and some version of remote attestation and only permit key-requests from attested machines. Alternatively (or concurrently), you could PXE boot all devices with a parameterized shared-secret individualized for each node.

I'm getting the feeling they don't like something about etcd or raft or both. Is that accurate? I noticed certstrap was adapted from etcd-ca.