2、k8s集群安全-认证
K8S的三种级别的客户端认证方式
HTTPS证书认证
基于CA根证书签名的客户端身份认证方式，最严格的认证方式
HTTP Token认证
通过一个token来识别合法用户，token是一个很长很复杂的字符串，每个token对应一个用户名存储在API Server能访问的文件中。当客户端发起API调用请求时，需要在HTTP Header中加入token
HTTP Base认证
通过"用户名+密码"的方式认证,用base64算法进行编码后的字符串放在HTTP Request中的Header authoriaztion域里发送给服务端，服务端收到后进行编码，获取用户名及密码
一、HTTPS证书认证
二、需要认证的节点
安全性说明
Controller Manager、Scheduler与API Server在同一台机器内所以直接使用API Server的非安全端口访问
--insecure-bind-address=127.0.0.1
kubectl、kubelet、kube-proxy访问API Server就需要证书进行HTTPS双向认证
证书签发
手动签发：通过k8s集群与CA进行签发HTTPS证书
自动签发：bubelet收起访问API Server时，使用token做认证，通过后，Controller Manager会为kubectl生成一个证书，以后的访问都是用证书做认证
三、kubeconfig
可以将其理解为认证函，kubeconfig文件包含集群参数、客户端参数、集群context信息
k8s组件通过启动时指定不同的kubeconfig文件可以切换到不同的集群
默认文件路径 /$HOME/.kube/config
kubectl config view
kubectl config view --kubeconfig=my-custom-config
主要结构
Clusters 集群 放置集群的规范，如API Server地址 CA根证书
Contexts 哪些帐户作用于哪些集群
Users 账户 放置密钥和对应的证书
四、ServiceAccount
Pod中的容器访问API Server。因为Pod的创建和销毁都是动态的，每次生成pod要为其创建证书，浪费资源。所以不能为其手动生成证书。使用Service Account来让pod重复使用证书
五、Secret与SA的关系
k8s设计了一种资源对象叫做Service，分为两类；
一种是用于ServiceAccount的service-account-token，
另一种是用于保存用户自定义密保信息的Opaque。
ServiceAccount包含三个部分：token、ca.crt、namespace
token是使用API Server私钥签名的JWT。用于访问API Server时，Server端认证
ca.crt是根证书。用于Client端验证API Server发送的证书
namespace是标识这个service-account-token的作用域命名空间
JWT（Json Web Token），是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准。该token被设计为紧凑且安全的，特别适用于分布式站点的单点登陆场景。JWT的声明一般被用来在身份提供者和服务提供者之间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其他业务逻辑所必须的声明信息，该token也可以直接被用于认证，也可以被加密
kubectl get secret --all-namespace
kubectl describe secret default-token-333 --namespace=kube-system
默认情况下，每个namaspace都会有一个ServiceAccount，如果Pod在创建时没有指定ServiceAccount，就会使用Pod所属namespace的ServiceAccount。默认挂载目录： /run/secrets/kubernetes.io/serviceaccount/
总结
