将最小权限原则应用于Kubernetes访问

Kubernetes是用于管理容器编排工作，为团队提供自动化部署、管理和扩展的应用平台。在创建或维护应用时，开发、运维和IT团队需访问Kubernetes环境。为确保安全性和资源保护，组织需遵循最小权限原则，并使用Kubernetes的身份验证和授权机制实现访问控制。明确定义哪些用户可访问API及可执行的操作和资源权限。禁用无身份验证的访问，保护团队帐户。

Kubernetes如何使用RBAC管理访问

基于角色的访问控制（RBAC）是许多系统中使用的一种方法，根据个体角色定义资源权限。Kubernetes具有强大的RBAC机制，允许配置权限，明确规定用户或用户组与集群中任何Kubernetes对象交互的方式。使用这种RBAC框架是保护集群及其容器化应用的第一步。

Kubernetes对象定义容器化应用程序及其资源和操作策略的持久实体。这些对象本质上是集群期望状态的定义。可以使用Kubernetes API创建、更改或删除对象。

在Kubernetes中，有两种类型的帐户：用户帐户和服务帐户。用户帐户给人员使用，而服务帐户用于访问Kubernetes API的进程。Kubernetes RBAC规定了这些帐户对资源的访问，包括Pod、密钥、控制器和自定义资源定义（CRD）。在Kubernetes中，权限使用Role或ClusterRole对象定义，然后通过RoleBinding和ClusterRoleBinding对象将定义的权限分配给账户。RBAC API声明了四种Kubernetes对象类型：

01.Role（角色）- 管理单个命名空间内资源的权限。

02.ClusterRole（集群角色）- 管理整个集群的权限。

03.RoleBinding（角色绑定）- 将角色分配给特定命名空间内的帐户或组。

04.ClusterRoleBinding（集群角色绑定）- 将集群角色分配给集群中所有命名空间的帐户或组。

在接下来的两部分中，我们将探讨RBAC策略如何与最小权限原则（PoLP）一致，限制对集群中资源的访问。

定义权限

为了正确地建立权限，您需要配置 Kubernetes 以反映每个团队成员的角色，同时考虑到 PoLP 实践。使用Role和 ClusterRoles 是实现这一目标的一种极其有效的方法。Role适用于一个命名空间中的资源，而 ClusterRoles 适用于整个集群中的资源。

在本节中，我们将探讨如何使用Role和ClusterRole限制对系统某些部分的访问。

假设一家公司有一名新的高级DevOps 工程师，他必须能够查看所有环境变量和其他Secret。此外，作为运维团队的一员，这名工程师可能还需要查看为公司应用程序创建的 Pod，以便监控包含客户端应用程序的容器的运行状况。

要实现这一点，首先在您的YAML文件中定义Role和ClusterRole对象。以下是如何定义Role以启用对development 命名空间中Secret的读取权限的示例：

上述代码指定了API版本。RBAC使用rbac.authorization.k8s.io API组来通过Kubernetes API配置授权策略。它明确指定了定义类型为"Role"，并指出将应用于的命名空间为"development"。假设"development"是开发团队使用的资源所在的命名空间。接下来，"Role"被命名为"secret-reader"。

"rules"部分包含了规则适用的资源以及"Role"可以对这些资源执行的操作。

注意，上述代码在metadata中没有指定命名空间。这是因为ClusterRoles不是以命名空间划分的。因此，您只在metadata部分指定了ClusterRole的名称，即pod-reader。

接下来，您可以绑定Role到以development为命名空间的资源组，并将ClusterRole绑定到整个集群。现在，您的团队可以查看development中的Secret（其他人不能）。以这种方式应用PoLP使您的团队能够访问执行开发任务所需的内容，但防止组织中的其他人访问这些Pods和资源。

您现在创建了一个Role以使DevOps工程师能够访问Secret，并为整个DevOps团队创建了一个ClusterRole以读取Pods。在下一部分中，您将为Role和ClusterRole分配权限。

分配权限

当特定员工需要访问应用程序配置中的Secret时。这些密钥可能是API密钥对或环境变量。此外，我们需要使用集群绑定以在整个集群中授予权限。集群绑定可以允许特定集群角色中的任何用户在集群中的任何位置读取Pods，而无需考虑命名空间。

如果DevOps工程师是一个名为sola的用户，你可以将上面创建的Role分配给development命名空间中名为sola的用户。因此，sola将能够读取该命名空间中的Secret。

RoleBinding定义如下：

在上述代码中，您执行了以下操作：

  • 指定了RoleBinding类型。这是一种将角色与主体关联的Kubernetes资源类型。

  • 创建了一个名为secret-reader的角色，并将其应用于development命名空间。此角色可用于授予对特定命名空间中的Secret资源的访问权限。

  • 在subjects部分指定了名为sola的用户。您还可以指定多个主体，以便将角色应用于多个用户或组。

  • 在roleRef部分将secret-reader角色附加到RoleBinding中。请注意，一旦创建了绑定，就不能更改roleRef部分中附加的角色。

上述RoleBinding示例适用于需要允许开发团队成员访问应用程序配置中的Secret资源的情况，例如API密钥对和环境变量。

未来，如果您需要在整个集群中授予权限，您需要使用ClusterBinding资源。在下面的示例中，您将看到如何使用ClusterBinding来允许ops组中的任何用户读取集群中任何命名空间中的Pod资源。

在使用集群绑定的情况下，我们授予所有团队成员访问集群中所有 Pod 的权限。通过正确设置每个特定权限，组中的用户可以查看 Pod 并评估其状态，确保他们能够完成所需的报告和监控职责。同时，ClusterRole 的定义确保用户无法修改 Pod 或其中包含的应用程序。

确保K8s配置的安全性

基于角色的访问控制（RBAC）在符合最少特权原则方面可以发挥重要作用。幸运的是，Kubernetes本地的RBAC框架在这个领域提供了强大的功能。创建和绑定角色的能力非常强大，可以确保只有最小数量的用户对所需资源拥有必要的访问权限。这限制了资源暴露的潜在风险，同时不妨碍团队成员的正常工作。

声明：本文来自小佑科技，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。