跳转到： 导航, 搜索

Keystone 边缘架构

此页面包含关于温哥华论坛讨论该主题的摘要。讨论的完整记录在 此处。边缘云基础设施的特性和需求在 OpenStack_Edge_Discussions_Dublin_PTG 中有描述。

需要解决的问题

易用性

  • 某些数据可能在本地修改，并且在更改时必须持久保存

功能性

  • 可能存在长时间没有连接的情况，所有功能（例如，自动伸缩）都必须继续运行

安全

  • 某些数据不应该同步到某些站点，如果站点受到损害，它应该只保存相关的本地数据
  • 需要一个集中的“视图”来同步边缘云的状态，以便进行审计/合规性检查
  • 需要集中式管理（某种形式）。

可扩展性

  • 边缘站点可能硬件资源非常有限（例如，可能是单节点基础设施）

架构选项

身份提供者 (IdP) 主节点与影子用户

挑战： 将用户、项目和角色分配从中央事实源同步到所有集群，作为管理 OpenStack 的众多部署中的身份验证的一部分。

解决方案： 与身份提供者主节点联合。

Oath 的当前实现


柏林 OpenStack 峰会回顾，包含相关信息


详细信息： 用户、角色和项目之间的映射在身份提供者 (IdP) 中管理，该提供者将向用户呈现一个带有签名的令牌，声明他们的用户名、项目和 Keystone 角色映射。此签名令牌作为身份验证凭据传递给 Keystone，如果它们尚不存在，Keystone 将创建用户、项目和角色映射。

未解决的问题

  • 是否有 IdP 支持上述场景并返回 Keystone 所需信息的令牌？
  • 如何处理具有不同配置的站点，例如 Jane 允许在站点 A 上执行某些操作，但在站点 B 上不允许？
  • 当 IdP 与边缘站点之间的连接中断时，如何处理？例如：过期的 Keystone 令牌和/或 CLI。


下图显示了“管理员”如何创建用户“Jane”，她作为项目“Foo”的“成员”。在通过 IdP 身份验证后，Jane 随后收到一个带有其身份和授权声明的签名令牌

Edge Keystone IdP Master.png

第二张图显示了用户从 IdP 获取签名令牌，并在请求 Keystone 令牌时将其传递给 Keystone。Keystone 验证请求，如果需要，将用户“Jane”添加到数据库，然后返回令牌。Jane 现在可以使用该令牌调用其他 OpenStack 服务。

Keystone Fed ext IdP 2.png

这种联合风格消除了部署者主动将用户、项目和角色分配同步到其他集群中的 Keystone 实例的需要，从而大大降低了操作复杂性。

多个 Keystone 实例与联合和 API 同步

每个边缘云实例运行自己的 Keystone 实例。这些 Keystone 实例是联合的，其中每个 Keystone 节点都是一个“服务提供者”，接受并验证来自受信任身份提供者的 SAML 断言（这与 k2k 联合不同）。每个 Keystone 维护一个映射以控制访问权限，具体取决于谁需要什么（这将是大量的映射，因为每个部署可能有多个）。
基本流程

  1. 用户呈现 SAML 断言以证明其身份
  2. 映射处理其属性，创建影子用户等。
  3. 然后用户使用其影子用户创建应用程序凭据
  4. 用户使用其应用程序凭据生成令牌来使用特定的 Keystone 部署


更多信息

分析

  • 优点
    • Keystone 已经支持联合
  • 缺点
    • 客户端与 IdP 或客户端与边缘云实例之间的连接中断会导致身份验证问题
    • 需要维护大量的映射规则，但它们可以是静态的

问题

  • VIO 中的 Keystone 可以作为 K2K 联合的身份提供者吗？
  • 除了 Keystone 联合中已有的内容之外，我们是否需要进一步同步数据？
    • 有些数据，例如用户或项目，需要分发
      • 可以使用映射规则或 Keystone 中的逻辑显式创建缺失的数据（在后一种情况下，还需要逻辑来删除不再需要的数据）
  • 如何处理 IdP 被隔离的情况？
    • 我们的集群几乎不需要直接与 IdP 通信。用户调用 IdP 获取身份验证令牌，并将该身份验证令牌传递给相关集群。将这种类型的联合视为“隐藏主节点”，每个 Keystone 在被用户调用时都能够完全独立地运行。集群内的服务用户不需要调用 IdP，因为它们可以本地进行身份验证。

Keystone 数据库复制与分布式数据库

每个边缘云实例运行自己的 Keystone 实例。这些实例的数据库通过数据库的标准复制机制同步，并且数据在边缘云实例之间同步。

相关资料

分析

  • 意见：不应使用此替代方案
  • 优点
  • 缺点
    • 分布式数据库存在局限性，例如 Galera 只能同步 16 个数据库
    • 不支持边缘云实例的滚动升级

Keystone 数据库复制与同步服务

每个边缘云实例运行自己的 Keystone。每个边缘云实例上都有一个同步代理，可以读取和写入 Keystone 数据库。同步代理从主 Keystone 的数据库读取选定的数据，并将其同步到从节点。Fernet 密钥同步以实现任何地方生成 - 任何地方使用的操作。在分区结束之后，Fernet 密钥应该被删除并重新同步。请注意 - 重新同步的集群将自动使所有令牌“失效”。令牌不会保存在数据库中，更新密钥存储库可能会导致过早的令牌失效（因为用于加密令牌负载的密钥由于更新而消失）。有一个 规范 提出使用异步签名而不是同步加密，这可能会对密钥管理产生影响（因为您只同步公钥而不是私钥或共享密钥）。

相关资料

分析

  • 优点
  • 缺点
    • 同步代理需要了解 Keystone 数据库结构的细节
    • 写入数据并保持一致性可能并不容易

分布式 LDAP 数据库作为 Keystone 后端

边缘云实例中的 Keystone 使用 LDAP 数据库作为后端，并且 LDAP 配置为同步数据。</br> LDAP 只能设置为身份验证领域，Keystone RDB 将提供身份服务数据库。但是，Keystone 还可以处理身份验证和身份服务，这将意味着在此场景中不需要 Keystone 关系数据库。

相关资料

分析

  • 优点
    • LDAP 同步是一个已解决的问题
  • 缺点
    • 这不是同步大量站点的正确工具

问题

  • 是否可以以这种方式存储和同步所有 Keystone 相关数据？

每个边缘的隔离域和在隔离域内更改数据的本地权限

  • “Spoke/Hub 模型”
  • “本地数据库用于本地“数据”和待写入”
  • 本地数据在连接恢复后发送到中央枢纽
  • 站点对其域具有权威性，其他“远程”域不具有权威性
  • 中央枢纽具有写入任何域的权威性
  • “代码/服务”编写用于打包本地更改并将其运送到中央进行分发/同步，并在恢复连接时（如果恢复连接）
    • 必须允许它执行常规 Keystone-API 工作无法执行的操作（使用特定 UUID 在数据库中创建项目）

分析

  • 优点
  • 缺点

Keystone API 同步和 Fernet 密钥同步

  • 每个边缘云实例运行自己的 Keystone 实例，
  • Keystone 资源从中央站点同步到边缘云，使用基于 API 的同步，
    • 例如，项目、用户、组、域……
  • 还支持 Fernet 密钥同步和管理，以便在任何边缘/中央云中创建的令牌可以在任何其他云中使用（并进行身份验证）。
  • (注意：只有当可以更改 Keystone API 以同步用户 ID 和项目 ID 时，才有可能实现此选项)
    • Fernet 令牌包含 userId 和 projectId，因此必须在所有云中同步这些信息，
    • 以前尝试将其上游到 Keystone 均未成功 ==> 这很可能排除了此选项。

分析

  • 优点
  • 缺点

复制的数据

这是 StarlingX 同步的数据列表

  • Keystone
    • 用户
    • 项目
    • 角色
    • 分配
    • 组（尚未实现）
    • 域（尚未实现）
    • Fernet 密钥（尚未实现）
  • Nova
    • 规格
    • Flavor extra specs
    • Keypairs
    • Quotas（应该在边缘云基础设施级别动态管理，例如，配额为 10 个实例的项目，只能在所有边缘云中创建 10 个实例；而不是每个边缘云 10 个实例。）
  • Neutron
    • 安全组
    • Security Group Rules
  • Cinder
    • 配额

相关链接

从 "https://wiki.openstack.org/w/index.php?title=Keystone_edge_architectures&oldid=166963" 检索