k8s的安全机制
k8s是分布式集群管理工具，k8s作用是容器编排
1、安全机制核心：API server。API server作为整个集群内部通信的中介，也是外部控制的入口，所有的安全机制都是围绕api sserver来进行设计的。请求api server资源要满足3个条件：认证、鉴权、准入机制。三个条件都通过才能在k8s中创建资源
2、认证anthentcation方式
（1）http token：通过token识别合法用户。token是一个很长、很复杂的字符串，字符串是用来表达客户的一种方式，每一个token对应一个用户名，用户名存储在api server能够访问的文件中，客户端发起请求时，http header中包含token，token对应到api server，api server对应到用户名存储文件，解码查看是否对应用户名，验证通过可访问集群
（2）http base：用户名+密码的验证方式。用户名和密码都是通过base64进行加密，加密完成的字符串存储在http request的header Atuthorization中，发送给服务端。服务端收到加密字符串，解码后获取用户名和密码，验证通过，登录成功
（3）https证书：这是最严格、最严谨的方式。基于CA根证书签名的客户端身份进行验证
3、认证的访问类型
（1）k8s组件对api server的访问（kubelet、kube-proxy）
（2）pod对api server的访问（pod、coredns、dashborad）
4、安全性说明
（1）controller namnger、scheduler与api server在一台服务器，可以直接使用api server的非安全端口进行访问
（2）kubectl、kubelet、kube-proxy都是通过api server的https证书进行双向验证，都是用6443端口进行验证
5、签发证书的方式
（1）手动签发（二进制部署是手动签发证书。CA签发：把证书匹配到每个对应组件，然后访问6443即可）
（2）自动签发（kubeadm是自动签发证书。kubelet第一次访问api server使用token，一旦token通过后，controller manager会为kubelet生成一个证书，以后都是通过证书访问）
6、kubeconfig
此文件包含集群的参数，比如CA证书、API server地址、客户端的参数（客户端的证书和私钥、集群的名称和用户名）等。k8s组件都是通过启动时指定访问不同的kubeconfig文件，可以访问不同的集群，再到api server，再到namespace，再到资源对象，再到pod，再到容器。简而言之，kubeconfig既是集群的描述文件，也是集群信息的保存文件，包含了集群的访问方式和认证信息
./kube/config保存的是kubectl的访问认证信息
7、Service Account
pod中的容器访问api server依靠serviceaccount。由于动态的pod动作（增删改查），为每个pod手动生成一个证书太麻烦，于是k8s使用service account来进行循环认证，service account里包含了统一的认证信息，通过service account直接进行api server访问
8、Secret与SA 的关系
Kubernetes 设计了一种资源对象叫做 Secret，分为两类：
①用于保存 ServiceAccount 的 service-account-token
②用于保存用户自定义保密信息的 Opaque
Service Account 中包含三个部分：
①Token：是使用 API Server 私钥签名的 Token 字符串序列号，用于访问 API Server 时，Server 端认证
②ca.crt：ca 根证书，用于 Client 端验证 API Server 发送来的证书
③namespace：标识这个 service-account-token 的作用域名空间
默认情况下，每个 namespace 都会有一个 Service Account，如果 pod 在创建时没有指定 Service Account，就会使用 pod 所属namespace 的 Service Account。每个 pod 在创建后都会自动设置spec.serviceAccount 为 default（除非指定了其他 Service Accout）
9、鉴权
之前的认证方式只确认双方都是可信的，可以相互通信，鉴权是为了确定请求方的访问权限
| AlwaysDeny |
拒绝所有（用于测试） |
| AlwaysAllow |
允许所有（用于测试） |
| ABAC |
attribute-based access control基于属性的访问控制 |
| webhook |
外部访问集群内部的鉴权方式 |
| RBAC |
role-base access control基于角色的访问控制。k8s的默认规则机制（常用） |
| ①角色role——绑定角色到指定的命名空间rolebinding 指定命名空间的资源控制权限 |
|
| ②集群clusterrole——绑定集群clusterrolebinding 可以授权所有命名空间的资源控制权限 kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user kubernetes-admin |
|
5、准入控制
准入控制是api server的一个准入控制器的插件列表，不同的插件可以实现不同的准入控制机制。一般情况下建议使用官方默认的准入控制器，比如limitranger命名空间的配额限制、serviceAccount、resourceQuota命名空间的配额限制
不同用户管理自己的命名空间实验
1、创建用户lucky，命名空间lucky-cloud
2、认证
①上传证书
②生成根证书
cd /etc/kubernetes/pki/
cfssl gencert -ca=ca.crt -ca-key=ca.key -profile=kubernetes /opt/lucky/lucky-csr.json | cfssljson -bare lucky
3、鉴权
kubeconfig保存token、鉴权信息等
使用上下文参数生成 lucky.kubeconfig 文件，查看证书
kubectl config use-context kubernetes --kubeconfig=lucky.kubeconfig
4、准入机制
5、切换用户，测试操作权限
①第一次测试用户权限
lucky用户只能在lucky-cloud命名空间中查看pod的情况，其他的这个用户没有权限
若想lucky用户有这些权限，在rbac文件中加入这些权限
②第二次测试用户权限
resources里一般给这两个权限，其他的权限可以加，但要和别的条件关联，较复杂
