Currently, to use password authentication, you must be communicating with the Presto coordinator over HTTPS.
From the docs about using a pluggable password authenticator (https://prestosql.io/docs/current/develop/password-authenticator.html):
Additionally, the coordinator must be configured to use password authentication and have HTTPS enabled.
I see a block in AuthenticationFilter here which enforces this requirement: https://github.com/prestosql/presto/blob/57051c9a9616eee4f8713f58b84c07a8041767cb/presto-main/src/main/java/io/prestosql/server/security/AuthenticationFilter.java#L67-L71
I'd like to use password authentication with a cluster where Presto nodes all live behind a load balancer. I'm running Presto in a Kubernetes cluster; worker nodes cannot be accessed from outside the cluster, and the coordinator can only be accessed via Ingress (https://kubernetes.io/docs/concepts/services-networking/ingress/#tls), a Kubernetes object analogous to a load balancer. Ingress can be configured to force HTTPS, so effectively all traffic going to Presto is over HTTPS, even if the coordinator itself is only serving HTTP traffic.
Would the community be open to allowing password authentication to work over HTTP? We could put this behavior behind a flag, and disable it by default to make it less likely for someone to run Presto in an insecure setup with basic authentication over HTTP.
This sounds reasonable. Maybe we should enforce that the X-Forwarded-Proto or the Forwarded header says the original request is HTTPS?
That sounds like a better approach than what I suggested. I can open a PR sometime next week.
I think we should do both: only allow if a config is enabled (default disabled) and if the forwarded header says the original request was secure.
Initial PR (work in progress): https://github.com/prestosql/presto/pull/1442
Most helpful comment
I think we should do both: only allow if a config is enabled (default disabled) and if the forwarded header says the original request was secure.