k8s RBAC-(认证) ServiceAccount与User

 Kubernetes集群中所有资源的访问和变更都是通过Kubernetes API Server的REST API来实现的，所以集群安全的关键点就在于如何识别并认证客户端身份（Authentication），以及随后访问权限的授权（Authorization）这两个关键问题，本节对认证管理进行说明。

我们知道，Kubernetes集群提供了3种级别的客户端身份认证方式。

◎　最严格的HTTPS证书认证：基于CA根证书签名的双向数字证书认证方式。

◎　HTTP Token认证：通过一个Token来识别合法用户。

◎　HTTP Base认证：通过用户名+密码的方式认证。

HTTPS证书认证的原理

这里需要有 CA 证书，我们知道 CA PKI 系统中通信双方都信任的实体，被称为可 信第 方（ Trusted Third Pa町， TTP ）。 CA 作为可信第三方的重要条件之 就是 CA 的行为具 有非否认性。作为第 方而不是简单的上级，就必须能让信任者有追究自己责任的能力。 CA 通过证书证实他人的公钥信息，证书上有 CA 的签名。用户如果因为信任证书而有了损失，则证书可以作为有效的证据用于追究 CA 的法律责任。正是因为 CA 承担责任的承诺，所以 CA 也被称为可信第三方。在很多情况下， CA 与用户是相互独立的实体， CA 作为服务提供方，有 可能因为服务质量问题（例如，发布的公钥数据有错误）而给用户带来损失。在证书中绑定了 公钥数据和相应私钥拥有者的身份信息，并带有 CA 的数字签名：证书中也包含了 CA 的名称， 以便于依赖方找到 CA 的公钥，验证证书上的数字签名。

 

CA认证涉及诸多概念，比如根证书、自签名证书、密钥、私钥、加密算法及HTTPS等，本书大致讲述SSL协议的流程，有助于理解CA认证和Kubernetes CA认证的配置过程。

如图所示，CA认证大概包含下面几个步骤。

（1）HTTPS通信双方的服务器端向CA机构申请证书，CA机构是可信的第三方机构，它可以是一个公认的权威企业，也可以是企业自身。企业内部系统一般都用企业自身的认证系统。CA机构下发根证书、服务端证书及私钥给申请者。

（2）HTTPS通信双方的客户端向CA机构申请证书，CA机构下发根证书、客户端证书及私钥给申请者。

（3）客户端向服务器端发起请求，服务端下发服务端证书给客户端。客户端接收到证书后，通过私钥解密证书，并利用服务器端证书中的公钥认证证书信息比较证书里的消息，例如，比较域名和公钥与服务器刚刚发送的相关消息是否一致，如果一致，则客户端认可这个服务器的合法身份。

（4）客户端发送客户端证书给服务器端，服务端在接收到证书后，通过私钥解密证书，获得客户端证书公钥，并用该公钥认证证书信息，确认客户端是否合法。

（5）客户端通过随机密钥加密信息，并发送加密后的信息给服务端。在服务器端和客户端协商好加密方案后，客户端会产生一个随机的密钥，客户端通过协商好的加密方案加密该随机密钥，并发送该随机密钥到服务器端。服务器端接收这个密钥后，双方通信的所有内容都通过该随机密钥加密。

上述是双向认证SSL协议的具体通信过程，这种情况要求服务器和用户双方都有证书。单向认证SSL协议则不需要客户端拥有CA证书，对于上面的步骤，只需将服务器端验证客户证书的过程去掉，之后协商对称密码方案和对称通话密钥时，服务器发送给客户的密码没被加密即可。

 完整过程:

完整过程：
step1： “客户”向服务端发送一个通信请求

“客户”->“服务器”：你好

step2： “服务器”向客户发送自己的数字证书。证书中有一个公钥用来加密信息，私钥由“服务器”持有

“服务器”->“客户”：你好，我是服务器，这里是我的数字证书

step3： “客户”收到“服务器”的证书后，它会去验证这个数字证书到底是不是“服务器”的，数字证书有没有什么问题，数字证书如果检查没有问题，就说明数字证书中的公钥确实是“服务器”的。检查数字证书后，“客户”会发送一个随机的字符串给“服务器”用私钥去加密，服务器把加密的结果返回给“客户”，“客户”用公钥解密这个返回结果，如果解密结果与之前生成的随机字符串一致，那说明对方确实是私钥的持有者，或者说对方确实是“服务器”。

“客户”->“服务器”：向我证明你就是服务器，这是一个随机字符串//前面的例子中为了方便解释，用的是“你好”等内容，实际情况下一般是随机生成的一个字符串。

“服务器”->“客户”：{一个随机字符串}[私钥|RSA]

step4： 验证“服务器”的身份后，“客户”生成一个对称加密算法和密钥，用于后面的通信的加密和解密。这个对称加密算法和密钥，“客户”会用公钥加密后发送给“服务器”，别人截获了也没用，因为只有“服务器”手中有可以解密的私钥。这样，后面“服务器”和“客户”就都可以用对称加密算法来加密和解密通信内容了。

“服务器”->“客户”：{OK，已经收到你发来的对称加密算法和密钥！有什么可以帮到你的？}[密钥|对称加密算法]

“客户”->“服务器”：{我的帐号是aaa，密码是123，把我的余额的信息发给我看看}[密钥|对称加密算法]

“服务器”->“客户”：{你好，你的余额是100元}[密钥|对称加密算法]

……//继续其它的通信

示例：

比如k8s组件与apiserver通信，这里设置kubectl的kubeconfig 制作过程

mkdir /root/.kube

KUBE_CONFIG="/root/.kube/config"
KUBE_APISERVER="https://192.168.0.190:8443"

# 设置集群
kubectl config set-cluster kubernetes \
  --certificate-authority=/opt/kubernetes/ssl/ca.pem \
  --embed-certs=true \
  --server=${KUBE_APISERVER} \
  --kubeconfig=${KUBE_CONFIG}
 
 # 设置用户
kubectl config set-credentials cluster-admin \
  --client-certificate=/opt/kubernetes/ssl/kubectl-admin.pem \
  --client-key=/opt/kubernetes/ssl/kubectl-admin-key.pem \
  --embed-certs=true \
  --kubeconfig=${KUBE_CONFIG}

# 设置上下文与集群、用户关系绑定
kubectl config set-context default \
  --cluster=kubernetes \
  # --namespace=xxx   # 限制某个命名空间的权限
  --user=cluster-admin \
  --kubeconfig=${KUBE_CONFIG}

# 切换(使用)到当前上下文
kubectl config use-context default --kubeconfig=${KUBE_CONFIG}

 

以上只是通过了认证，然后进行授权操作