How certificates are used by your cluster
Kubernetes requires PKI for the following operations:
- Client certificates for the kubelet to authenticate to the API server
- Server certificate for the API server endpoint
- Client certificates for administrators of the cluster to authenticate to the API server
- Client certificates for the API server to talk to the kubelets
- Client certificate for the API server to talk to etcd
- Client certificate/kubeconfig for the controller manager to talk to the API server
- Client certificate/kubeconfig for the scheduler to talk to the API server.
- Client and server certificates for the front-proxy
- API server端点的服务器证书
用于群集管理员向API服务器进行身份验证的客户端证书
- API服务器与kubelets对话的客户端证书
API服务器与etcd对话的客户端证书
- kubelet的客户端证书以向API服务器进行身份验证
客户端证书/kubeconfig 以使controller manager与API服务器对话 客户端证书/kubeconfig 以使scheduler与API服务器对话的。
- front-proxy的客户端和服务器证书
仅当您运行kube-proxy以支持扩展API服务器时,才需要front-proxy证书。
etcd also implements mutual TLS to authenticate clients and peers.
etcd还实现了双向TLS来对客户端和对等方进行身份验证。
Where certificates are stored存储证书的位置
If you install Kubernetes with kubeadm, certificates are stored in /etc/kubernetes/pki . All paths in this documentation are relative to that directory.
If you don‘t want kubeadm to generate the required certificates, you can create them in either of the following ways.
Single root CA
You can create a single root CA, controlled by an administrator. This root CA can then create multiple intermediate CAs, and delegate all further creation to Kubernetes itself.
您可以创建由管理员控制的单个根CA。然后,该根CA可以创建多个中间CA,并将所有进一步的创建委托给Kubernetes本身。
Required CAs:
path | Default CN | description |
ca.crt,key |
kubernetes-ca |
Kubernetes general CA |
etcd/ca.crt,key |
etcd-ca |
For all etcd-related functions |
front-proxy-ca.crt,key |
kubernetes-front-proxy-ca |
For the front-end proxy |
On top of the above CAs, it is also necessary to get a public/private key pair for service account management, sa.key and sa.pub .
除了上述CA之外,还必须获得用于service account管理的公共/私有密钥对sa.key和sa.pub。
All certificates
If you don‘t wish to copy the CA private keys to your cluster, you can generate all certificates yourself.
Required certificates:
Default CN | Parent CA | O (in Subject) | kind | hosts (SAN) |
kube-etcd |
etcd-ca |
|
server, client |
localhost , 127.0.0.1 |
kube-etcd-peer |
etcd-ca |
|
server, client |
<hostname> , <Host_IP> , localhost , 127.0.0.1 |
kube-etcd-healthcheck-client |
etcd-ca |
|
client |
|
kube-apiserver-etcd-client |
etcd-ca |
system:masters |
client |
|
kube-apiserver |
kubernetes-ca |
|
server |
<hostname> , <Host_IP> , <advertise_IP> , [1] |
kube-apiserver-kubelet-client |
kubernetes-ca |
system:masters |
client |
|
front-proxy-client |
kubernetes-front-proxy-ca |
|
client |
|
[1]: any other IP or DNS name you contact your cluster on (as used by kubeadm the load balancer stable IP and/or DNS name, kubernetes , kubernetes.default , kubernetes.default.svc , kubernetes.default.svc.cluster , kubernetes.default.svc.cluster.local )
where kind maps to one or more of the x509 key usage types:
kind | Key usage |
server |
digital signature, key encipherment, server auth |
client |
digital signature, key encipherment, client auth |
Note: Hosts/SAN listed above are the recommended ones for getting a working cluster; if required by a specific setup, it is possible to add additional SANs on all the server certificates.
Note:
For kubeadm users only:
- The scenario where you are copying to your cluster CA certificates without private keys is referred as external CA in the kubeadm documentation.
- If you are comparing the above list with a kubeadm generated PKI, please be aware that
kube-etcd , kube-etcd-peer and kube-etcd-healthcheck-client certificates are not generated in case of external etcd.
Certificate paths
Certificates should be placed in a recommended path (as used by kubeadm). Paths should be specified using the given argument regardless of location.
Default CN | recommended key path | recommended cert path | command | key argument | cert argument |
etcd-ca |
etcd/ca.key |
etcd/ca.crt |
kube-apiserver |
|
--etcd-cafile |
kube-apiserver-etcd-client |
apiserver-etcd-client.key |
apiserver-etcd-client.crt |
kube-apiserver |
--etcd-keyfile |
--etcd-certfile |
kubernetes-ca |
ca.key |
ca.crt |
kube-apiserver |
|
--client-ca-file |
kubernetes-ca |
ca.key |
ca.crt |
kube-controller-manager |
--cluster-signing-key-file |
--client-ca-file, --root-ca-file, --cluster-signing-cert-file |
kube-apiserver |
apiserver.key |
apiserver.crt |
kube-apiserver |
--tls-private-key-file |
--tls-cert-file |
kube-apiserver-kubelet-client |
apiserver-kubelet-client.key |
apiserver-kubelet-client.crt |
kube-apiserver |
--kubelet-client-key |
--kubelet-client-certificate |
front-proxy-ca |
front-proxy-ca.key |
front-proxy-ca.crt |
kube-apiserver |
|
--requestheader-client-ca-file |
front-proxy-ca |
front-proxy-ca.key |
front-proxy-ca.crt |
kube-controller-manager |
|
--requestheader-client-ca-file |
front-proxy-client |
front-proxy-client.key |
front-proxy-client.crt |
kube-apiserver |
--proxy-client-key-file |
--proxy-client-cert-file |
etcd-ca |
etcd/ca.key |
etcd/ca.crt |
etcd |
|
--trusted-ca-file, --peer-trusted-ca-file |
kube-etcd |
etcd/server.key |
etcd/server.crt |
etcd |
--key-file |
--cert-file |
kube-etcd-peer |
etcd/peer.key |
etcd/peer.crt |
etcd |
--peer-key-file |
--peer-cert-file |
etcd-ca |
|
etcd/ca.crt |
etcdctl |
|
--cacert |
kube-etcd-healthcheck-client |
etcd/healthcheck-client.key |
etcd/healthcheck-client.crt |
etcdctl |
--key |
--cert |
Same considerations apply for the service account key pair:
private key path | public key path | command | argument |
sa.key |
|
kube-controller-manager |
--service-account-private-key-file |
|
sa.pub |
kube-apiserver |
--service-account-key-file |
You must manually configure these administrator account and service accounts:
filename | credential name | Default CN | O (in Subject) |
admin.conf |
default-admin |
kubernetes-admin |
system:masters |
kubelet.conf |
default-auth |
system:node:<nodeName> (see note) |
system:nodes |
controller-manager.conf |
default-controller-manager |
system:kube-controller-manager |
|
scheduler.conf |
default-scheduler |
system:kube-scheduler |
|
Note: The value of <nodeName> for kubelet.conf must match precisely the value of the node name provided by the kubelet as it registers with the apiserver. For further details, read the Node Authorization.
-
For each config, generate an x509 cert/key pair with the given CN and O.
-
Run kubectl as follows for each config:
KUBECONFIG=<filename> kubectl config set-cluster default-cluster --server=https://<host ip>:6443 --certificate-authority <path-to-kubernetes-ca> --embed-certs
KUBECONFIG=<filename> kubectl config set-credentials <credential-name> --client-key <path-to-key>.pem --client-certificate <path-to-cert>.pem --embed-certs
KUBECONFIG=<filename> kubectl config set-context default-system --cluster default-cluster --user <credential-name>
KUBECONFIG=<filename> kubectl config use-context default-system
These files are used as follows:
filename | command | comment |
admin.conf |
kubectl |
Configures administrator user for the cluster |
kubelet.conf |
kubelet |
One required for each node in the cluster. |
controller-manager.conf |
kube-controller-manager |
Must be added to manifest in manifests/kube-controller-manager.yaml |
scheduler.conf |
kube-scheduler |
Must be added to manifest in manifests/kube-scheduler.yaml |
|