Refine Control Plane Auth

[danehans]

A single EG<>Envoy control plane existed. #208 added TLS for the control plane by generating CA, EG, and Envoy certs. with the addition of #404, the number of Envoy's is no longer static. As an interim solution, #404 creates a wildcard certificate *.envoy-gateway. A more secure solution should be developed that supports multiple Envoy's. One possible solution is that each deployed Envoy includes the certgen Job. Certgen would need to expose the ability to configure the SAN DNS names of the generated cert. Each managed Envoy would mount the cert and would also need to get the CA cert generated by EG.

[youngnick]

I'm not sure if I agree that having a separate cert per Envoy deployment is desirable - the TLS between control plane and data plane is really only for two things:

• to ensure that secrets are not interceptible on the wire
• to ensure that only EG managed Envoys connect to EG.

As long as users outside the EG namespace can't get to a shared keypair, then I think we can meet those requirements. And if untrusted users can provision things into the EG namespace, we've already lost the game.

[danehans]

Closing due to ^ feedback.