7 ms·

https://github.com/square/certstrap https://github.com/square/certstrap

by kbar13 12y ago

bradleyjg 12y ago
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.
- cssx 12y ago
  You can solve this by having a bootstrapping process that issues the appropriate credentials when bringing up a new server.
  - donavanm 12y ago
    And how do you trust the identity of the new server/instance during boot strapping?
    - 0x44 12y ago
      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.
- brazzledazzle 12y ago
  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.
0xdeadbeefbabe 12y ago
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.

https://github.com/square/certstrap https://github.com/square/certstrap

by kbar13 12y ago

https://github.com/square/certstrap https://github.com/square/certstrap

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.

cssx 12y ago
You can solve this by having a bootstrapping process that issues the appropriate credentials when bringing up a new server.
- donavanm 12y ago
  And how do you trust the identity of the new server/instance during boot strapping?
  - 0x44 12y ago
    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.
brazzledazzle 12y ago
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.

0xdeadbeefbabe 12y ago

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.