Add separate CA for etcd certificates #710
Assignees
Labels
area/security
kind/feature
Categorizes issue or PR as related to a new feature.
sig/cluster-lifecycle
Categorizes an issue or PR as relevant to SIG Cluster Lifecycle.
Comments
k8s-ci-robot
added
kind/feature
This was referenced Feb 24, 2018
k8s-github-robot
pushed a commit
to kubernetes/kubernetes
that referenced
this issue
Mar 1, 2018
Automatic merge from submit-queue. 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>. kubeadm 710 Switch to a dedicated CA for kubeadm etcd identities **What this PR does / why we need it**: On `kubeadm init`/`kubeadm upgrade`, this PR generates an etcd specific CA for signing the following certs: - etcd serving cert - etcd peer cert - apiserver etcd client cert These certs were previously signed by the kubernetes CA. The etcd static pod in `local.go` has also been updated to only mount the `/etcd` subdir of `cfg.CertificatesDir`. New phase command: ``` kubeadm alpha phase certs etcd-ca ``` See the linked issue for details on why this change is an important security feature. **Which issue(s) this PR fixes** Fixes kubernetes/kubeadm#710 **Special notes for your reviewer**: #### on the master this should still fail: ```bash curl localhost:2379/v2/keys # no output curl --cacert /etc/kubernetes/pki/etcd/ca.crt https://localhost:2379/v2/keys # handshake error ``` this should now fail: (previously would succeed) ``` cd /etc/kubernetes/pki curl --cacert etcd/ca.crt --cert apiserver-kubelet-client.crt --key apiserver-kubelet-client.key https://localhost:2379/v2/keys # curl: (35) error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate ``` this should still succeed: ``` cd /etc/kubernetes/pki curl --cacert etcd/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 generates an etcd specific CA for all etcd related certificates. ```
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 generated etcd certificates, kubeadm reuses the kubernetes CA.
This means that any kubernetes client cert (such as certs used to contact the apiserver) can also interact with etcd directly, bypassing validation, RBAC, and other logic.
What you expected to happen:
kubeadm should generate TLS identities for etcd from a separate CA as recommended in kubernetes/kubernetes#57415 (comment).
Etcd should only be accessible via certs intended for talking to etcd.
Anything else we need to know?:
This was discussed on the SIG Cluster Lifecycle call: Tue 20 February 2017.
Functionality:
server,peer, andapiserver-clientidentities.Considerations:
Shoud we use the existing kubernetes CA or create a dedicated etcd CA ?
It was decided in #594 that we should try using a shared kubernetes CA.
This becomes complicated because it's not possible to authenticate etcd peers based on their CN's in versions of etcd older than
v3.3. We also need to configure RBAC for clients which currently has to be done after etcd is bootstrapped.Adding support for a shared CA could be a good candidate for another issue.
The tradeoff is that we need to manage a third CA in addition to the kubernetes and front-proxy CA's.
The text was updated successfully, but these errors were encountered: