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.kubeconfig4、准入机制

5、切换用户，测试操作权限

①第一次测试用户权限

lucky用户只能在lucky-cloud命名空间中查看pod的情况，其他的这个用户没有权限

若想lucky用户有这些权限，在rbac文件中加入这些权限

②第二次测试用户权限resources里一般给这两个权限，其他的权限可以加，但要和别的条件关联，较复杂