基于RBAC的role base鉴权是对kubernetes集群内模型资源进行访问控制的标准做法，同时各主流云厂商通常都有一套自身的访问控制引擎，就像EKS，GKE的IAM，AKS的ARM，阿里云的RAM服务；而对于普通用户来说，如何理解二者的区别和边界并做出正确的授权配置就成了一个令人头疼的问题。
下面让我们来了解一下各主流云厂商k8s服务的认证鉴权流程。
AuthN & AuthZ in EKS
EKS没有做到IAM与RBAC的统一授权，且仅支持CLI方式的集群内RBAC授权。默认使用aws-iam-authenticator完成请求的认证过程，其认证鉴权流程如下图所示：
1 首先用户客户端的config凭证中需要通过exec字段配置用于认证的roleARN和集群id
2 EKS apiserver配置了认证webhook，收到认证请求后发送至aws-iam-authenticator server，server端通过IAM sts:GetCallerIdentity接口返回与指定的角色arn进行匹配完成认证，同时通过configmap中指定的arn与用户的映射关系找到k8s对应的用户或组返回
mapUsers:
- userARN: arn:aws:iam::012345678901:user/Jane
username: jane
- userARN: arn:aws:iam::012345678901:user/Joe
username: joe
AI 代码解读
3 如果认证失败，apiserver返回401至客户端
4 认证成功后，apiserver根据返回的用户或组进行RBAC鉴权，注意这里的RBAC鉴权所需的角色和绑定模型仍需要用户通过cli手工完成配置。
AuthN & AuthZ in GKE
GKE在IAM中预置了几种面向k8s集群内的角色模型，用户可以通过GCP IAM控制台的绑定操作获取集群内k8s模型资源的使用权限，同时支持用户账号邮箱作为IAM和K8S认证的统一身份，从而部分实现了IAM与RBAC的授权统一，下图是GKE几种预置k8s应用角色和RBAC预置clusterrole之间的权限映射关系，在GKE文档中有对几种k8s相关预置角色的详细说明。
这里用户需要注意的是GKE的Kubernetes Engine Admin角色相当于RBAC的cluster-admin，对集群内所有模型具有全部权限，Developer对应RBAC edit，Viewer对应RBAC view角色；而Kubernetes Engine Cluster Admin反而没有k8s集群内资源的使用权限，只有GKE cluster资源层面的管理权限，这种集群管理平面和集群内应用数据平面的权限隔离往往是令客户感到困扰的地方。
另外，在实际的生产环境中，如果某用户在IAM控制台内被授予了内置的Kubernetes Engine Developer角色，那么他将拥有集群所有namespace的写权限，这也包括kube-system ns, 由于GKE还不支持ns粒度的一步授权，这在某些多租场景下是无法接受的。通常根据权限最小化原则，管理员只会给普通用户一个全局Viewer的权限，再通过手工配置RBAC角色绑定完成更细粒度的授权。在整个授权流程中IAM授权是基础，而通过RBAC配置可以实现上层应用的精细化权限控制。
AuthN & AuthZ in AKS
AKS提供了Azure AD与k8s之间的认证身份集成能力，具体请参见，用户可面向Azure AD中的账号邮箱或组id在k8s集群中进行相应的RBAC角色绑定，为此AKS提供了CLI形式的绑定命令，当然这个过程仍然和Azure Resource Manager中的集群管理平面RBAC授权是分裂的两步操作。
值得一提的是Azure AD与AKS的认证集成利用k8s原生的oidc webhook认证模式很好的弥补k8s在用户账号管理能力上的不足，同时能够更好地支持吊销AD内用户访问k8s的集群凭证。
AuthN & AuthZ in ACK&AMK
阿里云容器服务的访问控制授权同样需要划分为管理平面授权和数据平面的授权，其中管理平面授权面向的是阿里云资源的权限控制，比如子账号在控制台对集群的可见性，集群自动伸缩，下载证书等权限都是由阿里云RAM服务来统一控制的，这也和阿里云其他云服务资源的授权模式保持一致。而对于集群内k8s模型的权限控制，仍旧通过RBAC角色配置完成，整体授权流程如下图所示，注意同GKE类似，RAM授权仍旧是整个授权流程的基础，用户需要确保首先完成RAM授权获得集群可见权限的基础上，在上层完成集群内应用资源的RBAC授权。
相较于其他云厂商的授权流程，阿里云容器服务控制台提供了可视化的授权管理页面，提供了如下能力：
- 提供了四种常用预置RBAC角色模板的可视化增删配置，降低了权限管理员的rbac学习成本
- 支持集群namespaces细粒度授权
- 同时支持多个集群内用户自定义clusterrole的自动绑定能力
- 支持RAM授权校验能力，同时可以根据当前授权配置帮助用户生成一个权限最小化的只读RAM策略模板方便管理员进行管理平面的RAM授权
- 支持主账号和具有集群管理员角色子账号的分级授权配置
- 支持所有集群维度的批量授权
- 使用阿里云uid为RAM和RBAC授权的统一身份id，降低差异性；同时提供用户对应config凭证的一键下载能力
- 提供了基于RAM的k8s集群联合认证支持工具
管理平面的云平台资源授权和集群内应用资源的RBAC授权本来就是一个专业化和精细化的复杂操作，通过如上特性，阿里云容器服务希望能够帮助用户更好的理解二者的区别并降低整个授权流程的复杂度。
在以上几个主流云厂商k8s集群已经具备的认证授权能力之外，下面的几个rbac相关的开源工具也是对整个授权流程的有效补充：
- kubectl auth can-i - kubectl原生命令，查询指定用户是否有相应的请求权限
- rakkess - 基于auth can-i，全局展示指定用户对资源的所有操作权限
- kubectl-who-can - 用于查询哪些用户在该集群中有指定操作的权限
- rbac-lookup - 查询指定用户的所有RBAC绑定权限
- RBAC-manager - 通过CRD的方式管理用户对应的所有绑定，同时支持在满足label selectors的ns中自动配置绑定
