gRPC authentication

In our current RPC model we use client certificates issued from a single CA and RabbitMQ ACLs to make sure services can only talk to the right places.

Once we switch to gRPC we'll need to come up with a different authentication model since there is no central service that can enforce a big ACL. Since gRPC is implemented over HTTP(S) we can continue using client and server certificates issued from a specific non-web CA. In order to replicate the ACLs we can implement a configurable grpc.TransportAuthenticator which uses information from the provided client certificates and a per-server configuration file to decide whether to allow/disallow a connection.

The best two options so far seem to be for the server to check either:

• That the certificate CN/SAN matches a specific regex pattern
• That the certificate fingerprint matches the configured fingerprint for the remote host IP

The former allows spinning up new VMs without restarting Boulder services as it can match against only the non-unique portion of the hostname, but may allow for cross-talk across staging/production.

The latter would require a restart to add/remove hosts (unless a automatic configuration reloader was implemented) but would be more secure as it would directly associate a host with the specific certificate it should be using and wouldn't allow any kind of cross-talk.