Congress
策略即服务(“国会”)
以下是一些包含关于国会详细信息的外部资源。
- 代码
如果您需要更多信息,请加入 freenode 的 #congress 频道,或联系 Tim Hinrichs (timothy.l.hinrichs@gmail.com)。
使命
国会是一个 OpenStack 项目,旨在为任何云服务集合提供策略即服务,从而为动态基础设施提供治理和合规性。
为什么需要国会
IT 服务始终会受到治理,并符合业务层面的策略。
过去,策略是手动执行的,例如,有人发送电子邮件要求将应用程序添加到网络,通过特定的防火墙条目进行保护,连接到约定的存储等。在云时代,IT 变得更加敏捷:用户期望立即交付服务,这是负责治理的团队无法企及的响应级别。因此,手动执行不再可行。
企业和供应商都推出了用于(半)自动执行策略的引擎,从而形成了一个碎片化的市场,企业在维护自己的代码的同时重新发明轮子,而供应商由于技术原因或其解决方案需要垂直集成和锁定而无法满足企业需求。
国会策略服务使 IT 服务可以通过 onboarding 新应用程序来扩展其 OpenStack 覆盖范围,同时保持自身业务策略所要求的强大合规性和治理。所有这些都利用社区驱动的实现,供应商可以插入到通用接口中。
什么是国会
国会旨在提供一个可扩展的开源框架,用于在任何云服务(例如,应用程序、网络、计算和存储)中实现治理和监管合规性,这些云服务都位于动态基础设施中。它是一种云服务,其唯一职责是策略执行。
国会旨在包含以下功能
- 允许云管理员和租户使用高级、通用、声明性语言来描述业务逻辑。策略语言不包含固定集合的策略类型或内置的执行机制;相反,策略只是定义了云的哪些状态符合合规性,哪些不符合合规性,其中云的状态是 Congress 可用的云服务提供的数据的集合。一些例子
- 应用程序 A 仅允许与应用程序 B 通信。
- 属于 B 组的租户 A 拥有的虚拟机应始终具有公共网络连接。
- 虚拟机 A 不应被配置到与存储 B 不同的地理区域。
- 提供一个可插拔的架构,该架构连接到任何云服务集合
- 执行策略
- 主动地:在违规发生之前防止违规
- 被动地:在违规发生后纠正违规
- 交互式地:让管理员了解策略及其违规行为,例如,识别违规行为、解释其原因、计算潜在的补救措施、模拟一系列更改。
策略语言
国会的策略语言是 Datalog,基本上是 SQL,但其语法更接近于传统的编程语言。之所以选择这种声明性语言,是因为其语义为广泛的 DevOps 领域所熟知,但其语法更简洁,更适合表达现实世界的策略。核心语法如下。
<policy> ::= <rule>*
<rule> ::= <atom> COLONMINUS <literal> (COMMA <literal>)*
<literal> ::= <atom>
<literal> ::= NOT <atom>
<atom> ::= TABLENAME LPAREN <term> (COMMA <term>)* RPAREN
<term> ::= INTEGER | FLOAT | STRING | VARIABLE
用例和示例
可以在此 google 文档中查看详细的用例:国会用例。请随时添加您希望国会支持的附加用例。
可以在此处查看已实现的国会策略示例:国会示例
已将一些已实现的策略打包到国会策略库中,以便于激活和使用:策略库
未来特性
以下是未来版本中会有用的功能列表。我们尚未对这些功能进行优先级排序或分配,因此,如果您是开发人员,认为这些功能很有趣,请告诉我们,我们可以详细说明。
- 基本策略语言实现
- 多线程 Datalog 实现
- 自底向上 datalog 评估
- 查询优化
- 物化实现:自动视图选择/内联
- 增强策略语言
- ActiveDirectory 接口
- 语法改进(插入/删除等模态)
- 对复合对象的支持(安全、分层递归)
- 更丰富的对 Enforcement 策略中动作的描述支持
- 模块
- 策略结构
- 多租户
- 多利益相关者(租户、财务、运营等)
- 执行
- 执行(丰富的)动作
- 雕刻子策略并推送到其他组件,例如 Neutron
- 将与国会的协商添加到其他 OS 组件,例如 Nova/Neutron
- 使用 Classification+Action 策略进行适当的补救枚举
- 找到自动选择适当补救策略的方法(例如,优先级/单调性)
- 让云所有者能够根据来自单独策略的信息配置如何主动/被动/等。
- 库
- 常见 OS 和非 OS 组件的数据源驱动程序
- HIPAA 等编码
- 不同行业的本体,例如金融
- 策略分析
- 通过 Enforcement 策略(使用 Action 策略)查找无限循环
- 比较访问控制策略和分类策略是否存在冗余
- 变更影响分析
- 仪表盘
- 策略 IDE(不同级别:原始 Datalog、AD、基于复选框)
- 列出违规行为
- 解释违规行为(通过策略逐步跟踪)
- 模拟状态更改和动作执行
- 枚举给定违规行为的补救措施
- 架构和 API
- 形式化并实现完整的内省和查询 API
- 跨多个节点分发
- 确保国会可以使用另一个国会实例作为数据
- 身份验证和访问控制
- 在 API/仪表板上添加身份验证和访问控制
- 在进行补救时,哪些用户正在执行操作?国会是否需要其所有云服务的管理员凭据,或者用户凭据是否是操作的一部分?需要适当的存储这些凭据。等等。
与其他项目的关系
相关的 OpenStack 组件
- Keystone:Keystone 是一种身份服务,为 OpenStack 提供身份验证和高级授权。国会可以将 Keystone 作为策略的输入。例如,审计员可能希望确保正在运行的系统与当前的 Keystone 授权决策一致。
- Heat:Heat 是一种用于应用程序配置和生命周期管理的编排服务。国会可以确保由 Heat 管理的应用程序与业务策略一致。
- Mistral:Mistral 是一种任务管理服务,或者换句话说,是一种工作流即服务。其主要用例包括云的 Cron、执行长期运行的任务以及大数据分析。国会可能利用 Mistral 来执行使云恢复到策略合规性的操作。
策略倡议
- SolverScheduler(Nova 蓝图):SolverScheduler 提供了一个接口,用于使用不同的约束求解器来解决 Nova 的放置问题。根据应用方式,可用于初始配置、重新平衡负载或两者兼而有之。
- Neutron 策略组:该组旨在为 Neutron 添加策略 API,租户在网络、端口等组之间表达策略,并强制执行该策略。策略语句的形式为“对于满足这些条件的 A 组和 B 组之间的每个网络流,对该流应用约束”。可以强制执行的流约束会随着执行引擎的成熟而增长;当前,约束是允许和拒绝,但计划添加服务质量约束。
- Open Attestation:该项目提供了一个用于验证主机完整性的 SDK。它提供了一些基于策略的管理功能,但文档有限。
- 基于策略的调度模块(Nova 蓝图):该工作旨在根据客户端、资源集群和上下文(例如,过载、时间等)调度 Nova 资源。在 OpenStack Juno 峰会的演示剧场中展示了一个概念验证。
- Tetris:该工作提供条件-动作策略(在某些条件下,执行这些动作)。它旨在成为一个通用的条件-动作引擎,处理复杂的动作和优化。这项工作吸收了 Nova 中的运行时策略蓝图。它似乎也吸收了 Neat 工作。Tetris 和国会最近决定合并,因为他们的目标和方法高度一致。
- 收敛引擎(Heat 规范):这项工作将 Heat 管理的对象的期望状态和观察到的状态分开。收敛引擎将检测期望状态和观察到的状态之间的差异,并采取措施消除这些差异。
- Swift 存储策略:Swift 存储策略描述了 Swift 使用物理设备实现虚拟存储系统。今天,每个策略都规定了存储系统有多少个分区,应维护每个对象的多少个副本,以及自上次移动分区以来必须经过的最小时间。
- Graffiti:Graffiti 旨在存储和查询 OpenStack 对象的(分层)元数据,例如,将 Glance 映像上安装的软件标记为该映像。目前,团队正在与其他 OpenStack 项目合作,为人们创建和查询元数据以及将元数据存储在项目数据库中添加用户界面。该项目是关于创建元数据,这对于编写业务策略可能很有用,而不是关于对该元数据的策略。
国会与所有这些努力互补。它旨在成为一个通用的策略组件,因此(潜在地)可以表达上述任何策略。但是,为了执行这些策略,国会将雕刻子策略并将其发送到云中的适当执行点。例如,国会可能会雕刻计算负载均衡策略并将其发送到运行时策略引擎,或者雕刻网络策略并将其发送到 Neutron 策略引擎。国会的目标之一是为管理员提供一个编写和检查整个数据中心或云中执行的策略的单一位置,将该策略的相关部分分发到所有可用的执行点,并监视云的状态,让管理员知道云是否符合合规性。(国会还尝试在发生策略违规时纠正违规行为,但上述许多策略的优化策略将不能由国会直接强制执行。)
[感谢 Jay Lau、Gokul Kandiraju 和邮件列表中的其他人帮助整理此列表。]
如何提出新功能
要提出新功能,您
- 创建一个 蓝图,描述您的功能及其工作方式。仅包括名称、标题和摘要。
- 要求至少一位核心审阅者提供反馈。如果该功能复杂或有争议,核心将要求您开发“规范”并将其添加到 congress-specs 仓库。规范是蓝图的代理,社区中的每个人都可以对其进行评论和帮助完善。如果 Launchpad(OpenStack 用于管理蓝图和错误的软件)允许社区向蓝图添加评论,我们就根本不需要规范。
- 一旦您的蓝图获得批准,您就可以将实现该蓝图的代码推送到 Gerrit,包括标签“Implements-blueprint:<blueprint-name>”
如果核心评审人要求提供规格文档,请按照以下步骤创建。
- 检出 congress-specs 仓库。
- 在当前发布文件夹中创建一个新文件,文件名类似于蓝图名称,例如 congress-specs/specs/kilo/your-spec-here.rst
- 使用 reStructuredText (RST) (一个 RST 教程) 通过填写 规格文档模板来描述您的新功能。
- 将您的更改推送到 congress-specs 仓库,该过程在 此处 有说明。
- 返回您的蓝图,并在蓝图详情的“Specification Location”字段中添加一个链接(例如 https://github.com/openstack/congress-specs/tree/master/specs/kilo/your-spec-here.rst)到您的规格文档。
- 通过 Gerrit 代码审查 参与您功能的讨论和完善。
- 最终,核心评审人将拒绝或批准您的规格文档。
- 如果规格文档获得批准,核心评审人将将其合并到仓库中并批准您的蓝图。
注意:如果您的蓝图在一个发布周期内未被批准或未实现,则必须在下一个周期重新提交。