[这是Freshworks工程师关于Kuberneteslearnings系列文章的第二篇。别再听库伯内特斯的恐怖故事了！]一旦我们决定迁移到Kubernetes（或amazoneks）并用pods替换我们所有的机器（或EC2实例），我们就必须确保开发人员能够访问这个集群。同时，我们还需要引入某种程度的控制，这样我们就可以确保特定的用户对系统有特定的访问权限。正如在本系列的第一篇博客中提到的，我们是AWS OpsWorks的大量用户。集成身份访问管理用户访问OpsWorks堆栈上的实例很容易管理。OpsWorks提供了一个接口来将IAM用户映射到其堆栈。我们所要做的就是为用户提供一个根据分配给他们的特权登录和访问OpsWorks实例的堡垒。这提供了访问OpsWorks实例的IAM用户的审计跟踪。不幸的是，EKS没有提供相同级别的集成或能力来让IAM用户访问kubernetesapi。这促使我们解决了以下挑战：保持堡垒的位置，因为我们仍然是混合模式的OpsWorks和EKS；管理用户对集群的访问的简单机制，类似于OpsWorks；可审核的工作流，以查看可跟踪用户访问的位置。20000英尺处的溶液在AWS中，访问是使用角色定义的。因此，角色是访问AWS中任何资源的一流机制。因此，解决方案是为用户提供角色映射，并携带该角色访问Kubernetes（EKS）集群。在堡垒中，用户可以登录并担任为他们创建的角色，以便访问EKS集群。用户的角色将使用ClusterRoleBinding（或RoleBinding）绑定到ClusterRole（或角色）。本文将进一步深入研究以上段落中描述的集群访问机制的实现细节。定义群集用户类别为了控制对集群的访问，我们认为在EKS集群级别有三个类别可以转换为ClusterRole：管理员：包括ClustorRole和角色操作权限在内的所有权限；超级用户：除ClusterRole和角色操作权限外的所有权限；用户：读取权限和执行权限。我们决定在命名空间级别也有三个类别可以转换为角色：Admin：命名空间上的所有权限，包括角色操作权限；超级用户：命名空间上的所有权限，角色操作权限除外；用户：对资源的读访问权限，以及exec权限。因此，用户对集群的访问权限是通过绑定到上面的一个（在集群级别使用ClusterRolebinding或在命名空间级别使用RoleBinding完成的）。Lambda和用户角色如上所述，我们需要在每个EKS集群上创建多个clusterrole，以便根据用户的访问权限对其进行存储。而且，由于我们必须启动许多集群，随着时间的推移，手动创建和管理这些集群将变得非常困难。所以我们创建了一个AWS Lambda函数，在每个EKS集群上创建这些ClusterRoles。为了将IAM用户绑定到ClusterRole，或者将它们添加到ClusterRoleBinding，我们扩展了Lambda来完成这项工作。现在，Lambda不仅创建ClusterRoles，还创建相应的IAM组（与该ClusterRole同名）。为什么选择IAM集团？因为它们的作用类似于bucket，当用户被添加到IAM组时，Lambda会将该用户添加到适当的ClusterRoleBinding中。由于用户的身份信息与AWS的身份不相关，因此无法对其进行访问。所以Lambda还负责创建用户角色。这是ClusterRoleBinding中存在的IAM用户角色。这个Lambda实现了很多神奇的功能，包括在命名空间级别执行相同的工作，其中它将以与ClusterRoles类似的方式处理Role和RoleBindings，这在上一节中指定。Dockersh和Metadataproxy现在我们已经将用户的角色映射到Kubernetes集群下基于角色的访问控制，现在的挑战是让一个安全的Shell（或SSH）用户承担该角色。好吧，有了开源和熟悉的技术，工具就在不远处了，我们登陆了Dockersh和Metadataproxy。Dockersh和其他Shell一样，只是当您将用户的默认Shell配置为Dockersh时，当用户登录实例时，用户将被放入与其他用户完全隔离的docker容器中。这样我们就可以控制用户在他们的环境中做什么。因此，我们创建了一个Chef配方，使docksh成为该堡垒上所有用户的默认Shell，并为集群访问配置了kubeconfig文件。我们还在Dockersh镜像中安装了访问EKS集群的所有相关工具。以下是Docker映像附带的一些工具：Kubectl：用于访问Kubernetes集群的官方命令行接口工具K9s：基于Curses的工具，用于访问集群，还提供了查看日志和执行pods的功能Kubectx:CLI工具，用于在集群上下文之间快速切换Kubens:CLI工具，用于在上下文中快速切换名称空间Metadataproxy是AWS元数据服务的一个代理，它从Security Token服务（它使人们能够为IAM用户请求临时和有限的权限凭证）中提供作用域的IAM凭证。因此，我们设置IP表规则，从用户的Dockersh拦截对元数据服务的所有调用，并使其通过Metadataproxy Docker容器。现在，有趣的部分。当用户连接到堡垒时，我们将其放入Dockersh中，将名为IAM_ROLE的环境变量设置为用户的IAM username。由于所有元数据调用都被Metadataproxy容器截获，因此它会查找Dockersh容器的IAM_角色，并使该容器承担该角色。而且由于Lambda已经在EKS集群上为角色创建了正确的访问映射，所以Dockersh中的用户可以从那里享受特权。把它们放在一起当创建名为hyades的新EKS集群时，AWS Lambda将创建以下ClusterRoles以及相应的IAM组。如果用户John Smith想要超级用户访问hyades，他必须提出一个请求，AWS云管理员将johnsmith（IAM用户名）添加到k8s poweruser@hydesIAM集团。Lambda在随后的迭代中做了两件事：创建一个名为johnsmith的IAM角色；将johnsmith绑定到ClusterRolek8s poweruser@hydes。在这一点上，约翰史密斯应该能够登录到堡垒使用库贝克特访问hyades授予他的特权。堡垒本身是使用Chef管理和配置的，Chef将Dockersh设置为所有用户的默认Shell。它还为所有集群配置Kubernetes配置。由于johnsmith是一个集群级的超级用户，他的能力涵盖了集群上的所有名称空间。另外，johnsmith是以johnsmith角色而不是johnsmith用户身份连接到集群的，因为Dockersh和Metadataproxy在后台一起使用的技巧。现在假设我们创建一个名为taurus的名称空间。同样，awslambda将在下一个周期中选择此更改，并创建以下IAM组和Kubernetes角色。现在用户Pocahontas来了，希望管理员访问taurus名称空间。她会向云管理员提出请求。云管理员只需将pocahontas（IAM用户名）添加到k8s管理员@hyades@金牛座国际机械师协会。同样，Lambda将接受此更改，创建一个pocahontas IAM角色，并将pocahontas绑定到k8s管理员@hyades@金牛座伯内特斯角色。Pocahontas现在可以作为taurus名称空间的管理员登录堡垒并访问集群hyades。但她不能在集群范围内访问。因此，更改johnsmith和pocahontas用户权限应该像在不同IAM组之间移动它们一样简单。另外，johnsmith和pocahontas的所有操作都将被跟踪到对Kubernetes集群的API调用，这可以在CloudWatch Insights中跟踪，因为所有EKS控制平面审计日志都被推送到CloudWatch。 作者：所有图表都是使用LibreOffice Draw创建的。图片中使用的字体是建筑师女儿常规字体。相关岗位和库伯内特斯一起去吉托普EKS星团地形形成