Glance-属性保护
这是蓝图 https://blueprints.launchpad.net/glance/+spec/api-v2-property-protection 的规范
我们将采用最小可行产品 (MVP) 的方法，看看能达到什么效果。
什么是“属性保护”？
Glance 中目前有两种类型的属性
- 属性（或“核心属性”）... 这些是定义在镜像模式中的属性
- 附加属性... 这些是可以添加到镜像上的任意键/值对
根据本提案，上述任何一种都可以通过为它们定义保护来成为“受保护的属性”。 当你对属性设置保护时，它限制了特定类别的用户可以对该属性执行 CRUD 操作。 没有定义保护的属性将像现在一样运行，即对核心属性进行管理员 CRUD 操作，对附加属性进行所有者 CRUD 操作。
如何指定属性保护？
最简单的方法是使用配置文件。 它可以如下所示
[mypropertyname] create: <role-list> read: <role-list> update: <role-list> delete: <role-list>
其中角色列表基于 policy.json
或者
[mypropertyname] <role-name>: <crud-list> <role-name>: <crud-list> <role-name>: <crud-list>
与其使用简单的属性名称，我们可能需要允许正则表达式规范，以防止属性欺骗（见下文）。
如何显示受保护的属性？
它们在镜像响应中看起来与现在完全一样，但根据你的权限，你可能根本看不到它们，例如，如果用户没有对属性的读取权限，则该属性不会出现在该用户的镜像详细信息响应中。
命名空间和属性保护
将没有显式的命名空间，非正式的“命名空间”将继续像现在一样，例如，“系统”属性将以类似于“org.openstack__1__”或“com.cloudprovider__1__”的内容为前缀。 缺点是，由于保护是基于名称的，如果镜像所有者有一个与受保护名称匹配的现有属性名称，则镜像所有者可能无法编辑他自己的属性。 另一方面，非正式的 javaesque 命名空间一开始的全部意义就是为了防止这种冲突，所以我们（好吧，反正是我）并不担心。
属性欺骗
使用非正式命名空间会引入恶意镜像所有者劫持提供商的“命名空间”并将镜像共享给其他用户的可能性。 例如，镜像所有者将一个类似于“com_rackspace_approved: True”的属性添加到镜像，使其看起来好像该镜像可以安全地启动，即使 Rackspace 没有这样的镜像属性。
可以通过几种方式解决这个问题 [1]。 目前的共识是我们可以使用基于正则表达式的策略。 基本思想是，担心此问题的提供商可以强制镜像所有者为他们想要添加到镜像上的附加属性使用非正式命名空间。 例如，如果配置文件具有“先匹配优先”策略，它可以按名称列出“受保护”属性，并对它们进行适当的 CRUD 限制，然后是/^owner_specified_.*/允许镜像所有者对它们执行所有 CRUD 操作，然后是/.*/拒绝镜像所有者所有 CRUD 操作。 这将有效地强制镜像所有者使用非正式命名空间前缀owner_specified_用于所有附加属性。
因此，与其将“com_rackspace_approved: True”添加到镜像，恶意所有者只能添加“owner_specified_com_rackspace_approved: True”，这不应该愚弄任何人。 该方案的一个优点是云提供商可以为此目的选择任意非正式命名空间并适当地教育用户。
以前的开放问题
- 应如何将具有保护的属性的名称传达给用户？
- 共识是应独立于 glance 完成此操作。 云提供商通过文档或其他适当方式向用户传达此信息。
- 保护是否应像策略一样起作用，即是否可以为每个节点独立存在，或者我们是否应强制在所有节点上保持一致性？
- 共识是属性保护应在所有节点上保持一致。 关键要点是每个节点上的配置文件存在不应限制属性保护的实施，例如，如果事实证明这是好的实施策略，则可以在数据库中完成保护。
未解决的问题
- 配置文件格式将是什么？
- 此方案是否适用于 nova 快照过程？ （Nova 从用户上下文中写入一些属性（例如“architecture”））。
- 是否可以通过允许镜像所有者 CR-- 这样的属性来处理？ 它们在 Nova 代码中被枚举，因此我们可以在配置文件中按名称指定它们。
