Admin endpoint security

The admin endpoint today is unsecured (no authentication or TLS), with the assumption that it is only available to localhost or accessible on a trusted network. Ideally:

• We want to be able to restrict access to only trusted IPs, client certificates and ensure we have transport security.
• We want to have some ability to distinguish roles and access to the admin console, i.e. distinct identities might be allowed to operate /quitquitquit vs. stats monitoring.

Beyond just security, there's also the question of what the admin console is. Is it just a curlable utility, an interactive web console or is it a first-class API intended for programatic use? Should it offer gRPC endpoints (in particular as we are moving towards a proto definition of its contents in places such as https://github.com/envoyproxy/envoy/issues/2172). Answers to this affect the framing of security considerations.

Opening this issue to start the design discussion here.