Rancher中的K8S认证和RBAC

Rancher Kubernetes拥有RBAC（基于角色的访问控制）功能，此功能可让管理员配置不一样的策略，容许或拒绝用户和服务账户访问Kubernetes API资源。

为了更好地理解RBAC功能是如何工做的，本文将阐明如何使用Kubernetes 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组织的任何用户的服务了：

关注微信公众号（RancherLabs），获取每日Docker&K8S技术干货推送。添加Rancher助手（RancherLabsChina）为好友，加入技术群，获取免费技术支持，年底赢取Apple Watch、Beats耳机、机械键盘等重磅好礼。