Secure etcd API /w TLS on kubeadm init #594
Assignees
Labels
area/security
kind/feature
Categorizes issue or PR as related to a new feature.
priority/important-longterm
Important over the long term, but may not be staffed and/or may need multiple releases to complete.
sig/cluster-lifecycle
Categorizes an issue or PR as relevant to SIG Cluster Lifecycle.
triaged
Milestone
Comments
k8s-ci-robot
added
kind/feature
luxas
added
the
priority/important-longterm
k8s-github-robot
pushed a commit
to kubernetes/kubernetes
that referenced
this issue
Feb 25, 2018
Automatic merge from submit-queue (batch tested with PRs 59159, 60318, 60079, 59371, 57415). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Feature/kubeadm 594 etcd TLS on init/upgrade **What this PR does / why we need it**: On `kubeadm init`/`kubeadm upgrade`, this PR generates certificates for securing local etcd: - etcd serving cert - etcd peer cert - apiserver etcd client cert Flags and hostMounts are added to the etcd and apiserver static-pods to load these certs. For connections to etcd, `https` is now used in favor of `http` and tests have been added/updated. Etcd only listens on localhost, so the serving cert SAN defaults to `DNS:localhost,IP:127.0.0.1`. The etcd peer cert has SANs for `<hostname>,<api-advertise-address>`, but is unused. New kubeadm config options, `Etcd.ServerCertSANs` and `Etcd.PeerCertSANs`, are used for user additions to the default certificate SANs for the etcd server and peer certs. This feature continues to utilize the existence of `MasterConfiguration.Etcd.Endpoints` as a feature gate for external-etcd. If the user passes flags to configure `Etcd.{CAFile,CertFile,KeyFile}` but they omit `Endpoints`, these flags will be unused, and a warning is printed. New phase commands: ``` kubeadm alpha phase certs etcd-server kubeadm alpha phase certs etcd-peer kubeadm alpha phase certs apiserver-etcd-client ``` **Which issue(s) this PR fixes** Fixes kubernetes/kubeadm#594 **Special notes for your reviewer**: #### on the master these should fail: ```bash curl localhost:2379/v2/keys # no output curl --cacert /etc/kubernetes/pki/ca.crt https://localhost:2379/v2/keys # handshake error ``` these should succeed: ``` cd /etc/kubernetes/pki curl --cacert ca.crt --cert apiserver-etcd-client.crt --key apiserver-etcd-client.key https://localhost:2379/v2/keys ``` **Release note**: ```release-note On cluster provision or upgrade, kubeadm now generates certs and secures all connections to the etcd static-pod with mTLS. ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
/kind feature
/area etcd
/area kubeadm
/area security
/sig cluster-lifecycle
What happened:
When initializing a cluster with kubeadm, the local connection to etcd is insecure.
Anyone logged into the master machine has implicit root access via the etcd port.
What you expected to happen:
kubeadm should generate TLS identities for etcd.
The connection should be secure -- unaccessible without valid credentials.
Anything else we need to know?:
This was discussed in in the kubeadm working group: Wed 13 December 2017.
Functionality:
Considerations:
Shoud we use the existing kubernetes CA or create a dedicated etcd CA ?
The text was updated successfully, but these errors were encountered: