Use unix socket for etcd listen address

[jnummelin]

No need to listen on external address, each api server can connect to local etcd only. We can use local unix sockets too if that works for both etcd and api-server. (it should but there's a history of issues related)

[jnummelin]

Seems there's some missing bits and pieces in etcd side to really be able to use unix sockets: https://github.com/etcd-io/etcd/pull/11747

Let's move this bit further and re-visit once things are better supported in upstream etcd.

[mikhail-sakhnov]

Hm, but based on the code, it's already listens on 127.0.0.1 only?

	args := []string{
		fmt.Sprintf("--data-dir=%s", e.etcdDataDir),
		"--listen-client-urls=https://127.0.0.1:2379",
		"--advertise-client-urls=https://127.0.0.1:2379",
		"--client-cert-auth=true",
		fmt.Sprintf("--listen-peer-urls=%s", peerURL),
		fmt.Sprintf("--initial-advertise-peer-urls=%s", peerURL),
		fmt.Sprintf("--name=%s", name),
		fmt.Sprintf("--trusted-ca-file=%s", path.Join(e.certDir, "ca.crt")),
		fmt.Sprintf("--cert-file=%s", path.Join(e.certDir, "server.crt")),
		fmt.Sprintf("--key-file=%s", path.Join(e.certDir, "server.key")),
		fmt.Sprintf("--peer-trusted-ca-file=%s", path.Join(e.certDir, "ca.crt")),
		fmt.Sprintf("--peer-key-file=%s", path.Join(e.certDir, "peer.key")),
		fmt.Sprintf("--peer-cert-file=%s", path.Join(e.certDir, "peer.crt")),
		"--peer-client-cert-auth=true",
	}

[jnummelin]

Hm, but based on the code, it's already listens on 127.0.0.1 only?

yes, but our intention is to make it listen only a unix socket. need to update the issue title... :)

[mikhail-sakhnov]

should we have it for current (0.6.0) milestone? It seems to be blocked on the issue in the etcd repo which has no activity for a while. I ping the original author of the etcd issue if he is going to reiterate on the PR but now we can't really do anything in the mke.

[jnummelin]

Seems the upstream PR is still blocked, moving forward

[trawler]

because the upstream PR seem to be stale, I opened https://github.com/etcd-io/etcd/pull/12469

[unixfox]

Will I still be able to force listening on an IP address? For example if I need to port forward the etcd port using SSH for remote diagnose with the etcd cli then this could come handy to have etcd listening an IP address instead of a UNIX socket.

[jnummelin]

Will I still be able to force listening on an IP address?

Probably not. We really want to "hide" etcd from external access for security reasons of course.

if I need to port forward the etcd port using SSH for remote diagnose

AFAIK you can do the same for unix sockets. Something like ssh -R /tmp/remote_socket:1234:somehost user@remote_host

[jnummelin]

Bumbed to next milestone as we're still waiting for the upstream PR to land...

[jnummelin]

Still waiting on upstream, removing from milestone

[mikhail-sakhnov]

looks like upstream PR requests some changes (add more tests)

https://github.com/etcd-io/etcd/pull/12469

[github-actions[bot]]

The issue is marked as stale since no activity has been recorded in 30 days

[github-actions[bot]]

The issue is marked as stale since no activity has been recorded in 30 days