-
Notifications
You must be signed in to change notification settings - Fork 17
Credentials Overview
- TLS Certificate / Private Key (CA)
- TLS Certificate / Private Key (RabbitMQ server)
- TLS Certificate / Private Key (Nginx server)
- TLS Certificates / Private Keys (RabbitMQ client credentials per-node)
- SSH public / private keys (Reverse tunnel credentials per-node)
Out of these, the following are absolutely critical.
The CA's private key absolutely must be kept secure and both the certificate and private key must be backed up!
Since we're managing our own self-signed CAs - a particular CA private key is the root of the entire trust and authentication infrastructure for certificates it's used to sign.
The CA's certificate, on the other hand, is public knowledge. This could be (should be?) preloaded on the nodes, on Github, etc to ensure it's already available for verification.
Beehive must have a backup of the authorized SSH public keys each node will offer. Strictly speaking, Beehive does not need the node private keys. For example, the key pair could be generated on a node at build time and registering it would copy the public key to beehive.
Nodes must have their public and private keys. If we're concerned about data corruption of individual files on the node, we could consider keeping a replicated copy of these like:
waggle_key1
waggle_key1.pub
waggle_key2
waggle_key2.pub
...
waggle_keyn
waggle_keyn.pub
which are just duplicates of the same key and have SSH try each one. I'm not convinced that's required though.
A new RabbitMQ server certificate can be generated and signed by the CA whenever we want.
A new Nginx server certificate can be generated and signed by the CA whenever we want.
Client certificates / privates keys must be on the right "node" in intending to use them. ("Node" could mean an actual node, a test publisher machine, etc.)
Client credentials do not need to be on Beehive. All Beehive requires is the CA's certificate to verify that a client certificate was signed. (It's ok if they are, but they aren't used for authentication and I'd suggest getting the design right so that RabbitMQ client credentials can be rotated relatively easy instead of storing them and putting old ones back on the node over and over again.)
Note that the CN (Common Name) field must match the RabbitMQ username that a client is attempting to authenticate with.
One suggestion has been doing away with these altogether and just using a strong random token as a RabbitMQ password. Since RabbitMQ client certificates are generated much more often that server certificates, this may be simpler to manage and understand by anyone not familiar with the details of TLS / SSL. (Those still must be managed, but I don't think it's controversial to say a password is easier to understand than a PKI system.)
In that case, managing TLS / SSL would be a much less frequent activity and limited to just the server side, hence easier to control and automate.
Currently the config file the CA uses defaults to using a SHA1 hash for signing. I don't have a good sense of how much that puts us at risk, but the SHA1 is being deprecated, so the adhere to best practice, we should move to SHA256 and regenerate our certificates.