[ English | 日本語 | Deutsch | Indonesia ]

用户管理

OpenStack Dashboard 提供了一个图形界面来管理用户。本节描述了使用 Dashboard 进行用户管理。

您还可以通过命令行客户端 管理项目、用户和角色。

此外，许多站点会编写自定义工具来满足本地需求，以实施本地策略并为用户提供当前打包工具无法提供的自助服务级别。

创建新用户

要创建用户，您需要以下信息

  • 用户名

  • 描述

  • 电子邮件地址

  • 密码

  • 主项目

  • 角色

  • 启用

用户名和电子邮件地址不言而喻，但您的站点可能有您应该遵守的本地约定。主项目只是用户关联的第一个项目，必须在创建用户之前存在。角色几乎总是“member”（成员）。开箱即用，OpenStack 包含两个定义的角色

member（成员）

一个典型用户

admin（管理员）

一个管理超级用户，拥有跨所有项目的完全权限，应谨慎使用

可以定义其他角色，但这样做并不常见。

收集到这些信息后，在仪表板中创建用户就像我们之前见过的另一个 Web 表单一样，可以通过单击 Users（用户） 链接在 Identity（身份） 导航栏中找到，然后单击右上角的 Create User（创建用户） 按钮。

用户修改也从这个 Users（用户） 页面完成。如果您有大量用户，此页面可能会变得非常拥挤。页面顶部的 Filter（筛选） 搜索框可用于限制用户列表。通过从用户修改行的末尾的动作下拉菜单中选择 Edit（编辑），可以弹出一个与用户创建对话框非常相似的表单。

将用户与项目关联

许多站点运行用户仅与一个项目关联。这对于管理和用户来说都是更保守和更简单的选择。从管理角度来看，如果用户报告实例或配额的问题，就显然与哪个项目相关。如果用户只在一个项目中，他们不必担心他们正在操作的项目。但是，请注意，默认情况下，任何用户都可以影响其项目中的其他用户的资源。如果这对于您的组织有意义，也可以将用户与多个项目关联。

从仪表板的 Projects（项目） 页面，通过从 Actions（操作） 列中选择 Manage Members（管理成员），可以将现有用户与附加项目关联或从旧项目删除，如下面的屏幕截图所示。

从这个视图中，您可以执行许多有用的操作，以及一些危险的操作。

此表单的第一列，名为 All Users（所有用户），包含云中所有尚未与此项目关联的用户列表。第二列显示了所有与之关联的用户。这些列表可能很长，但可以通过在列顶部的筛选字段中键入您正在查找的用户名子字符串来限制它们。

从这里，单击 + 图标将用户添加到项目。单击 - 以删除他们。

Edit Project Members tab

危险的可能性在于更改成员角色的能力。这是 Project Members（项目成员） 列表中的用户名下方的下拉列表。在绝大多数情况下，此值应设置为 Member（成员）。此示例有意显示了一个管理用户，其值为 admin。

警告

admin 是全局的，不是按项目划分的，因此在任何项目中授予用户 admin 角色都会赋予用户整个云的管理员权限。

典型的用法是在单个项目中创建管理用户，按照约定，是在云设置期间默认创建的 admin 项目。如果您的管理用户也使用云来启动和管理实例，强烈建议您为管理访问和正常操作使用单独的用户帐户，并将它们放在不同的项目中。

自定义授权

默认 authorization（授权） 设置仅允许管理用户代表不同的项目创建资源。OpenStack 处理两种授权策略

基于操作

策略指定对特定操作的访问标准，可能对特定属性进行细粒度控制。

基于资源

根据配置资源的权限，确定是否允许访问特定资源（当前仅适用于网络资源）。在 OpenStack 服务中实施的实际授权策略因部署而异。

策略引擎从 policy.json 文件中读取条目。此文件的实际位置因发行版而异：对于 nova，它通常位于 /etc/nova/policy.json。您可以在系统运行时更新条目，无需重新启动服务。当前，更新此类策略的唯一方法是编辑策略文件。

OpenStack 服务的策略引擎直接匹配策略。规则指示对这些策略的元素进行评估。例如，在 compute:create: "rule:admin_or_owner" 语句中，策略是 compute:create，规则是 admin_or_owner。

策略由 OpenStack 策略引擎在其中一个策略与 OpenStack API 操作或给定操作中使用的特定属性匹配时触发。例如，引擎每次将 POST /v2/{tenant_id}/servers 请求发送到 OpenStack Compute API 服务器时，都会测试 create:compute 策略。策略也可以与特定的 API extensions（API 扩展） 相关联。例如，如果用户需要像 compute_extension:rescue 这样的扩展，则提供程序扩展定义的属性会触发该操作的规则测试。

授权策略可以由一个或多个规则组成。如果指定了多个规则，则评估策略成功，如果任何规则成功评估；如果 API 操作匹配多个策略，则所有策略都必须成功评估。此外，授权规则是递归的。匹配规则后，规则可以解析为另一个规则，直到达到终端规则。这些是定义的规则

基于角色的规则

如果提交请求的用户具有指定的角色，则成功评估。例如，"role:admin" 如果提交请求的用户是管理员，则成功。

基于字段的规则

如果当前请求中指定的资源的字段与特定值匹配，则成功评估。例如，"field:networks:shared=True" 如果网络资源的 shared 属性设置为 true，则成功。

通用规则

将资源中的属性与从用户安全凭据中提取的属性进行比较，如果比较成功，则成功评估。例如，"tenant_id:%(tenant_id)s" 如果资源中的租户标识符等于提交请求的用户的租户标识符，则成功。

以下是默认 nova policy.json 文件的摘录

{
   "context_is_admin":  "role:admin",
   "admin_or_owner":  "is_admin:True", "project_id:%(project_id)s",
   "default": "rule:admin_or_owner",
   "compute:create": "",
   "compute:create:attach_network": "",
   "compute:create:attach_volume": "",
   "compute:get_all": "",
   "admin_api": "is_admin:True",
   "compute_extension:accounts": "rule:admin_api",
   "compute_extension:admin_actions": "rule:admin_api",
   "compute_extension:admin_actions:pause": "rule:admin_or_owner",
   "compute_extension:admin_actions:unpause": "rule:admin_or_owner",
   "compute_extension:admin_actions:migrate": "rule:admin_api",
   "compute_extension:aggregates": "rule:admin_api",
   "compute_extension:certificates": "",
   "compute_extension:flavorextraspecs": "",
   "compute_extension:flavormanage": "rule:admin_api",
}

  1. admin_or_owner 显示一个规则，如果当前用户是管理员或请求中指定的资源的拥有者（租户标识符相等），则成功评估。

  2. default 显示默认策略，如果 API 操作不匹配 policy.json 中的任何策略，则始终评估。

  3. compute_extension:flavormanage 显示一个策略，限制仅使用 Admin API 的管理员才能操作 flavors。

在某些情况下，应将某些操作限制为仅管理员。因此，作为进一步的示例，让我们考虑如何修改此示例策略文件，以启用用户创建自己的 flavors 的场景

{
  "compute_extension:flavormanage": ""
}

扰乱其他用户的用户

您的云中的用户可能会扰乱其他用户，有时是故意且恶意地，有时是意外地。了解情况可以帮助您做出更好的处理中断的决定。

例如，一组用户拥有正在利用大量计算资源进行非常密集的计算任务的实例。这正在提高计算节点上的负载并影响其他用户。在这种情况下，请查看您的用户用例。您可能会发现高计算场景很常见，然后应该为您的云规划适当的隔离，例如主机聚合或区域。

另一个示例是用户消耗了大量的带宽。同样，关键是了解用户在做什么。如果她自然需要大量的带宽，您可能需要限制她的传输速率，以免影响其他用户，或者将她移动到具有更多可用带宽的区域。另一方面，也许她的实例已被入侵，并且是发起 DDoS 攻击的僵尸网络的一部分。解决此问题的办法与网络上的任何其他服务器被入侵的办法相同。联系用户并给她时间回复。如果她没有回复，请关闭该实例。

最后一个示例是，如果用户反复轰炸云资源。联系用户并了解他试图做什么。也许他不明白他所做的事情是不合适的，或者他正在访问的资源存在问题，导致他的请求排队或滞后。