OpenStack项目用户角色关系详解：从授权模型到生产实践

做OpenStack这套东西，最绕不开也最容易被新手绕晕的就是项目（Project）、用户（User）、角色（Role）这三者的关系。很多刚接触OpenStack的人，看完官方文档里那句“用户属于项目，角色定义了用户在项目中的权限”之后，依然一脸茫然——好像懂了，一上手配权限就乱套。这篇东西我就用实际干活的经验，把这层关系彻底掰开揉碎讲清楚，顺便把那些文档里不写、但你在生产环境一定会踩的坑也一并说了。

1. 三个概念的真实定义：别再拿“组”和“权限组”去套

先把这个最核心的认知误区掰过来。很多人习惯拿Windows或者传统Linux里的“用户组”概念去理解OpenStack的项目，结果做出来的权限模型一塌糊涂。Three者之间的本质区别，其实从OpenStack的源头设计里就能看明白。

1.1 项目（Project）不是用户组，是“资源隔离边界”

Project在OpenStack里最准确的理解是“资源的集合与隔离边界”。在Nova里叫“项目”或“租户”（Tenant），在Cinder、Neutron里也都以项目作为资源归属的基本单位。你创建的所有云主机、卷、网络、子网、安全组、镜像，以及Swift里的容器，都必须归属于且只能归属于某一个Project。

一个Project内部有独立的配额体系（Quota），比如能创建多少个实例、多少核CPU、多少GB内存、多少块卷。项目与项目之间默认是二层网络隔离的（通过VLAN、VXLAN等网络技术实现），资源不能跨项目互相可见。这就是“隔离边界”的物理含义。

举个例子：你在Project A里创建了一台云主机，它的网卡接在Project A的虚拟网络上。Project B里的云主机，哪怕和你在同一台物理计算节点上，也完全感知不到它的存在。从网络层面、存储层面、资源配额层面，Project之间都是独立的。

1.2 用户（User）就是“自然人”，与项目没有必然绑定关系

User这个概念的定位就简单得多，它就是一个个独立的登录身份，对应一个真实的人、一个服务账号、或者一个API调用的主体。一个User可以拥有全局层面的属性，比如用户名、密码、邮箱、是否启用等。

关键点在于：User本身不直接拥有任何OpenStack资源，它必须“进入”到某个Project里，才能真正干活。这就好比一个人（User）进了一个公司（Project）才能拿到工位、电脑和业务资源；但这个人本身可以是多个公司的员工——在OpenStack里，一个User可以同时属于多个Project，而且在每个Project里的权限可以完全不同。

我见过不少从传统IT运维转过来的人，喜欢把User当成“员工账号”、把Project当成“部门”，然后问“那我是不是该给每个部门建一个单独的用户组？”——不是的。OpenStack没有独立的“用户组”概念（虽然Keystone后来加入了Group，但那是为了批量授权，它的定位也变了，后面我会单独讲），权限的载体是“用户在某个项目里被赋予了什么角色”，不是“用户属于哪个组”。

1.3 角色（Role）是“授权令牌”，决定的是“能干什么”

Role是三者中最容易理解但也最容易配置出错的一个。它的定义非常直白：一个角色代表一组权限的集合。当把一个User关联到一个Project，再给这个关联关系赋予一个或多个Role时，这个User在这个Project内部就拥有了对应角色所定义的权限。

OpenStack默认提供了两个内置角色：admin和member（旧版本还有_member_，带下划线，版本迭代中逐渐被member替代）。但需要注意的是，这两个角色在不同服务里的含义是有差异的：

• admin：在Keystone层面，admin角色可以管理用户、项目和角色本身（取决于policy.json的配置）；在Nova里，admin角色的用户可以查看所有租户的云主机、执行迁移、关机等管理操作。
• member：这是一个比较标准的“业务操作员”角色，在Nova里可以创建、删除自己的云主机，在Neutron里可以管理自己的网络，在Swift里可以操作自己容器里的对象。

真正让你在配置时需要用到的角色，往往不只是这两个。比如Horizon里有个heat_stack_owner角色，FWAAS有个fwaas_admin，heat还有个heat_stack_user。如果创建一个用户并赋予它在某个项目里创建编排栈的权限，却忘了加heat_stack_owner，这个用户会在Horizon里点击“创建堆栈”时被干脆利落地拒绝。

1.4 为什么这个铁三角关系容易搞混

搞混的根源在于，OpenStack的授权模型并不是“用户–角色–项目”的三元组，而是**“用户–项目”的二元关联 + “角色”对这个关联的修饰**。官方文档管这个叫**“赋值”（Assignment）**——即“用户X在项目Y中被赋予了角色Z”。

这个设计是Keystone的重中之重。你不需要先定义“用户属于哪些项目”，也不需要先问“这个项目有哪些角色”，你需要先理解OpenStack的数据模型：一个User对应多个Assignment，一个Project也对应多个Assignment，每个Assignment绑定一个或一组Role。真正生效的权限是Assignment里Role的组合。

在这种模型下，“一个用户属于多个项目”就不再是一个需要特殊处理的例外情况，而是模型的原生能力。

2. 项目、用户、角色怎么串起来：一次完整的授权链路拆解

理论说完了，我从实际操作侧把这个模型如何运转到底层讲透。这样遇到权限问题你才能从数据流的角度去排查，而不是猜。

2.1 Keystone里的一条核心链路：Token → Project → Role

以OpenStack最常见的认证流程为例。用户使用openstack login或者直接用API发一个认证请求时，实际上是在做一次租户选择：

bash复制openstack --os-project-name myproject --os-username alice --os-password xxx token issue

这一步发生的事，是向Keystone请求一个Scoped Token（绑定到myproject这个项目的作用域令牌）。Keystone收到这个请求后，会在它的三张核心表（user表、project表、assignment表）里做一次联合查询：alice这个用户在myproject这个项目里有哪些角色？如果查询结果为空，比如这个用户压根不在这项目里，Keystone会直接返回一个HTTP 401 Unauthorized。

如果找到了角色，Keystone就把这些角色信息打包进Token里。之后这个用户拿着这个Token去请求Nova、Neutron、Cinder的API时，各服务会从Token里提取出项目ID和角色列表，然后基于各自的policy规则来决定放不放行。

2.2 Policy规则决定角色能做什么

这里必须讲到policy.json（新版本是policy.yaml），因为角色本身不直接决定权限，它是被各服务的policy规则引用的。比如在Nova的policy.yaml里，你经常会看到这样的规则：

yaml复制"os_compute_api:servers:start":
  - "rule:admin_or_owner"
"os_compute_api:servers:stop":
  - "rule:admin_or_owner"

而admin_or_owner这个规则的定义一般是：

yaml复制"admin_or_owner":
  - "role:admin"
  - "project_id:%(project_id)s"

看到没有？admin_or_owner的含义是：如果请求者的Token里有admin角色，或者Token里携带的project_id正好等于资源所属的project_id，就放行。所以一个用户在Project里拥有member角色，就意味着他操作自己项目里的资源是匹配project_id:%(project_id)s这个条件的，因此被允许。

这就是为什么“同一个人在不同项目里权限不同”在OpenStack里是天经地义的：他在项目A里是member，在项目B里可能只有只读权限，甚至只是被加进了项目但没给任何角色，这种情况下他连项目B里的列表都拉不出来。

2.3 一个真实的授权配置示例

我们用命令行做一遍，给一个新人用户开通两个项目的不同权限。这是生产环境最常见的需求，比如一个研发同事既要管开发环境的资源，又要偶尔查看生产环境的系统状态。

bash复制# 1. 创建用户（如果还没有）
openstack user create --domain default --password 'TempPass123!' zhangsan

# 2. 项目已存在：dev-project、prod-project

# 3. 把zhangsan加入dev-project并赋予member角色
openstack role add --user zhangsan --project dev-project member

# 4. 把zhangsan加入prod-project但只赋予只读角色（自定义角色）
openstack role create readonly
openstack role add --user zhangsan --project prod-project readonly

注意看命令的语义——role add这个动作本身就是“在指定项目里给指定用户加角色”，它天然要求三个参数：--user、--project、角色名。这就是刚才说的Assignment概念。

那么生产环境里，如果你给用户加了readonly角色，这个用户能在prod-project里看到云主机列表吗？取决于Nova的policy里有没有定义类似role:readonly的规则，并且把这个规则用在os_compute_api:servers:index上。默认情况下没有，所以你如果想实现“只读”效果，要么自定义policy，要么加一个自定义角色并把该角色引用到相应API的policy规则里。这块别指望默认配置能开箱即用。

2.4 这张“三表查询”逻辑是排查权限问题的线索

实际排错时，我强烈建议你先记熟这几条命令：

bash复制# 查看用户在某个项目里有哪些角色
openstack role assignment list --user zhangsan --project dev-project --names

# 查看项目下所有用户和角色
openstack role assignment list --project dev-project --names

# 查看某个用户所有项目里的角色
openstack role assignment list --user zhangsan --names

输出里会有TOKEN那一列显示为None，别管它，那是接入Keystone Federation（联邦认证）时才有用的字段。重要的是看输出的Role、User、Project三列。如果这里查不到记录，那你在Horizon或者API层面无论怎么调整策略都不会有权限，问题一定出在“压根没有Assignment”上。

3. 一个用户属于多个项目：多租户身份切换的实战姿势

这是很多人最开始困惑的地方——当一个人同时属于多个项目，他登录后看到的界面/API上下文到底是哪一个？答案：他在每次请求时都明确指定了Project。这就是OpenStack的“项目作用域（Project Scope）”机制。

3.1 Horizon界面里的“当前项目”切换

在Horizon（OpenStack的Web界面）里，用户登录后会看到左上角或顶部导航栏有一个当前项目的下拉框，可以切换到自己有权限访问的其它项目。切换之后，整个界面展示的资源列表、配额信息、安全组、网络等都会变成那个项目的。这个交互逻辑很多人没那么在意，但实际上非常重要——一个用户在不同项目里看到的资源完全不同，这就是多租户隔离在用户界面的直接体现。

如果你给一个用户添加了多个项目，但他在Horizon里看不到项目切换下拉框，常见原因有：

• Horizon配置了OPENSTACK_API_VERSIONS里的identity版本不匹配
• 用户在其它项目里虽然有Assignment，但Token过期了，刷新一下登录态即可
• 当前浏览器缓存了旧的项目列表（常见于多region部署），清缓存或用无痕窗口试试

3.2 CLI环境下如何指定项目

在命令行下，OpenStack统一通过环境变量或者命令参数来指定项目作用域：

bash复制# 方式一：环境变量（最常用）
export OS_PROJECT_NAME=dev-project
export OS_USERNAME=zhangsan
export OS_PASSWORD=xxx
export OS_AUTH_URL=http://controller:5000/v3
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default

# 方式二：命令后跟--os-project-name参数
openstack server list --os-project-name prod-project

但方式二有个坑，如果你当前环境变量指向dev-project，然后执行openstack server list --os-project-name prod-project，有些版本会直接忽略这个参数并去请求dev-project的资源列表，甚至报错。最稳妥的做法是每个项目单独设置一套环境变量文件，比如openrc-dev、openrc-prod，用的时候source一下。

这里有一个安全点值得提醒：不要在一个shell会话里来回切换source不同的rc文件，因为有些旧版本的OpenStack CLI会在环境变量残留时发出奇怪的行为。我自己的习惯是在每个新的终端tab里source不同的项目环境，或者用env | grep OS_检查当前环境变量再操作。

3.3 多项目归属的经典应用场景：跨项目协作与项目委托

多项目归属不是说“一个用户有两份权限”这么简单，它承载了一些常见的业务场景：

• 跨项目协作：你是一个运维人员，同时管着开发、测试、生产三个项目，每次操作都通过切项目作用域来切换身份。
• 项目委托：甲方有一个OpenStack项目，把其中的管理操作委托给了乙方的工程师。那就在甲方的项目里给乙方工程师的账号加一个角色，让他能在这个项目里做有限操作，但不能碰其它项目。
• 服务账号多项目写入：CI/CD系统的服务账号可能需要向多个项目推送镜像到Glance、或者同步配置到多个项目的Swift容器，这时候就可以通过多项目归属来让一个服务账号统管。

在生产案例里，我遇到过最典型的一个需求：给一个“项目运营人员”同时添加多个Project的member权限，让他通过Web界面查看所有项目的资源使用量。做法很简单：

bash复制for proj in project-a project-b project-c; do
    openstack role add --user opuser --project $proj member
done

用了这个操作之后，这个运营人员登录Horizon，就能在左上角下拉框切换查看每个项目的资源了。但要注意，Quota的实际使用量需要配合Ceilometer等监控组件才能看到历史趋势曲线，这里只能看到实时列表。

4. 项目、用户、角色的日常管理操作全记录

这一节是把日常操作做成一份可以照抄的清单。无论是创建新用户、新项目、还是给已有项目调整权限，都离不开这些命令。

4.1 项目的创建、更新、禁用与删除

创建项目时最容易忽略的是domain参数。在Keystone v3中，项目是挂在domain下的，虽然默认有一个default域，90%的场景不会用到多域，但命令里不带--domain会在某些新版本CLI里被警告，因此建议养成好习惯：

bash复制# 创建项目
openstack project create --domain default --description "研发环境项目" dev-project

# 查看项目详情
openstack project show dev-project

# 修改项目（比如改描述或改名称，改名称要小心！）
openstack project set dev-project --description "研发环境项目(已升级)"

# 禁用项目（临时不让新资源创建，但不影响已有资源运行）
openstack project set dev-project --disable

# 列出所有项目（包括禁用状态）
openstack project list

# 删除项目（有明确风险！项目下还有资源时一般无法删除）
openstack project delete dev-project

关于项目改名，这是一个容易被低估的操作。项目名称变了，UUID不会变，但CLI里机器读的项目名、Horizon URL里的项目名、以及各种配置文件里写的OS_PROJECT_NAME都要同步改。如果改了名称忘了改openrc，会直接报NotFound。生产环境我的建议是：项目一旦创建，名称不要改，要改就新建项目并迁移资源。

4.2 用户的创建、密码管理与启用禁用

用户的操作相对直接，唯一需要注意的是密码策略和用户域：

bash复制# 创建用户
openstack user create --domain default --password 'Welcome123!' --email zhangsan@example.com zhangsan

# 用户改密码（常用）
openstack user set --password 'NewPass456!' zhangsan

# 禁用用户（用户被禁用后所有项目权限全部失效，但关联关系保留）
openstack user set zhangsan --disable

# 重新启用
openstack user set zhangsan --enable

# 删除用户
openstack user delete zhangsan

很多人在创建用户后忘记设置邮箱和姓名（--email、--display-name这些属性），结果在Horizon的用户管理列表里看到一堆只有用户名的账号，很难区分是谁的。这个在实际运维中会非常痛苦，尤其当你负责的平台上有一百多个用户的时候。所以我的习惯是：创建用户的命令里必须带display-name和email，哪怕email随手填一个内部地址。

4.3 角色创建与权限边界定义

自定义角色是权限细化的重要方式。默认的admin和member粒度太粗，在很多安全审计场景下不够用，需要自己创建角色并配合policy调整。创建角色本身很简单：

bash复制# 创建一个只读角色
openstack role create readonly

# 创建一个网络管理员角色
openstack role create network-admin

# 查看所有的角色
openstack role list

# 查看角色的详情
openstack role show readonly

但真正的“角色定义权限”这一步不在Keystone里，而是在各服务的policy.yaml里。比如你希望readonly角色在Nova里只能执行list/show类操作，那就要在Nova的policy.yaml里找到list和show相关的规则，改成类似：

yaml复制"os_compute_api:servers:index": "role:readonly or role:admin or project_id:%(project_id)s"
"os_compute_api:servers:show": "role:readonly or role:admin or project_id:%(project_id)s"

改完policy之后，需要重启nova-api服务，并且客户端需要重新获取Token（因为Token里携带的角色列表是认证时固定的，policy变更不会让旧Token里的角色信息刷新）。

这里有一个非常关键的坑：不要把角色名写错。policy.yaml里的role:readonly，对应的是Keystone里Role的name，不是ID。一旦打错一个字母，权限就不会生效，而且不会报错，只会静默拒绝——排查起来极其痛苦。

4.4 角色分配的增删查改

给用户配角色是在项目维度上完成的：

bash复制# 增加角色分配
openstack role add --user zhangsan --project dev-project member

# 移除角色分配（注意：移除后用户在该项目里可能什么都干不了，但如果还有其他角色在，则保留其他角色权限）
openstack role remove --user zhangsan --project dev-project member

# 查看用户在某个项目的全部角色
openstack role assignment list --user zhangsan --project dev-project --names

# 查看项目下的所有用户角色映射
openstack role assignment list --project dev-project --names

批量操作时可以用循环脚本，比如批量把一批用户加入一个新项目：

bash复制for user in alice bob charlie; do
    openstack role add --user $user --project new-project member
    echo "已添加 $user"
done

5. 坑与经验：生产环境里你最可能遇到的权限问题

理论知识说得再多，不如把生产环境里频频踩到的问题拿出来复盘。我把自己和同行交流中最常出现的几个问题集中写在这里，都是真实案例。

5.1 坑一：给用户加了admin角色，结果还是没法管理其他项目

这是最常见的误解。admin角色默认在policy里，很多是role:admin规则，但注意，admin角色在某个项目里生效的前提是：这个用户必须在那个项目里有Assignment。如果你在东一区创建了一个全局admin用户，但他不在任何一个项目里有Assignment，那他只是“在default域里有admin角色”，到了某个具体项目里，query不到Assignment记录，自然无法操作该项目的资源。

更准确地说：admin角色如果配合domain级别的赋权，那是全局管理员；如果只配合project级别的赋权，那就只管那个项目。想把某个用户变成全平台管理员，需要给他分配一个“admin项目”（通常叫admin或cloud_admin），然后在这个项目里授予admin角色；或者在Keystone的domain层面赋予admin角色。这两者在权限覆盖范围上是不同的。

bash复制# 正确做法：先在admin项目里分配admin角色
openstack role add --user admin --project admin-domain admin

# 或者，创建domain admin project
openstack project create --domain default admin-project
openstack role add --user superadmin --project admin-project admin

但还有一个隐藏点：Nova的policy里存在一个rule:admin_api，它通常要求角色里有admin权限，还有一个rule:project_admin_or_owner，它们的具体定义在不同版本各有不同。很多情况下，你给用户加了admin角色在某个项目里，但nova-api的policy对某些管理操作要求“必须是admin角色的用户且作用域在admin项目”，这时候即使你在普通项目里加了admin角色也没用——这就要到policy.yaml里去确认实际规则。

5.2 坑二：创建新项目后，原本的管理员进不去

具体场景：你是云平台管理员，新建了一个项目new-proj，然后想用自己账号进去查看资源。于是用自己账号去操作，结果Horizon里并没有出现new-proj的下拉选项，CLI用--os-project-name new-proj也报错Project new-proj not found。

原因就是：新项目没有任何Assignment，管理员用户并没有自动获得这个项目里的任何角色。OpenStack不会因为你全局是admin，就自动给你所有项目的权限。因此，每次创建新项目之后，都必须要显式给相关管理人员执行role add：

bash复制openstack role add --user admin --project new-proj admin
openstack role add --user admin --project new-proj member

在一些自动化运维脚本里，创建项目之后的第一件事如果没有做这个role add，那后续所有需要管理员介入的操作（比如查看该项目下的错误信息定位问题）都会失败。

5.3 坑三：Swift里对容器的访问权限与项目绑定，可能超出你的预期

如果你使用Swift（对象存储），权限模型跟Nova/Neutron有很大不同。Swift的访问控制跟Keystone的Role绑定关系是：在Swift里，用户访问一个容器，首先必须能够通过Keystone认证，并且必须在对应的Project里有至少一个角色（通常member就可以）。但Swift内部的容器ACL（Access Control List）还有另一层机制：你可以通过X-Container-Write和X-Container-Read设置允许特定用户（甚至不用在同一项目里）读写容器。

这就产生了一个容易出问题的场景：你有一个用户，在Project A里有member角色，同时又在Project B里有member角色。如果他在Project B里通过Swift CLI操作容器，他操作的其实是Project B的容器的，而不是Project A的。很多人一开始分不清“全局容器列表”和“项目内容器列表”的差异，把跨项目的容器路径搞混，造成误删除。

5.4 坑四：Token过期时间与角色变更生效时间之间的竞态

当你在Keystone里给一个用户新增了某个项目的角色，这个用户当前已持有的Token并不会立刻被更新。Token里携带的是Token签发时刻的角色列表。也就是说，用户拿到Token之后的角色变更，在下次重新认证之前不会生效；反之，如果你撤销了某个角色，用户的旧Token在有效期内仍然带着旧角色，对某些API依然能访问。

这个问题的解决办法通常是设置较短的Token过期时间，或者主动让用户重新登录。对于安全审计要求高的环境，建议把Keystone的Token过期时间配置得短一些（比如默认的expiration设为8小时，可以调成1小时），配合Horizon的会话过期设置，降低风险窗口。

5.5 坑五：新手最容易忽略的domain维度

Keystone从v3开始引入了domain的概念，默认有一个Default域。如果你是用openstack project create new-project创建项目而没有带--domain，那这个项目会被创建到用户认证时指定的域（通常就是Default）。但如果你在创建用户时也忘了带--domain，用户会被创建到Default域，而Policy和Horizon默认也只查询Default域，所以多数情况下是可以的。

但一旦你的平台上建立了多个域（比如内部域、外部域、隔离域），因为domain作用域导致的权限问题就会层出不穷。最典型的是：在非Default域里创建项目或用户，而Horizon配置的是Default域，结果界面完全看不到那个新项目。排查这类问题的思路永远是先看资源到底挂在哪一个域下面，不要只看名字。

5.6 一个排查权限问题的四步法

最后把排查流程整理成一个固定套路，照着走能省非常多的时间：

1. 看Assignment：用openstack role assignment list --user xxx --project yyy --names确认用户在该项目下确实有角色分配。没有就是这一步的问题。
2. 看Token：openstack token issue之后，用openstack token show查看Token里携带的project和roles字段，确认Token作用域正确、角色正确。
3. 看Policy：找到对应服务的policy.yaml，找出被拒绝的那个API对应的规则，确认规则里要求什么角色，然后对比用户Token里实际带的角色是否满足。
4. 看日志：如果上面全查过还是不对，去/var/log/keystone/keystone.log、/var/log/nova/nova-api.log里搜对应的request_id，往往能看到具体是哪个策略规则拒绝的。

这套流程在绝大多数情况下能定位权限问题，比拿眼睛在界面上干瞪要高效得多。

6. 从单项目到多项目：一个最小化落地案例

我结合一个最小化多人团队使用场景，走一遍完整配置。假设一个研发团队有3个人（阿明、小红、阿强），需要一套开发环境、一套测试环境。管理员要做的事，就是创建好项目、用户，并把角色正确分配。

6.1 前置准备

确保已经在Keystone里初始化好基础环境，能执行openstack project list不报错。默认有admin项目和一个admin用户（安装时创建），先验证admin能正常操作：

bash复制source /etc/keystone/admin-openrc.sh
openstack project list

6.2 创建项目

bash复制openstack project create --domain default --description "开发环境" dev-project
openstack project create --domain default --description "测试环境" test-project

6.3 创建用户并初始化密码

bash复制openstack user create --domain default --password 'Dev123!' --display-name "阿明" aming
openstack user create --domain default --password 'Test123!' --display-name "小红" xiaohong
openstack user create --domain default --password 'Ops123!' --display-name "阿强" aqiang

6.4 分配角色

bash复制# 阿明进入开发环境做开发
openstack role add --user aming --project dev-project member

# 小红进入测试环境做测试
openstack role add --user xiaohong --project test-project member

# 阿强作为运维，两个项目都需要管理，并额外给予admin
openstack role add --user aqiang --project dev-project admin
openstack role add --user aqiang --project dev-project member
openstack role add --user aqiang --project test-project admin
openstack role add --user aqiang --project test-project member

这里我习惯把admin和member都加上。因为有些服务在admin角色下执行某些API时的预期行为是“管理操作”，如果只加admin不加member，某些旧版Horizon的显示会有异常（比如看不到项目列表，因为Horizon的查询有时依赖member角色的identity:list_projects权限）。具体看你平台版本，但两个都加绝对不会错。

6.5 验证

用阿明的账号登录，切换项目时应该只看到一个项目（dev-project）；用阿强的账号登录，可以看到两个项目，并且都能在项目里创建云主机、管理网络。如果阿强的账号在某个项目里执行操作时被拒绝，再按上面的四步法排查一遍。

这个最小化落地流程看起来简单，但你要注意一个细节：创建项目与分配角色之间，不需要等待，是立即生效的；但用户如果已经有一个旧Token，可能需要重新登录一次才能看到新分配的项目。如果发现问题，第一件事永远是让用户重新登录，而不是去怀疑后端。

7. 最后再说点实际的

我遇到很多人在聊OpenStack权限模型时，习惯性地拿“用户组”去理解“项目”，然后各种配置都对不上号。其实OpenStack的这套模型借鉴的是云计算里很经典的租户隔离和RBAC（基于角色的访问控制）思想，它的底层逻辑清晰得很，只是文档写得太“学术”，把简单事情说复杂了。

回到项目、用户、角色这三个词上，用一句话收束：项目是围墙，用户是进入围墙的人，角色是他在墙内能拿到的那把钥匙。 一个人可以同时拿不同院子里的不同钥匙，每把钥匙能开的锁由Policy决定。你下一步要做的，就是拿着openstack role assignment list多查几次自己的环境，亲手给一个用户配一遍跨项目的权限。这套东西只要实际操作一遍，基本就再也不会搞混了。