134. Rancher 系统身份验证

它是 Rancher 身份验证代理的一部分牛模拟系统是Rancher实现身份验证的关键组成部分。主体必须明确拥有“冒充”权限才能冒充其他用户。Rancher 为 Kubernetes 新增的关键特性之一是集中式用户身份验证。该特性允许用户使用一套凭据对任何 Kubernetes 集群进行身份验证。这种集中式用户身份验证是通过 Rancher 身份验证代理实现的该代理与 Rancher 的其他组件一起安装。此代理对用户进行身份验证并使用服务帐户将其请求转发到 Kubernetes 集群。为什么我们需要牛模拟系统Kubernetes 不是自带用户身份验证功能吗简而言之答案是肯定的。Rancher 是一款多集群 Kubernetes 管理工具它允许从单一中心点在任何位置、任何服务商上部署和运行集群。Rancher 位于这些多个 Kubernetes 集群的“前端”。由于 Kubernetes 对身份验证提供了强大的支持因此每个集群都可以拥有自己的身份验证策略。默认情况下Kubernetes 集群通过 kubeconfig 文件进行访问该文件包含对集群的完全访问权限。而使用 Rancher集群 API 通信不再需要 kubeconfig 文件因为它采用了身份验证代理机制。Rancher Manager 服务器通过服务帐户连接到下游用户集群上的 Kubernetes API 服务器从而与 Kubernetes 集群通信。该服务帐户为在 Pod 中运行的进程提供身份标识。那么Kubernetes中的用户呢Kubernetes 对用户和组实体的支持并不完整。它确实有作为用户的服务帐户。但对于普通用户而言Kubernetes 文档指出他们的身份应该由外部身份提供商进行管理。因此API 不支持用户对象及其组成员关系链接。如果要管理多个 Kubernetes 集群以及跨这些集群的用户则需要进行外部管理。在这种情况下Rancher是如何进行用户身份验证的Rancher设计并开发了自己的身份验证框架并扩展了Kubernetes以支持用户和组对象为了实现这一点它使用了 Kubernetes 的用户模拟功能。用户模拟一个用户或服务帐户能够扮演另一个用户的角色用户或服务帐户应具有“模拟”权限。Rancher身份验证系统的一个重要关键点是在每次Kubernetes API调用中身份验证代理都会对调用者进行身份验证。它会在将调用转发给Kubernetes主节点之前设置正确的Kubernetes模拟标头。Rancher身份验证代理在集中式认证模型中Rancher 位于所有 Kubernetes 集群的“前端”充当中央认证代理从而简化多个集群的认证过程。Rancher 管理员只需在 Rancher 服务器上集中配置并启用一次针对 Rancher 可用集成之一例如 Active Directory、OpenLDAP 等的身份验证即可管理所有集群的身份验证。用户通过 Rancher 进行身份验证Rancher 使用标准 bearer token 和用户模拟技术将用户请求重定向到特定的 Kubernetes 集群以模拟该用户的行为。牛模仿系统的资源我们创建了四种资源来应对身份冒用命名空间牛模拟系统服务帐户cattle-impersonation-system/cattle-impersonation-用户 ID​ 在后台Kubernetes 还会创建一个帐户令牌供 Rancher 用于身份验证cattle-impersonation-system/cattle-impersonation-用户 ID-token-哈希值集群角色cattle-impersonation-用户 ID集群角色绑定cattle-impersonation-用户 ID内部实施创建模仿资源分为两个部分。第一部分当用户创建集群或被添加为集群所有者/成员/其他角色或被添加到该集群上的某个项目时系统 会在集群上为该用户创建一个ClusterRoleTemplateBinding或ProjectRoleTemplateBinding 。当ClusterRoleTemplateBinding或ProjectRoleTemplateBinding存在时Rancher 会创建命名空间如果尚不存在、服务帐户、集群角色绑定以及集群角色 并根据当时掌握的信息配置相应的规则。这些规则将包含模拟用户 ID 和 Rancher 已知的用户组的功能。第二部分当用户使用集群浏览器、下载了kubeconfig文件的kubectl命令或使用/k8s/clusters代理API的curl命令向下游集群发出请求时Rancher会拦截该请求并检查资源是否为最新、是否存在以及用户的规则是否为最新。如果用户通过外部身份验证提供程序登录Rancher 在第一部分可能无法获知用户有哪些额外属性因为这些属性包含在请求中的令牌中。此时Rancher 将更新集群角色以包含请求中包含的这些额外属性例如主体 ID 和用户名。下游集群上的所有相关资源命名空间、服务帐户、密钥、集群角色和集群角色绑定都会在 Rancher 服务器上进行监视和缓存因此检查这些资源应该只会带来最小的性能开销。请求图例如在此图中名为 Bob 的用户想要查看下游用户集群名为“用户集群”上运行的所有 Pod。在 Rancher 系统中他可以运行 kubectl 命令来查看 pod。Bob 通过 Rancher 的身份验证代理进行了身份验证。身份验证代理会将所有 Kubernetes API 调用转发到下游集群。它与本地身份验证、Active Directory 和 GitHub 等身份验证服务集成。每次 Kubernetes API 调用时身份验证代理都会对调用者进行身份验证并在将调用转发到 Kubernetes 主节点之前设置正确的 Kubernetes 模拟标头。Rancher 使用 服务帐户与 Kubernetes 集群通信该服务帐户为在 Pod 中运行的进程提供身份标识。默认情况下Rancher 会生成一个 kubeconfig 文件其中包含通过 Rancher 服务器代理连接到下游用户集群上的 Kubernetes API 服务器的凭据。该 kubeconfig 文件kube_config_rancher-cluster.yml拥有对集群的完全访问权限。问答ClusterRole 何时应该更改通常情况下首次登录时会添加 userextras/principalid 和 userextras/username 属性。Rancher 未来对用户额外属性的处理方式进行改进后将不再需要这样做。如果用户添加或更改身份验证提供程序则此设置会发生变化。注意Rancher 目前不支持更改身份验证提供程序。如果身份验证提供程序中用户的组发生更改则此结果也会随之更改。根据用户发出请求的方式UI、kubectl 或 curl令牌可能会有所不同——有时令牌包含不同的用户额外属性。清理工作何时进行当 ClusterRoleTemplateBinding 或 ProjectRoleTemplateBinding 被删除时当用户从​​项目或集群中移除时服务帐户、集群角色和集群角色绑定将被清理。访问Rancher-K8S解决方案博主企业合作伙伴 https://blog.csdn.net/lidw2009