Document options for etcd client authentication in tcp listener

[gberche-orange]

Thanks for sharing the kine component with the community. I'm looking for ways to secure a standalone kine cluster

https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#limiting-access-of-etcd-clusters mentions

After configuring secure communication, restrict the access of etcd cluster to only the Kubernetes API servers. Use TLS authentication to do so.

For example, consider key pairs k8sclient.key and k8sclient.cert that are trusted by the CA etcd.ca. When etcd is configured with --client-cert-auth along with TLS, it verifies the certificates from clients by using system CAs or the CA passed in by --trusted-ca-file flag. Specifying flags --client-cert-auth=true and --trusted-ca-file=etcd.ca will restrict the access to clients with the certificate k8sclient.cert.

Once etcd is configured correctly, only clients with valid certificates can access it. To give Kubernetes API servers the access, configure them with the flags --etcd-certfile=k8sclient.cert, --etcd-keyfile=k8sclient.key and --etcd-cafile=ca.cert.
Note: etcd authentication is not currently supported by Kubernetes. For more information, see the related issue Support Basic Auth for Etcd v2.

However, from available cli options, I can't find the equivalent of --client-cert-auth=true in kine when accepting tcp connections

kine/main.go

Lines 28 to 99 in e0ae664

	app.Flags = []cli.Flag{
	cli.StringFlag{
	Name: "listen-address",
	Value: "0.0.0.0:2379",
	Destination: &config.Listener,
	},
	cli.StringFlag{
	Name: "endpoint",
	Usage: "Storage endpoint (default is sqlite)",
	Destination: &config.Endpoint,
	},
	cli.StringFlag{
	Name: "ca-file",
	Usage: "CA cert for DB connection",
	Destination: &config.BackendTLSConfig.CAFile,
	},
	cli.StringFlag{
	Name: "cert-file",
	Usage: "Certificate for DB connection",
	Destination: &config.BackendTLSConfig.CertFile,
	},
	cli.StringFlag{
	Name: "server-cert-file",
	Usage: "Certificate for etcd connection",
	Destination: &config.ServerTLSConfig.CertFile,
	},
	cli.StringFlag{
	Name: "server-key-file",
	Usage: "Key file for etcd connection",
	Destination: &config.ServerTLSConfig.KeyFile,
	},
	cli.IntFlag{
	Name: "datastore-max-idle-connections",
	Usage: "Maximum number of idle connections retained by datastore. If value = 0, the system default will be used. If value < 0, idle connections will not be reused.",
	Destination: &config.ConnectionPoolConfig.MaxIdle,
	Value: 0,
	},
	cli.IntFlag{
	Name: "datastore-max-open-connections",
	Usage: "Maximum number of open connections used by datastore. If value <= 0, then there is no limit",
	Destination: &config.ConnectionPoolConfig.MaxOpen,
	Value: 0,
	},
	cli.DurationFlag{
	Name: "datastore-connection-max-lifetime",
	Usage: "Maximum amount of time a connection may be reused. If value <= 0, then there is no limit.",
	Destination: &config.ConnectionPoolConfig.MaxLifetime,
	Value: 0,
	},
	cli.StringFlag{
	Name: "key-file",
	Usage: "Key file for DB connection",
	Destination: &config.BackendTLSConfig.KeyFile,
	},
	cli.StringFlag{
	Name: "metrics-bind-address",
	Usage: "The address the metric endpoint binds to. Default :8080, set 0 to disable metrics serving.",
	Destination: &metricsConfig.ServerAddress,
	Value: ":8080",
	},
	cli.DurationFlag{
	Name: "slow-sql-threshold",
	Usage: "The duration which SQL executed longer than will be logged. Default 1s, set <= 0 to disable slow SQL log.",
	Destination: &metrics.SlowSQLThreshold,
	Value: time.Second,
	},
	cli.BoolFlag{
	Name: "metrics-enable-profiling",
	Usage: "Enable net/http/pprof handlers on the metrics bind address. Default is false.",
	Destination: &metricsConfig.EnableProfiling,
	},
	cli.BoolFlag{Name: "debug"},

Does kine authN and authZ instead only support unix socket (i.e.when no --listen-addressflag is passed, and instead unix://kine.sock is read) by 3rd party component ?

[brandond]

The upstream kubernetes and etcd docs do not generally apply to kine; kine implements just enough of the etcd API to be usable by Kubernetes and additional bits of functionality like RBAC are optional and therefore not implemented. Kine does not have any authn/authz whatsoever. Anyone that can connect to the etcd endpoint is allowed to access it.

Configuring TLS on the listener (via the --server-cert-file/--server-key-file options) does not add any client certificate validation, it just enables use of a server certificate on the listening port.

We can take a look at enabling client certificate auth, but given that our most common deployment scenarios see kine being accessed via a unix socket where filesystem permissions can be used to restrict access, it may not be a high priority.

[gberche-orange]

Thanks Brad for your prompt answer. I'm also investigating ways to provide client cert auth outside of the kine process, as a MITM component such as haproxy and kine ensuring connections can only come from haproxy

In our case of running kine within a k8s cluster, this might result into the haproxy ingress configured with mTLS
https://haproxy-ingress.github.io/docs/configuration/keys/#auth-tls