10分钟了解k8s认证鉴权体系

k8s应用很广泛了，但由于现在托管化、云化，日常工作大部分围绕应用组件，很少有人关注认证授权这一块，今天来简单聊聊。

所谓认证鉴权，必然有相互作用方。对于k8s而言，一切都是api对象，核心调用绕不过apiserver，所以整个体系也是围绕apiserver来展开的。简单来说，认证鉴权，就是某个用户/组件想要操作k8s里某个资源，在apiserver必然走的一个流程。

那为啥又叫认证鉴权？在k8s里，认证和鉴权是分开的。一个操作请求来到apiserver时，apiserver就会先启用身份认证机制，认证完给发起方一个身份，然后再启用鉴权机制，确认该身份有没有权限操作对应的资源，再决定要不要处理请求。

接下来就很好理解了，认证体系，通常包括了证书、账号令牌、认证代理等机制，apiserver会根据配置依次认证，使用第一个成功认证的方案来标识。

鉴权体系要复杂一些，常见的是RBAC模式，Role-Based Access Control，也就是基于角色的授权。RBAC可以定义一组权限作为一个角色Role或集群角色（ClusterRole），这两个的区别是Role需要指定一个namespace，而ClusterRole是作用在整个集群的。每个角色可以配置一组权限，也叫rule，描述哪些api资源可以被该角色进行访问/修改/删除等。
创建好角色还不够，需要创建一个角色绑定对象（RoleBinding或ClusterRoleBinding），将这些角色指定给某些主体（subjects），这样就完成了权限分配。
主体通常分为3类：服务账户（ServiceAccount）、用户（User）、用户组（Group），需要注意的是为避免复杂的角色分配，k8s默认创建了很多系统用户和系统用户组，并为其绑定了不少系统角色。这些主体/角色都适用system:开头命名，权限通常比较大，最好不要随意使用，否则容易被攻击利用。

这里再提一个Node鉴权模式，这个模式可以针对kubelet的api请求作出一些限制。前面提到RBAC模式有些系统角色权限很高，有一类漏洞就是当system:nodes用户组被不合理绑定了某些角色时，任意节点都可以提权获取核心api资源，这时Node模式就可以作为补充，确保节点kubelet只能修改自身节点资源。

整个认证鉴权都通过后，apiserver还有最后一道防线叫准入控制。准入控制可以在apiserver处理create/delete/modify请求前，对请求执行验证（validating）、变更（mutating）操作，实现强制修改资源、访问控制等功能，10分钟了，这里先不展开。