公钥、私钥、数字签名
https://blog.csdn.net/tabactivity/article/details/49685319

傻傻分不清楚的k8s证书
https://blog.sealyun.com/views/container/2020/kube-cert.html#service-account%E5%AF%86%E9%92%A5%E5%AF%B9-sa-key-sa-pub

k8s学习笔记：证书详解（推荐阅读）

https://www.cnblogs.com/centos-python/articles/11043570.html

https://www.cnblogs.com/linhaifeng/articles/15167217.html

先写结论

#首先了解一下CA证书和私钥
ca-config.json
ca-csr.json
ca.csr
ca-key.pem
ca.pem
其中ca.csr是一个签署请求，ca-key.pem是ca的私钥，ca.pem是CA证书，是后面kubernetes组件会用到的RootCA。

k8s集群一共有多少证书，总共8套
先从Etcd算起：

1、Etcd对外提供服务，要有一套etcd server证书

2、Etcd各节点之间进行通信，要有一套etcd peer证书

3、Kube-APIserver访问Etcd，要有一套etcd client证书

再算kubernetes：

4、Kube-APIserver对外提供服务，要有一套kube-apiserver server证书

5、kube-scheduler、kube-controller-manager、kube-proxy、kubelet和其他可能用到的组件，需要访问kube-APIserver，要有一套kube-APIserver client证书

6、kube-controller-manager要生成服务的service account，要有一对用来签署service account的证书(CA证书)

7、kubelet对外提供服务，要有一套kubelet server证书

8、kube-APIserver需要访问kubelet，要有一套kubelet client证书

建K8S集群 kubeadm 会生成的很多证书

[root@k8s-master01 ~]# cd /etc/kubernetes/pki
[root@k8s-master01 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

k8s集群一共有多少证书：
先从Etcd算起：
1、Etcd对外提供服务，要有一套etcd server证书
2、Etcd各节点之间进行通信，要有一套etcd peer证书
3、Kube-APIserver访问Etcd，要有一套etcd client证书

再算kubernetes：
4、Kube-APIserver对外提供服务，要有一套kube-apiserver server证书
5、kube-scheduler、kube-controller-manager、kube-proxy、kubelet和其他可能用到的组件，
   需要访问kube-APIserver，要有一套kube-APIserver client证书
6、kube-controller-manager要生成服务的service account，要有一对用来签署service account的证书(CA证书)
7、kubelet对外提供服务，要有一套kubelet server证书
8、kube-APIserver需要访问kubelet，要有一套kubelet client证书

深入了解证书先了解一下 公钥，私钥和数字签名

总结：公钥和私钥是成对的，它们互相解密。
公钥加密，私钥解密。
私钥数字签名，公钥验证。

一、公钥加密  假设一下，我找了两个数字，一个是1，一个是2 我喜欢2这个数字，就保留起来，
不告诉你们(私钥），然后我告诉大家，1是我的公钥。

我有一个文件，不能让别人看，我就用1加密了。别人找到了这个文件，但是他不知道2就是解密的私钥啊，
所以他解不开，只有我可以用 数字2，就是我的私钥，来解密。这样我就可以保护数据了。
我的好朋友x用我的公钥1加密了字符a，加密后成了b，放在网上。别人偷到了这个文件，但是别人解不开，
因为别人不知道2就是我的私钥， 只有我才能解密，解密后就得到a。这样，我们就可以传送加密的数据了。

二、私钥签名 如果我用私钥加密一段数据（当然只有我可以用私钥加密，因为只有我知道2是我的私钥），
结果所有的人都看到我的内容了，因为他们都知 道我的公钥是1，那么这种加密有什么用处呢？

假如我的好朋友x说有人冒充我给他发信。怎么办呢？我把我要发的信，内容是c，用我的私钥2，加密，
加密后的内容是d，发给x，再告诉他 解密看是不是c。他用我的公钥1解密，发现果然是c。 这个时候，
他会想到，能够用我的公钥解密的数据，必然是用我的私钥加的密。只有我知道我的私钥，
因此他就可以确认确实是我发的东西。 这样我们就能确认发送方身份了。这个过程叫做数字签名。
用私钥来加密数据，用途就是数字签名。

RSA算法基于一个十分简单的数论事实：将两个大素数相乘十分容易，但那时想要对其乘积进行因式分解却极其困难，因此可以将乘积公开作为加密密钥。

根证书与证书

通常我们配置https服务时需要到"权威机构"(CA)申请证书。过程是这样的：
1.网站创建一个密钥对，提供公钥和组织以及个人信息给权威机构
2.权威机构颁发证书
3.浏览网页的朋友利用权威机构的根证书公钥解密签名，对比摘要，确定合法性
4.客户端验证域名信息有效时间等（浏览器基本都内置各大权威机构的CA公钥）

这个证书包含如下内容：
1.申请者公钥
2.申请者组织和个人信息
3.签发机构CA信息，有效时间，序列号等
4.以上信息的签名

根证书又名自签名证书，也就是自己给自己颁发的证书。CA(Certificate Authority)被称为证书授权中心，
k8s中的ca证书就是根证书。

密钥对：sa.key sa.pub  根证书：ca.crt etcd/ca.crt  私钥:ca.key 等 其它证书

生成CA证书和私钥
cfssl gencert -initca ca-csr.json | cfssljson -bare ca
ls | grep ca
ca-config.json
ca.csr
ca-csr.json
ca-key.pem
ca.pem
其中ca-key.pem是ca的私钥，ca.csr是一个签署请求，ca.pem是CA证书，是后面kubernetes组件会用到的RootCA。

#Pod中的容器访问API Server(如dashboard容器 访问API Server) 因为Pod的创建、销毁是动态的，所以要为它
手动生成证书就不可行了。K8s使用了Service Account解决Pod 访问API Server的认证问题
默认情况下，每个 namespace 都会有一个 ServiceAccount，如果 Pod 在创建时没有指定 ServiceAccount
就会使用 Pod 所属的 namespace 的 ServiceAccount,默认值/run/secrets/kubernates.io/serviceaccount/
#test 随便查看kube-system命名空间下的pod
  kubectl get pod -n kube-system
  kubectl exec  kube-proxy-cmzp6 -n=kube-system -it -- /bin/sh #进入容器
  cd /run/secrets/kubernates.io/serviceaccount/
  ls #里面有ca.crt(根的证书)   namespace  token 3个文件
  #token是使用 API Server 私钥签名的 JWT（json web token）。用于访问API Server时，Server端认证
  #ca.crt，根证书(是k8s中私有的)。用于Client端验证API Server发送的证书
  #namespace, 标识这个service-account-token的作用域名空间

service Account密钥对 sa.key sa.pub
提供给 kube-controller-manager使用，kube-controller-manager通过 sa.key 对 token 进行签名,
master 节点通过公钥 sa.pub 进行签名的验证 如 kube-proxy 是以 pod 形式运行的, 在 pod 中, 
直接使用 service account 与 kube-apiserver 进行认证, 此时就不需要再单独为 kube-proxy 创建证书了,
会直接使用token校验。