思考CloudOps中的访问控制模型

今天，每个应用程序都带有某种安全模型。然而，当我们用许多这样的应用程序开发我们的软件时，整个模型变成了所有这些不同模型的大杂烩。有时，它不是用目标应用程序所需的机器、人和对象抽象来建模的。这可能导致安全漏洞。让我们看看可能发生这种情况的一些情况。

场景一

您刚刚使用运行在Amazon AWS上的Kubernetes部署了全新的shining应用程序。您已经设置了同类中最好的CI/CD管道，以确保当新版本准备部署时，可以自动测试它，以确保没有引入回归问题，并且可以以最小的努力进行部署。由于安全性是您的第一优先级，您已经确保它只能从超级安全的跳转主机访问，该主机只能在连接到公司VPN并使用您保护的密钥时访问。
第二天出现了性能问题，开发人员要求收集一些信息，您很乐意提供这些信息。但在接下来的几天里，这样的请求增加到了压倒性的水平。您不情愿地让您的一些团队成员根据需要访问您的密钥。但是现在，你不知道谁在什么时候访问了系统并采取了什么行动。
管理员必须能够审核生产集群上的每一个操作。

场景二

您已经在Amazon AWS上设置了RBAC，因此可以控制谁可以访问您的VPC、实例和其他AWS资源。然后，您需要控制谁可以访问Kubernetes中的pods和部署，因此还需要在Kubernetes上设置RBAC。类似地，每个云应用程序（如Confluent Kafka、MongoDB或Mysql）都有其访问控制风格，它们都以不同的方式工作。现在，当您需要授予某人一些访问权限时，您可能需要与所有这些访问控制系统打交道。即使在这之后，也没有集中的审计线索告诉你谁在系统中做了什么。
管理生产应用的差异化访问需要统一的安全模型和集中控制。

场景三

最后，您设法按照您的规范配置了所有的访问控制模型。您有一个远程团队在夜间处理服务调用。通常，他们不需要在生产环境中访问Kafka的内部，所以他们不能访问它，但是昨天发现了一个bug，要求他们访问一个主题来解决客户问题。您希望能够在处理调用和记录远程团队采取的所有操作所需的时间内授予他们访问权限，但目前还不存在这样的机制。
具有审计功能的实时、基于属性的访问控制是远程优先团队所必需的。这有助于每个人在保持ops团队控制的同时提高生产力。

不幸的是，像上面这样的场景比它们需要的要常见得多。其根本原因是当今可用的访问控制机制要么是：
此外，由于分散在不同的应用程序中，他们没有全局系统视图来为操作员提供完整的审计跟踪，以通知他们谁在不同的应用程序中在他们的系统中采取了什么操作。

解决方案

当我们开始研究Maira时，访问控制必须作为核心能力进行架构和实现。由于Maira平台集成了客户可能使用的所有云应用程序，我们希望构建一个系统，可以控制对系统所有部分的访问，并跟踪谁在什么时间访问了什么。它必须具有非常细粒度的控制级别，以授予对特定资源上的各种操作的访问权，同时易于配置。它应该有基于时间和基于位置的控制。也应该很容易看出谁可以访问什么资源。下图显示了访问控制和审计是Maira平台不可分割的一部分。
Maira为自动化和手动访问提供了一个集成的环境。这使它成为一个自然的安全策略执行点和所有活动的记录保存人。

访问控制技术

我们研究了实现这一点的各种技术。最常见的技术有基于角色的访问控制(RBAC)、基于属性的访问控制(ABAC)、基于策略的访问控制(PBAC)或下一代访问控制(NGAC)。这些技术的详细比较见[1]。
RBAC模型为用户分配角色，然后为这些角色授予权限。但是，随着对越来越细粒度访问的需求的出现，角色的数量激增，并变得难以大规模管理。
ABAC模型为用户和对象分配属性，并且可以将权限授予这些属性的任何组合。这种方法的问题是实现和配置都更加复杂。在这个模型中，也很难确定谁可以访问哪些对象。例如。如果您想列出用户Bob可以执行的所有操作和所有资源，这可能非常困难甚至不可能。
PBAC是对ABAC的迭代，其中权限是在包含所有用户和资源属性的策略中定义的。它仍然遭受与ABAC相关的问题。
NGAC是由国家标准与技术研究所(NIST)定义的标准。它试图通过定义资源/资源组与对象/对象组之间的关系来解决与ABAC复杂性相关的问题。然后，在这些组之间定义访问策略。关于NGAC的介绍见[2]，关于它的介绍见[3]。

Maira对象模型

在Maira对象模型中，用户属于角色(admin/member)，角色属于组。类似地，对象属于对象类型，对象类型属于服务实例和服务类型。这些节点之间的边定义了用户可以访问的内容，边上的标签定义了用户可以执行的操作。所有权限都是分层的，因此用户可以访问其角色、组或整个团队的所有资源。
对于站点或位置有一个单独的“维度”。每个用户属于一个站点，并且用户可以访问连接到该站点的所有资源。
每个策略还有一个时间组件，在这个时间组件上该策略将生效。因此，可以授予对特定时间段的访问权限。

实施

执行这些政策可能是一项非常具有挑战性的任务。我们使用工业标准Open Policy Agent[4]，它被许多受人尊敬的公司用于其访问控制实现。它允许我们用声明性语言定义策略，并实时处理策略，以确定是否应该允许用户的特定操作。

在Maira云上配置访问控制策略规则

通常，最终用户使用CLI和具有层次结构（如pods/<namespace>/<pod-name>)和组织结构（如kafka用户组等）的对象。如果访问控制也不是基于相同的访问控制，它就不能通过简单性测试。在Maira中，可以定义策略规则，将用户、角色或组连接到该层次结构中的资源实例、资源类型、服务实例或服务类型。这使得您可以轻松地从非常精细的级别定义策略到非常粗略的级别。下面是显示这个过程的截图。

结论

我们可以看到，拥有适当的访问控制对于在分布式环境中进行有效的操作至关重要。不充分、难以配置或分散的访问控制将导致只有少数人能够访问系统的任何部分，最终，它将导致倦怠。使用Maira，您可以在一个地方以简单易懂的方式为整个云操作、跨不同环境和多个不同应用程序配置访问控制。