etcd gateway to https endpoint

[jbuhacoff]

The gateway guide talks about how the purpose of the gateway is to centralize endpoint configuration on each system so that it's only updated in one place, instead of having to update every app.

But the gateway is only a simple TCP proxy and doesn't handle TLS connections. So when the remote etcd service is listening on https, the client (every local application using the gateway) must be configured to have the right CA certificate. When the remote server changes certificates, all local applications have to be updated. This seems to be an issue the gateway was supposed to solve.

The gateway even has a configuration setting --trusted-ca-file but it seems this only used when connecting to the remote etcd service for discovery.

This doesn't work because the server cert mentions 198.51.100.77 and not 127.0.0.1 so hostname verification fails:

etcd gateway start --listen-addr=127.0.0.1:2379 --endpoints=198.51.100.77:2379 --trusted-ca-file=/path/to/etcd.pem &
ETCDCTL_API=3 etcdctl  get --prefix / --endpoints=https://127.0.0.1:2379 --cacert=/path/to/etcd.pem

Disabling hostname verification "works" but is insecure:

ETCDCTL_API=3 etcdctl  get --prefix / --endpoints=https://127.0.0.1:2379  --insecure-transport=false --insecure-skip-tls-verify=true

For the gateway to be useful in my situation it would need to be configured with the CA cert and then offer
a non-TLS connection to local clients, so that I can just run this:

ETCDCTL_API=3 etcdctl  get --prefix /

This is what I was hoping the etcd gateway does when I got started.
However, because it doesn't do that, I used a wrapper script, moving the original etcdctl to etcdctl.v3:

#!/bin/bash
ETCDCTL_API=3 etcdctl.v3 --endpoints=https://198.51.100.77:2379 --cacert=/path/to/etcd.pem $*

Now the same command line works:

ETCDCTL_API=3 etcdctl  get --prefix /

So I'm just posting this because after reading the gateway documentation once, the actual capability didn't match my expectations, and after reading the documentation twice, I realized why, and then was wondering what is the point of the gateway. Will the etcd gateway eventually allow local clients to connect with http while it uses https to connect to the remote etcd endpoints? Or will the v3 proxy allow this when it's ready?

At the very least, I suggest treating this as a documentation bug, and add a note to the gateway guide that says if the remote endpoints are using TLS then local clients need to connect to gateway with the insecure flags. The only other way is for the remote etcd services to add 127.0.0.1 to their subject alternative name, which may not even be a possibility for someone who is installing a gateway that connects to a remote etcd service someone else controls.

[xiang90]

The gateway ONLY helps with endpoint part. It knows nothing above TCP stack. The gateway will not do TLS termination for you.

The first sentence of the gateway clearly states that

etcd gateway is a simple TCP proxy that forwards network data to the etcd cluster. 
The gateway is stateless and transparent;
 it neither inspects client requests nor interferes with cluster responses.

https://github.com/coreos/etcd/blob/master/Documentation/op-guide/gateway.md#what-is-etcd-gateway

I am closing this since gateway works as expected. If you want something can terminate TLS for you, see gRPC proxy.

[jbuhacoff]

The same page of documentation you linked also says this:

This wide-scale reconfiguration is both tedious and error prone.
etcd gateway solves this problem by serving as a stable local endpoint.

For TLS connections, it doesn't solve the problem. Clients still need to be configured with the TLS certificate. If they bring their own certificate, they may as well bring their own endpoint configuration as well, obviating the need for the gateway.

The words "TLS" and "SSL" aren't even mentioned on the gateway page. It would be helpful for readers if the documentation had even just one sentence to explicitly state that the gateway doesn't perform the TLS verification and that clients still need to be configured with the remote etcd server's TLS certificate or CA certificate.

You mentioned gRPC proxy but it's a reverse proxy, not a forward proxy aka gateway.

Users looking at using this etcd gateway can save time by writing a tiny wrapper script instead.

[xiang90]

The words "TLS" and "SSL" aren't even mentioned on the gateway page. It would be helpful for readers if the documentation had even just one sentence to explicitly state that the gateway doesn't perform the TLS verification and that clients still need to be configured with the remote etcd server's TLS certificate or CA certificate.

There is no mentioning since TLS is above TCP. Same reason we do not mention HTTP or HTTPs or HTTP2 or gRPC. If you wish to clarify this, you can submit a pull request to improve the doc where you see it fits.

We have no plan to support TLS termination in the gateway. If you want that feature, you can submit a feature request with your use case. Additionally, you can provide a design doc to expedite the process of adding that feature.

[xiang90]

Personally, I feel it might be OK to make gateway understand TLS.

[raoofm]

Is this feature being developed? I think it is a very valid usecase.