Admin endpoint security
- Dominant language
- C++
- Stars
- 28.9k
- Forks
- 5.6k
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 430
Description
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 `curl`able 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.
Contributor guide
Assessment
This issue has not been assessed yet.