Certificate update

The default certificate valid for one year

Once the certificate has expired, the following tips when using kubectl: `Unable to connect to the server: x509: certificate has expired or is not yet valid`

View certificate expiration

 1 [root@k8s-test-master-1 ~]# kubeadm alpha certs check-expiration
 2 CERTIFICATE EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
 3 admin.conf Jul 28, 2020 05:41 UTC 364d no
 4 apiserver Jul 28, 2020 05:41 UTC 364d no
 5 apiserver-etcd-client Jul 28, 2020 05:41 UTC 364d no
 6 apiserver-kubelet-client Jul 28, 2020 05:41 UTC 364d no
 7 controller-manager.conf Jul 28, 2020 05:41 UTC 364d no
 8 etcd-healthcheck-client Jul 28, 2020 05:41 UTC 364d no
 9 etcd-peer Jul 28, 2020 05:41 UTC 364d no
10 etcd-server Jul 28, 2020 05:41 UTC 364d no
11 front-proxy-client Jul 28, 2020 05:41NO 364d UTC
 12 is scheduler.conf Jul- 28 , 2020  05 : 41 is UTC NO 364d
 13 is  
14  # See root CA certificate is valid (years)
 15 [@ K8S the root-Test-The MASTER . 1 PKI] CD # / etc / Kubernetes / PKI
 16 [@ K8S the root-Test-The MASTER . 1 PKI] # LS | grep in ca.crt | xargs -I X509 OpenSSL -text {} - in {} | grep  " Not the After " 
. 17 Not the After: Jul- 26 is  05 : 41 is : 23  2029 GMT
18 Not After : Jul 26 05:41:23 2029 GMT

Certificate directory structure

[root@k8s-test-master-1 pki]# pwd
/etc/kubernetes/pki
[root@k8s-test-master-1 pki]# tree .
.
├── apiserver.crt
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
├── apiserver.key
├── apiserver-kubelet-client.crt
├── apiserver-kubelet-client.key
├── ca.crt
├── ca.key
├── etcd
│   ├── ca.crt
│   ├── ca.key
│   ├── healthcheck-client.crt
│   ├── healthcheck-client.key
│   ├── peer.crt
│   ├── peer.key
│   ├── server.crt
│   └── server.key
├── front-proxy-ca.crt
├── front-proxy-ca.key
├── front-proxy-client.crt
├── front-proxy-client.key
├── sa.key
└── sa.pub


1 directory, 22 files

Kubernetes cluster root certificate

/etc/kubernetes/pki/ca.crt

/etc/kubernetes/pki/ca.key

Thus certificate issued by the root certificate are:

1, kube-apiserver assembly held by the server certificate

　　/etc/kubernetes/pki/apiserver.crt

　　/etc/kubernetes/pki/apiserver.key

2, kubelet hold components of the client certificate

　　/etc/kubernetes/pki/apiserver-kubelet-client.crt

　　/etc/kubernetes/pki/apiserver-kubelet-client.key

kubelet general does not explicitly specify the server certificate, but only specify ca root certificate, let kubelet server certificate is automatically generated and saved to the cert-dir configuration file in the folder based on the local host information.

Convergence layer (Aggregator) certificate

/etc/kubernetes/pki/front-proxy-ca.crt

/etc/kubernetes/pki/front-proxy-ca.key

Thus the root certificate certificate issued by only one group:

1, the client certificate using the Agent, on behalf of the user as authentication and kube-apiserver

/etc/kubernetes/pki/front-proxy-client.crt

/etc/kubernetes/pki/front-proxy-client.key

etcd cluster root certificate

/etc/kubernetes/pki/etcd/ca.crt

/etc/kubernetes/pki/etcd/ca.key

Thus the root Certificate Authority certificate issued are:

1, etcd server holds the server certificate

/etc/kubernetes/pki/etcd/server.crt

/etc/kubernetes/pki/etcd/server.key

2, the client certificate in the peer nodes in the cluster communicate with each other using

/etc/kubernetes/pki/etcd/peer.crt

/etc/kubernetes/pki/etcd/peer.key

3, pod client certificates defined probes used Liveness

/etc/kubernetes/pki/etcd/healthcheck-client.crt

/etc/kubernetes/pki/etcd/healthcheck-client.key

4, configured to do with etcd server mutual authentication of client certificates in kube-apiserver in

/etc/kubernetes/pki/apiserver-etcd-client.crt

/etc/kubernetes/pki/apiserver-etcd-client.key

Serveice Account keys

This group key is only available to children kube-controller-manager use. Kube-controller-manager of the token signed by sa.key, master node verifies the signature by the public key sa.pub.

authenticating link API Server supports multiple identity verification ways: client cert, bearer token, static password auth, etc., these methods have a way (Kubernetes API Server will attempt to by-ways) by authenticating, then the identity check will pass. Once the API Server discovery client-initiated request using the service account token way, API Server will automatically adopt signed bearer token way for identity verification. The request will be used to carry the service account token participation verification. The token API Server is started with the API server when you create a service account parameters: value -service-account-key-file is signed (sign) generated. If -service-account-key-file did not pass any value, then the default value -tls-private-key-file, that API Server's private key (server.key).

By After authenticating, API Server according to where the group Pod username: serviceaccounts and system:: serviceaccounts: (NAMESPACE) authority and its admission control authority processing two links system. In both session, cluster administrators can set permissions to refine the service account.

/etc/kubernetes/pki/sa.key

/etc/kubernetes/pki/sa.pub

Cluster kubeadm created, kube-proxy, flannel, coreDNS pod form is running in the pod, the direct use of kube-apiserver service account for authentication, then you do not need to create a separate certificate for kube-proxy

Update certificate

Yaml cluster configuration file generation

1 kubeadm config view > /root/kubeadm.yaml

kubeadm.yaml

 1 apiServer:
 2   extraArgs:
 3     authorization-mode: Node,RBAC
 4   timeoutForControlPlane: 4m0s
 5 apiVersion: kubeadm.k8s.io/v1beta2
 6 certificatesDir: /etc/kubernetes/pki
 7 clusterName: kubernetes-test
 8 controlPlaneEndpoint: 10.8.28.200:6443
 9 controllerManager: {}
10 dns:
11   type: CoreDNS
12 etcd:
13   local:
14     dataDir: /data/etcd
15 imageRepository: k8s.gcr.io
16 kind: ClusterConfiguration
17 kubernetesVersion: v1.15.1
18 networking:
19   dnsDomain: cluster.local
20   podSubnet: 192.168.0.0/16
21   serviceSubnet: 10.96.0.0/12
22 scheduler: {}