kubernetes学习笔记6：认证、鉴权、角色和安全

k8s API请求从发起到持久化入库：首先是人机交互，kubelet对APIserver的请求过程，然后是机机交互，pod中业务逻辑与APIserver之间的交互，这里面分为三个步骤，首先是authentication认证，可能返回401错误，然后是authorization鉴权，可能返回403错误，最后是admissioncontrol，判断用户请求是否是安全合规的。

k8s支持的请求认证方式有basic认证（用户名和密码），X509证书认证（使用较多，集群ca签发或者是APIserver的管理员approve来自client请求才签发的客户端证书访问APIserver，APIserver收到请求后，进行tls握手，验证证书，并验证客户端证书的请求源地址等信息，开启是“双向认证），jwt（service account，openID，webhooks）。

serviceaccount（是k8s中唯一能通过API的方式管理APIserver访问凭证，用于pod 的业务进程与APIserver的交互，用户创建完namespace的同时，会在该namespace下生成明为Default的serviceaccount和对应service的实例）。

k8s鉴权使用的是rbac，鉴权三要素有主体（谁），API resource（访问的资源），verbs（什么操作），鉴权的粒度就是namespace，对多租户有用。

role角色定义了用户对某个namespace下的资源的权限和对资源操作的权限，rolebinding就是角色跟主体之间的绑定也就是跟用户绑定，clusterrole是针对都有namespace命名空间内的资源权限和操作权限，clusterrolebinding是所有namespace下资源跟主体之间的绑定也就是跟用户绑定。

default clusterrolebinding集群中预置角色（system：basic-user，cluster-admin是system：masters组默认集群角色绑定，clusterrolebinding）。

security context将容器设置为非root运行模式有效阻止cve-2019-5736攻击，但是现实不理想，82%使用root权限运行。可以在生成镜像的Dockerfile文件中添加USER 2，然后在生成pod的yaml文件中添加添加一下内容来保证容器安全策略有pod和container非root运行。

securityContext:
      fsGroup:2
      runAsGroup:2
      runAsUser:2

遵循权限最小化，启用pod security policy，开启admission controllers（imagepolicywebhook，alwayspullimages），控制容器运行时是否有文件系统的写权限，控制容器运行时拥有的capabilities，可以显示添加或删除。