HTTPS CA认证

可以通过token即一个字符串来识别合法用户，这个token不是存储在etcd中的，而是在一个api server能访问的文件中。

也可以通过用户名+密码用base64算法加密后发到http请求报文里，再由服务端进行解密的方式进行认证。

最后一种是CA根证书认证，如下图所示，客户端和服务端都会向CA机构申请证书，需要通信的时候，客户端发送自己的证书给服务端，服务端也会返回自己的证书给客户端。认证通过以后，通过随机私钥进行加密通信。K8s采用的是CA认证。

Kubeconfig

是一个认证函，里面包含了应该怎样去访问服务的信息。

cat /root/.kube/config默认这个文件里面就包含了集群的访问方式和认证信息。

举个例子，现在有一个development集群和一个scratch集群，在development集群，前端工程师工作在frontend的namespace，存储工程师工作在storage的namespace。在scratch集群，开发者工作在default的namespace。开发访问development集群使用证书验证，访问scratch集群需要用帐号和密码。基本框架如下:

apiVersion: v1
kind: Config
preferences: {}

clusters:
- cluster:
  name: development
- cluster:
  name: scratch

users:
- name: developer
- name: experimenter

contexts:
- context:
  name: dev-frontend
- context:
  name: dev-storage
- context:
  name: exp-scratch

cat config-demo 这个config-demo文件有2个clusters,2个users,3个contexts的框架,里面还可以继续填充需要的信息。

认证分类

访问api server，如果是本机组件如controller manager，scheduler默认访问一个非安全加密端口，如果是其它远程组件如kubelet，kube-proxy就需要进行https双向认证。如果是Pod需要用到下面的SA。

SA

Pod创建销毁是动态的，用证书认证就很耗资源，SA是一种循环认证的机制，解决了pod和API server访问的认证问题。SA也是一组文件，包含了私钥和命名空间等重要信息。默认每个namespace都会有一个SA。如果创建的pod没有指定sa，它将采用当前namespace的默认sa。

[root@zr-k8s-master01 secret]# cat satest.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx-container
image: ikubernetes/myapp:v1