area/adminarea/securityhelp wantedtech debt
Métriques du dépôt
- Stars
- (27 997 stars)
- Métriques de merge PR
- (Merge moyen 8j) (378 PRs mergées en 30 j)
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
/quitquitquitvs. 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.