search

k3s-io / kine

Run Kubernetes on MySQL, Postgres, sqlite, dqlite, not etcd.
Apache License 2.0
1.49k stars 226 forks source link

Document options for etcd client authentication in tcp listener #272

Open gberche-orange opened 5 months ago

gberche-orange commented 5 months ago

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

https://github.com/k3s-io/kine/blob/e0ae6642766a955cd4603bf749e010c7c689e0c9/main.go#L28-L99

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 commented 5 months ago

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 commented 5 months ago

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