Rancher Kubernetes拥有RBAC（基于角色的访问控制）功能，此功能可以让管理员配置不同的策略，允许或拒绝用户和服务帐户访问Kubernetes API资源。
为了更好地理解RBAC功能是如何工作的，本文将阐明如何使用Ku bernetes API进行身份认证，以及RBAC授权模块如何与认证用户协同工作。
在Rancher中使用KUBERNETES验证
Rancher使用Webhook Token身份验证策略来认证用户的bearer token。首先，用户使用Rancher验证通过Kubernetes > CLI选项卡获得kube配置文件，这其中就包含bearer token。然后，kubectl借助此token和web hook远程认证服务，用Kubernetes API对用户进行身份认证:
当用户尝试使用bearer token对Kubernetes API进行认证时，认证webhook会与Rancher Kubernetes认证服务进行通信，并发送包含该token的身份认证审查对象。然后，Rancher Kubernetes认证服务将会发送一个检查状态，该状态指定用户是否经过身份认证。
审阅状态包含名称、uid和组等用户信息。Kubernetes API中的授权模块稍后将以此确定该用户的访问级别。
以下是Kubernetes发送给Rancher Kubernetes认证服务的认证请求示例。
认证请求：
Rancher Kubernetes认证服务决定该用户是否通过认证，并向Kubernetes发送响应。
认证响应：
如您所见，由于环境所有者发送此请求，用户在系统中被归为system:masters组，该用户组可以访问Kubernetes集群中的所有资源：
集群角色“集群管理”资源允许访问所有API组中的所有Kubernetes资源:
RBAC授权模块
对API的请求包含请求者的用户名、请求的操作以及操作所影响的对象的信息。在对Kubernetes API的请求成功进行认证之后，必须授权该请求。
RBAC授权模块定义了四个顶级对象，这四个对象控制授权用户的授权决策:
- 角色
- 集群角色
- 角色绑定
- 集群角色绑定
角色和集群角色都标识了Kubernetes API资源的权限集。它们之间唯一的区别是：角色可以在命名空间中定义，而集群角色绑定则在集群范围内定义。
角色绑定和集群角色绑定将定义的角色分配给用户、组或服务帐户。而它们可以通过在命名空间中进行角色绑定或在集群范围内进行集群角色绑定来获得授予权限。在下一节中我们将讨论相关示例。
如何在Rancher中启用Kubernetes RBAC功能
要在Rancher中全新安装Kubernetes来启用RBAC功能，您可以编辑默认环境或创建新的环境模板。在Kubernetes环境选项中，您可以启用RBAC，如果您已经启动了Kubernetes基础设施服务，则可以单击“更新”以更新Kubernetes的配置选项。
RBAC示例
如前一节所述，这些示例假设您已经启用了RBAC功能的Kubernetes，并假设您已启用Rancher的GitHub身份认证。
作为Kubernetes环境的所有者，如前所述，您可以访问所有Kubernetes API，因为集群管理员角色是默认分配给环境所有者的。管理员用户默认不会访问任何API资源。
若您已将一些GitHub用户和组添加为Kubernetes环境的成员，当你尝试访问Kubernetes API时，则会收到以下消息：
要跨所有Kubernetes集群启用GitHub组织的访问权限，请创建以下集群角色：
此角色定义了列表并获得了对服务资源的访问权限。此时, 集群角色不与任何用户或组关联, 因此以下步骤为创建集群角色绑定:
角色绑定指定了GitHub组织的“github_org:”组。这时您会发现，当您想将角色绑定应用于组时，每种认证类型都有专门的Rancher认证语法。有关更多详细信息，可参阅Rancher文档：
创建角色绑定后，您就可以列出属于此GitHub组织的任何用户的服务了：
