Barbican/Discussion-Federated-Barbican
目录
此 wiki 页面正在进行中，旨在让贡献者思考如何实现联合 Barbican。
目前有需求让 Barbican 能够将私有云中的密钥联合到公有云中。
当前联合 Keystone
下图显示了当前联合 Keystone 与 Barbican 的工作方式。部署如下环境所需的一切，Barbican 和 Keystone 中都已经存在。
联合 Barbican
联合 Keystone 提供了对一些问题的良好解决方案。这些包括
- 扩展 Barbican
- 多个加密设备
- 工作负载分配
- 混合 Barbican
然而，仍然有一些限制需要解决。我认为最大的一个问题是令牌检索的自动化。
这个问题似乎并非我们独有。我想其他服务可能已经建立了一些管道或中间件，自动处理步骤 1-5。 这正是我目前正在研究的。
另一个问题是将密钥检索定向到正确的 barbican。
我自己、diazjf 和 edtubill 正在研究两个想法
1. 代理重定向
2. 加密驱动
我们还发现社区可能已经在开发一个相关的解决方案。在“相关文章”部分中，有两个项目似乎正在致力于自动联合多个云之间的资源。在“相关文章”部分中有更深入的解释。
代理
代理方案将所有联合 Keystone 的工作都卸载到代理服务器上。代理将处理 Keystone 到 Keystone 的联合，并将 Barbican 请求转发到正确的 Barbican 服务器。
可以通过 barbican.conf 文件中的变量控制插件。当“proxy_enabled”设置为 true，然后启动代理时。
仍然存在 2 个问题：1. 需要一种方法来确定是否应该转发请求。 2. 仍然需要一种方法来告诉代理请求需要转发到的 barbican 的位置。
第一个问题似乎并不严重。可以向客户端添加一个新的可选参数，例如：--federated，通知代理将请求转发到联合的 Barbican，而不是本地的 Barbican。我认为 -f 已经被客户端占用，所以标志需要是不同的。
第二个问题更具挑战性。代理需要知道将请求转发到哪里。 有几种方法可以解决这个问题
1. 存储用户有权访问的每个 barbican 的位置
- 这需要进一步完善，但基本思路是存储每个租户有权访问的 barbican。然后
代理可以处理所有授权，以便将请求转发到正确的 barbican。 存在一些特殊情况，例如如果客户部署多个云并可以访问多个 barbican。维护所有这些数据和处理重定向会变得更加复杂。
2. 轮询 IDP Keystone 以获取每个服务提供商的访问权限。
- 据我所知，您可以在身份提供程序（在本例中为 Keystone）上查看您有权访问的服务列表。
Keystone 可以提供用户有权访问的服务列表，在本例中包括所有用户可以联合的 barbican。然后代理可以检查所有可用的 barbican 以获取密钥，并在 put 操作上平均分配作业。
这些是我们一直在研究的两个可能的解决方案，但我非常希望听到其他人的想法和建议。
加密驱动
驱动程序几乎与代理完全相同。 唯一的区别在于，驱动程序位于加密设备之上，而不是位于 Barbican 之前。 因此，重定向和身份验证到联合 Keystone 在 API 调用已经开始通过 Barbican 管道过滤后发生。 基本上，代理功能将使用可以通过配置文件打开或关闭的驱动程序在 Barbican 本身处理。
相关文章
感谢 Steve Martinelli 传达了这些信息。波士顿大学似乎有一个小组正在从事类似的工作，例如设置在多个云之间联合访问，所有云都可以启动一个共享来自不同云的服务公共云。
看起来还有一个名为 Mercador 的项目，它是一个用于联合独立的 OpenStack 云的系统。
他们安排在 UTC 时间 1700 举行会议。 我会尝试参加这些会议，看看他们在做什么，并可能开始询问这如何帮助 Barbican。
评论
- arunkant- 关于流程的澄清：作为步骤 2 的结果，客户端将获得用于本地 Keystone 的 unscoped 令牌，然后将使用该令牌获得该本地云的 scoped 令牌。 然后客户端可以使用该 scoped 令牌直接进行通信到本地 Barbican。 我认为没有 Barbican 到 Barbican 的请求重定向（这更多是关于资源联合用例，该用例不受支持）。 谁能澄清一下？
- Silos - 我认为你是对的。 按照目前联合 Keystone 的实现方式，你首先需要获取令牌才能访问联合资源。 新图应该反映这一点。 然而，我认为这确实引发了一个问题。 在生产环境中，需要某种类型的自动化来告诉 barbican 哪些密钥在公共 barbican 中，哪些密钥在联合 barbican 中。 这样 barbicanclient 才能知道何时向公共 barbican 或联合 barbican 发出请求。 还有人认为这是一个问题吗？
- Diazjf - 正确，公共 Keystone 将充当 IdP（身份提供程序），私有 Keystone 将充当 SP（服务提供程序）。 然后用户必须使用 IdP 获得 SAML 断言，然后使用该断言生成 SP 的 unscoped 令牌。 然后必须对该令牌进行范围限定，然后才能对其执行操作。 这需要 K2K（Keystone-Keystone）联合。 如果设置了 2 个 Keystone 以使用相同的 IdP，则必须执行类似的过程。 我在这里的担忧是，用户需要在请求密钥之前知道密钥存储在哪里。 我建议对 Secret 对象添加一个标志来检查它是否是一个链接，并能够将链接包含到另一个位置的 Barbican 密钥中。 因此，无需执行特殊命令来存储/获取密钥。
