存储元数据以允许使用每个 secret 的策略

https://blueprints.launchpad.net/barbican/+spec/add-per-secret-policy

这是一个在 Barbican 中添加每个 secret 特定策略的提案，以增强 policy.json 中基于通用操作的策略。 想法是存储有助于确定是否可以访问 secret 或 container 的属性（例如，用户 include_list），每个 secret 对应一个。

Oslo policy 允许您访问这些属性，并将它们作为 target.* 属性的字典传递给 RBAC 规则引擎，并在策略执行中使用。

问题描述

最近，Neutron LBaaS 试图弄清楚如何授予 LBaaS 系统用户检索 secret（cert containers 和 secrets）的能力，以便创建负载均衡器配置。 最终确定的解决方案是 trusts（信任）。 也就是说，为相关项目 ID，在 keystone 服务器上为 LBaaS 用户创建了一个 trust。

虽然这种机制有效，但 trust 过于重。 基本上，它允许 LBaaS 用户在 trust 有效期间（可能永远有效）冒充相关项目的用户。 如果 LBaaS 用户被劫持，他们不仅可以访问所有 Barbican 数据，还可以以该用户的身份与所有其他服务交互。

事实上，随着越来越多的项目与 Barbican 集成，服务用户获取 barbican secrets 的需求将会再次出现。 仅仅为了执行像检索 secret 这样基本的操作，就在各个服务中传播 trust 似乎是一个灾难的配方。

此外，最近有要求能够指定某些 secret 是私有的。 也就是说，只有 secret 创建者（创建 secret 的用户）才能提取它们。 现在，有人可能会认为可以为每个用户创建一个项目——但这似乎是一个非常繁琐的解决方案。

这两个问题（也许还有其他问题）都可以通过使用每个 secret 的访问属性来进一步细化与 secret 关联的策略来解决。 在策略术语中，这是使用目标（在这种情况下，secret 或 container）的属性来进一步细化策略。

例如，Keystone 中就做了这样的事情。 请参阅 https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json 中的规则，它们引用了 target。 这些值在 keystone/common/controller.py（在 protected() 的定义中）中填充。

为了更清楚地说明，我将把这个第二个问题（“私有 secret”）的解决方案分成一个单独的后续 spec。

提议的变更

这个 spec 仅处理 LBaaS 提出的问题。 该问题是：如何允许一个不属于 secret 项目的用户访问 secret。

该提案是为每个 secret 或 container 存储访问控制数据，这些数据可用于根据资源基础对检索现有策略进行补充。

可以将此功能分解为四个子问题

1. 拟议的 ACL 将涵盖哪些操作，以及每个操作的默认策略是什么？ 请参阅下面的“操作”部分。

2. 客户端在设置 secret 或 container 的 ACL 时将什么数据发送到服务器？ 请参阅下面的“REST API”部分。

3. 此 ACL 信息如何在数据库中存储？ 请参阅下面的“数据库”部分。

4. 如何提取此数据并将其呈现给 Oslo 层以进行 RBAC 强制执行？ 请参阅下面的“策略”部分。

操作

这里的 ACL 权限对应于项目创建者之外的某个用户可以对 secret 或 container 执行的操作。 这些操作包括

get: 对于 secret，具有“get”权限的人将能够检索

secret 元数据和 payload。 对于 container，他们将能够检索 container（基本上是所有元数据）。 访问 container 中引用的 secret 将需要每个 secret 上的“get”权限。 对于“Kilo”，对 container 的 get 权限不会自动级联到 secret。 这是 K 中唯一要实现的操作。

delete: 删除 secret 或 container 的能力。 当前，此权限

仅限于 secret 项目中的特定角色（“创建者”？）。 对于 Kilo，这将不会改变。 特别是，不清楚我们是否希望项目外部的任何人能够删除 secret 或 container。

write: 修改项目/container 的能力。 当前，typed containers 和

secrets 是不可变的。 即使它们不是不可变的，也不清楚来自不同项目的人是否应该能够修改 secret/container。 这不会在 K 中实现。

change-acl: 更改 secret 的 ACL 的能力。 对于 K，这将是

限制为 secret/container 的创建者（即创建 secret/container 的用户）。

REST API 影响

• 将添加一个新参数（“acl”）到 secret 和 container 的 POST 请求中。 此字段中的数据格式如下

  {
      "get": {
              "users": ["some_user_id",
                        "another_user_id"],
             }
  }
  

  这些字段中的数据将直接放置在下面的 ContainerACL 和 SecretACL 表中。

  有人讨论过向 acl 添加白名单组和项目的参数。 这需要进一步讨论，因为组未在 keystone token 中指定，并且角色也应在项目内定义。 由于目前不需要这些参数，我们将推迟添加它们到 L+。

• 此外，将提供一个新的端点，以允许用户更改 secret 或 container 上的 ACL

  POST <host>/v1/secrets/<secret-UUID>/acl
  

  其中 body 将是与上述相同的格式的 ACL。 此端点将默认限制为 uid == <uid of creator>。

• ACL 数据默认情况下不会随 GET 请求返回。 相反，将提供一个新的路由来检索 ACL

  GET /secrets/<secret_uuid>/acl

  这将返回如上所示的 ACL。 此端点将限制为 uid: <creator>。

• 创建订单时，Barbican 服务器需要跟踪订单的创建者，以确保订单的创建者具有访问 secret 的权限。

  例如，在使用存储密钥机制生成证书时，异步 worker 需要访问 container 和 container 中引用的私钥。 只有当订单的创建者具有对相关资源的访问权限时，才应允许这样做。

数据模型影响

对于 secret 和 container，我们需要添加一列来存储 secret 的创建者。 这将由创建者的 user_id 填充。 考虑到我们计划删除 secret/project 表，存储创建者的 project_id 也可能很有用。

我们还需要添加一列来存储 Order 的创建者，以便在处理 Order 时生成的任何 secret/container 都会被标记为它们的创建者。

我们还需要创建两个新表：ContainerACL 和 SecretACL，用于存储 ACL 数据。 SecretACL 表的字段如下

secret_id: Secrets 表的外键 action: 当前，只有“read”将被实现 users: 字符串，指定操作的白名单用户列表

在 L+ 中，我们可能会决定添加列以允许白名单组或项目。 现在，仅白名单用户。

策略

访问 container 或 secret 时，ACL 数据将从数据库检索，并作为 target.* 属性提供给 RBAC 层。 例如，对于获取 secret，我们可以传入 target.user_whitelist。

策略规则将如下所示

(can_read_shared and user_in_user_whitelist) OR current_resource_permissions

current_resource_permissions 部分基本上是用户在 secret 创建者的项目中具有相关角色。

我们可能需要扩展（并上游）oslo-policy 以允许处理列表。

备选方案

我们可以使用 trusts，但是如前所述，它们过于重。 总而言之，这是 Barbican 中简单地需要的。

安全影响

这通过消除 trust 的要求，而是提供细粒度的每个 secret 权限，从而提高了整个堆栈的安全性。

通知与审计影响

无。

其他最终用户影响

python-barbicanclient 需要更新以提供一个界面来填充额外的参数。

性能影响

访问 secret/container 需要两个数据库调用：一个用于获取 secret/container include)list 作为 RBAC 引擎的规则执行的一部分，另一个用于实际获取 secret/container。

其他部署者影响

Neutron 和其他服务用户将访问 Barbican 中的 secret，可以使用新机制，而不是 trust。

开发人员影响

Neutron 代码可能需要进行更改才能利用此机制。 当前使用 trust 的机制仍然有效。

实现

负责人

主要负责人

alee rm_work

工作项

• 向数据库表和 REST API 添加新字段。

• 添加逻辑，通过 REST API 或通过 Orders 创建的 secret/container 标记其创建者。

• 添加逻辑，从数据库检索 ACL 数据并将其作为 target.* 属性提供给 RBAC 层。

• 根据这些 target.* 属性修改策略规则。 在这里，可能需要扩展 oslo policy 以正确处理列表。

• 修改 neutron 代码/barbican 客户端以利用此新机制。

依赖项

无

测试

当前的单元测试也将被修改以反映此更改。

文档影响

Neutron 和 Barbican 文档需要更改。

参考资料

• 显示 Neutron LBaaS 详细流程的图表。 http://goo.gl/Wc8oIj

• 具有类似想法的早期蓝图。 https://blueprints.launchpad.net/barbican/+spec/secret-isolation-at-user-level