OpenStack Mitaka 版本中的 domain 和 admin详解

OpenStack 的 Keystone V3 中引入了 Domain 的概念。引入这个概念后,关于 admin 这个role 的定义就变得复杂了起来。

本文测试环境是社区 Mitaka 版本。

1. Domain,project,user,role,token 的概念和关系

1.1 概况

简单来说,

  1. Domain - 表示 project 和 user 的集合,在公有云或者私有云中常常表示一个客户
  2. Group - 一个domain 中的部分用户的集合
  3. Project - IT基础设施资源的集合,比如虚机,卷,镜像等
  4. Role - 角色,表示一个 user 对一个 project resource 的权限
  5. Token - 一个 user 对于某个目标(project 或者 domain)的一个有限时间段内的身份令牌

它们之间的关系用一个不完整的图来表示:

说明:

  1. Domain 可以认为是 project,user,group 的 namespace。 一个 domain 内,这些元素的名称不可以重复,但是在两个不同的domain内,它们的名称可以重复。因此,在确定这些元素时,需要同时使用它们的名称和它们的 domain 的 id 或者 name。
  2. Group 是一个 domain 部分 user 的集合,其目的是为了方便分配 role。给一个 group 分配 role,结果会给 group 内的所有 users 分配这个 role。
  3. Role 是全局(global)的,因此在一个 keystone 管辖范围内其名称必须唯一。role 的名称没有意义,其意义在于 policy.json 文件根据 role 的名称所指定的允许进行的操作。
  4. 简单地,role 可以只有 admin 和 member 两个,前者表示管理员,后者表示普通用户。但是,结合 domain 和 project 的限定,admin 可以分为 cloud admin,domain admin 和 project admin。
  5. policy.json 文件中定义了 role 对某种类型的资源所能进行的操作,比如允许 cloud admin 创建 domain,允许所有用户创建卷等
  6. project 是资源的集合,其中有一类特殊的project 是 admin project。通过指定 admin_project_domain_name 和 admin_project_name 来确定一个 admin project,然后该project 中的 admin 用户即是 cloud admin。
  7. Token 具有 scope 的概念,分为 unscoped token,domain-scoped token 和 project-scoped token。下文有说明。

1.2 Token scope 和 Scoped token

官方文档在这里,我这里写的只是我的理解。

Token 是针对不同 scope 认证状态,这里的 scope 是指 project 和 domain,因此一共有三种 scoped token:

  1. project-scoped token:针对一个 project 的 token,它包含 service catalog, a set of roles, 和那个 project 的详细信息
  2. domain-scoped token:针对一个 domain  的 token,它具有有限的使用场景,只用于 domain 层面的操作。与 project-scoped 相比,它只具有优先的 sevice catalog
  3. unscoped token:当既不指定 project 也不指定 domain 为 scope ,同时 user 也没有 default project 时获得的 token,这是一种特殊的token。

下文有获取不同类型 token 的方法的描述。

2. 各种 admin

admin 是一种特别的 role。下面分两种情况讨论。

2.1 使用默认 policy.json 时候的 admin 的权限

2.1.1 Identity 资源的 admin 权限

对 Identiy 项目中的大多数资源的操作都需要 admin 权限,比如:

  "identity:get_user": "rule:admin_required",
  "identity:list_users": "rule:admin_required",
  "identity:create_user": "rule:admin_required",
  "identity:update_user": "rule:admin_required",
  "identity:delete_user": "rule:admin_required",

也就是说,以  user 为例,如果一个用户没有 admin 角色,那么他将不能对 user 做任何操作。而 policy.json 文件中对 admin 的约束非常简单:

"admin_required": "role:admin or is_admin:1",

也就是说,满足两个条件中的一个,它就是 administrator:

  1. 他拥有 'admin' 这个 role,而这里的 ‘admin' 是写死的,因为默认就是使用这个名字,当然你可以修改它,比如创建一个 cloud_admin role,然后修改这里为 role:cloud_admin,其效果是一样的。
  2. is_admin:1:这个只是在项目启动后才使用,其判断条件是操作使用的token 和 keystone.conf 中的 admin_token 相同。

从 policy.json 文件可以看出来,只要赋予一个用户 admin 角色,那么他就是 administrator 了,可以操作 OpenStack cloud 内的所有资源。

2.1.2 OpenStack 基础设施资源的权限控制

以 Cinder 为例,它也使用 policy.json 文件进行 role 的 policy 控制,它区分了 admin,project owner 和普通 user 的权限:

  "context_is_admin": "role:admin",
  "admin_or_owner": "is_admin:True or project_id:%(project_id)s",
  "default": "rule:admin_or_owner",
  "admin_api": "is_admin:True",

  "volume:create": "",
  "volume:delete": "rule:admin_or_owner",
  "volume:get": "rule:admin_or_owner",
  "volume:get_all": "rule:admin_or_owner",
  "volume:get_volume_metadata": "rule:admin_or_owner",

可见:

  1. 创建 volume:不限特定权限,只要是 user 角色就行
  2. 删除 volume,获取所有volumes:需要 admin 或者 project owner 权限,owner 是指用户 token 的 project id 和被删除 volume 的 project id 相同(也就是说对于一个 project 中的两个普通用户 user1 和 user2,user2 可以删除 user1 创建的 volume,但是不可以删除)

2.2 使用 policy.v3cloudsample.json 时候的 admin 的权限

从上面 2.1.1 可以看出,使用默认 policy.json 文件时的 admin 权限控制非常粗,不能支持 Keystone V3 API 中引入的域的概念。因此,社区提供了支持多域的 policy.v3cloudsample.json文件。

2.2.1 Identity 中的 admin

  "admin_required": "role:admin",
  "cloud_admin": "role:admin and (token.is_admin_project:True or domain_id:2b871f5dba704f74923ac01b4fcd7205)",
  "service_role": "role:service",
  "service_or_admin": "rule:admin_required or rule:service_role",
  "owner" : "user_id:%(user_id)s or user_id:%(target.token.user_id)s",
  "admin_or_owner": "(rule:admin_required and domain_id:%(target.token.user.domain.id)s) or rule:owner",
  "admin_and_matching_domain_id": "rule:admin_required and domain_id:%(domain_id)s",
  "service_admin_or_owner": "rule:service_or_admin or rule:owner",

它定义了几种 admin:

cloud admin (cloud_admin):必须拥有 admin role;其 token 在 admin project 内 或者在指定的 domain 内。Cloud admin 的主要职责是

  1. 创建 domains
  2. 为每个 domain 创建 domain admin

domain admin:必须拥有 admin role;token 的 domain id 必须和被操作资源(包括user,project 等) 的 domain id 相同。其主要职责包括

  1. 在该 domain 内创建 projects
  2. 在该 domain 内创建 users
  3. 分配 project 的权限给 user,包括 admin 和 user,前者就是 project admin,后者是 project user

只有 Cloud admin 拥有的一些权限:

  1. region 的增删改
  2. service 的增删改
  3. endpoint 的增删改
  4. domain 的列表,增删改
  5. role 增删改

只有 Domain admin 拥有的一些权限(当然这些权限 cloud admin 都拥有):

  1. 获取特定 domain 的信息
  2. 列表 projects,以及增删改
  3. 列表 users 和 groups
  4. user 增删改

2.2.2 示例规则说明

"admin_required": "role:admin",

"identity:create_project": "rule:admin_required and domain_id:%(project.domain_id)s",

"identity:get_project": "rule:admin_required and domain_id:%(target.project.domain_id)s",

"identity:list_projects": "rule:admin_required and domain_id:%(domain_id)s",

先来看create_project,首先要求 admin角色,需要注意的是and的后半句 domain_id:%(project.domain_id)s,这条规则的意思就是 create_project 时,使用的token的 domain_id 必须等于project所在的domain的domain_id。

也就是如下场景:

1.为userA在domainA的范围内赋予admin的权限

2.userA指定domainA作为scope,申请一个domainA scope的tokenA

3.userA使用tokenA,去创建project,创建project时domain_id参数必须为domainA的id

4.创建project成功

这里有几个关键点需要注意:

  1. 首先userA在domainA内必须要有admin权限,这样才能满足rule:admin_required
  2. 其次,token需要是一个domain scope的token,这样token中才会有domain_id
  3. 再次,创建project的时候,domain_id参数必须等于domainA的id,这样才能满足domain_id:%(project.domain_id)s。

这样一条规则的意义在于,可以限制只有在domainA内有权限的用户才能在domainA创建project。

get_project 比较好理解,就是查询的project的 domain_id 必须和token的 domain_id 相同,也就是只能查询 token 所在范围内的project。

list_project 是查询出所有的project,但是会根据token的domain_id过滤,然后剩下所有和token的domain_id相同的project。

keystone 增加了 domain 这样一个概念之后,其实也就把 keystone 本身的资源 user、project、group 按照 domain 给做了一个划分,可以做到在 domain 范围内的对于user、project和group的管理。

3. 多域(multi-domain)的相关操作

3.1 启用多域 policy.json

1. Keystone 使用普通的 policy.json 文件,使用 admin 用户,创建 admin_domain domain,cloud_admin user 并授予其 admin role

 openstack domain create admin_domain
 openstack user create --domain admin_domain --password 1111 --description "Cloud admin" cloud_admin
 openstack role add --domain admin_domain --user cloud_admin admin

2. 使用 policy.v3cloudsample.json

使用policy.v3cloudsample.json覆盖 /etc/keystone/policy.json,并做如下修改(蓝色部分为上一步说创建的 admin_domain 的 id):

代码如下:

"cloud_admin": "role:admin and (token.is_admin_project:True or domain_id:2b871f5dba704f74923ac01b4fcd7205)"

3. 重启 keystone service

3.2 操作

1. 获取 cloud_admin 用户 scoped domain 'admin_domain' token

CLOUD_ADMIN_TOKEN=$(\
curl http://localhost:5000/v3/auth/tokens \
  -s \
  -i \
  -H "Content-Type: application/json" \
  -d '
{
  "auth": {
    "identity": {
      "methods": [
        "password"
      ],
      "password": {
        "user": {
          "domain": {
            "name": "admin_domain"
          },
          "name": "cloud_admin",
          "password": "password"
        }
      }
    },
    "scope": {
      "domain": {
        "name": "admin_domain"
      }
    }
  }
}' | grep ^X-Subject-Token: | awk '{print $2}' )

注意 Keystone token 分为两大类:domain-scoped token 和 project-scoped token,各自需要使用不同的 scope 目标:

    --os-domain-name <auth-domain-name> | --os-domain-id <auth-domain-id>
       Domain-level authorization scope (name or ID)

    --os-project-name   <auth-project-name>   |    --os-project-id
    <auth-project-id>
       Project-level authentication scope (name or ID)

其中 domain-scoped token 用于操作 domain 范围内的资源,包括 projects 和 users;project-scoped token 用于操作 project 范围的资源。可以简单地认为,前者适合于 cloud admin 和 domain admin;后者合适于 project admin 和 标准 user。

2. 创建域 dom1

ID_DOM1=$(\
curl http://localhost:5000/v3/domains \
  -s \
  -H "X-Auth-Token: $CLOUD_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '
{
  "domain": {
    "enabled": true,
    "name": "dom1"
  }
}' | jq .domain.id | tr -d '"')

3. 在 dom1 中创建第一个用户 adm1

ID_ADM1=$(\
curl http://localhost:5000/v3/users \
  -s \
  -H "X-Auth-Token: $CLOUD_ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d "
{
  \"user\": {
    \"description\": \"Administrator of domain dom1\",
    \"domain_id\": \"$ID_DOM1\",
    \"enabled\": true,
    \"name\": \"adm1\",
    \"password\": \"password\"
  }
}" | jq .user.id | tr -d '"')

4. 赋予用户 adm1 'admin' role

curl -X PUT http://localhost:5000/v3/domains/${ID_DOM1}/users/${ID_ADM1}/roles/${ADMIN_ROLE_ID} \
  -s \
  -i \
  -H "X-Auth-Token: $CLOUD_ADMIN_TOKEN" \
  -H "Content-Type: application/json"

5. 获取 adm1 在 dom1 中的 token,同样是domain-scoped 的

ADM1_TOKEN=$(\
curl http://localhost:5000/v3/auth/tokens \
  -s \
  -i \
  -H "Content-Type: application/json" \
  -d '
{
  "auth": {
    "identity": {
      "methods": [
        "password"
      ],
      "password": {
        "user": {
          "domain": {
            "name": "dom1"
          },
          "name": "adm1",
          "password": "password"
        }
      }
    },
    "scope": {
      "domain": {
        "name": "dom1"
      }
    }
  }
}' | grep ^X-Subject-Token: | awk '{print $2}' )

6. 在 dom1 中创建 prj1

ID_PRJ1=$(\
curl http://localhost:5000/v3/projects \
  -s \
  -H "X-Auth-Token: $ADM1_TOKEN" \
  -H "Content-Type: application/json" \
  -d "
{
  \"project\": {
    \"enabled\": true,
    \"domain_id\": \"$ID_DOM1\",
    \"name\": \"prj1\"
  }\
}" | jq .project.id | tr -d '"' )

echo "ID of prj1: $ID_PRJ1"

7. 在 dom1 中创建标准用户 usr1

ID_USR1=$(\
curl http://localhost:5000/v3/users \
  -s \
  -H "X-Auth-Token: $ADM1_TOKEN" \
  -H "Content-Type: application/json" \
  -d "
{
  \"user\": {
    \"default_project_id\": \"$ID_PRJ1\",
    \"description\": \"Just a user of dom1\",
    \"domain_id\": \"$ID_DOM1\",
    \"enabled\": true,
    \"name\": \"usr1\",
    \"password\": \"password\"
  }
}" | jq .user.id | tr -d '"' )

echo "ID of user usr1: $ID_USR1"

8. 赋予 usr1 Member 权限

MEMBER_ROLE_ID=$(\
curl http://localhost:5000/v3/roles?name=Member \
  -s \
  -H "X-Auth-Token: $ADM1_TOKEN" \
| jq .roles[0].id | tr -d '"' )

curl -X PUT http://localhost:5000/v3/projects/${ID_PRJ1}/users/${ID_USR1}/roles/${MEMBER_ROLE_ID} \
  -s \
  -i \
  -H "X-Auth-Token: $ADM1_TOKEN" \
  -H "Content-Type: application/json"

3.3 使用 OpenStack CLI 操作

经过测试,获得如下结果:

1. 使用 cloud_admin 用户在 openstack CLI 操作都正常

2. 使用 domain admin 用户 adm1 用户在 OpenStack CLI 中不正常

从 OpenStac CLI 文档上看,可以通过下面的方法获取不同 scoped token:

  1. --os-domain-name:同 REST API 中 的 scope/domain/name,获取 domain-scoped token
  2. --os-project-name:同 REST API 中的 scope/project/name,获取 project-scoped token
--os-domain-name <auth-domain-name> | --os-domain-id <auth-domain-id>
Domain-level authorization scope (name or ID)
--os-project-name <auth-project-name> | --os-project-id <auth-project-id>
Project-level authentication scope (name or ID)

但是实际测试中,使用 --os-domain-name 无法获取期望的 domain-scoped token:

root@controller:/home/sammy# openstack --os-domain-name dom1 --os-username adm1 --os-password password --os-user-domain-name dom1 user list
You are not authorized to perform the requested action: identity:list_users (HTTP 403) (Request-ID: req-ea4b10-0a35-4d88-907f-bab181544f40)

调试发现,此时的token 自带有 project_id,而不带有 domain_id。还需要进一步确认是否是个 bug。

一个 workaround 是,对于这种 domain admin 用户,需要首选获取 domain scoped token,然后通过 curl 操作,比如要获取 domain 内的project 列表:

root@controller:/home/sammy# curl -sX GET -H "X-Auth-Token:$ADM1_TOKEN" http://mysqlserver:5000/v3/projects?domain_id=db7de29b35dd450284dc99bc0a6474ca
{"links": {"self": "http://mysqlserver:5000/v3/projects?domain_id=db7de29b35dd450284dc99bc0a6474ca", "previous": null, "next": null}, "projects": [{"is_domain": false, "description": "", "links": {"self": "http://mysqlserver:5000/v3/projects/7ff06beb0045405f8bebcda166f47f04"}, "enabled": true, "id": "7ff06beb0045405f8bebcda166f47f04", "parent_id": "db7de29b35dd450284dc99bc0a6474ca", "domain_id": "db7de29b35dd450284dc99bc0a6474ca", "name": "prj1"}

3. 从结果看, Mitaka 版本的 OpenStack CLI 对多域的支持情况如下:

  1. 支持 cloud admin,这是通过 admin domain 的方式来实现的
  2. 支持 project owner,通过 project-scoped token
  3. 支持普通 user,通过 project-scoped token
  4. 不支持 domain admin,因为无法获取 domain-scoped token

3.4 Horizon 对多域的支持

3.4.1 准备工作

1. 修改 /etc/openstack-dashboard/local_settings.py 文件:

OPENSTACK_API_VERSIONS = {
  "data-processing": 1.1,
  "identity": 3,
  "volume": 2,
  "compute": 2,
}

# Set this to True if running on multi-domain model. When this is enabled, it
# will require user to enter the Domain name in addition to username for login.
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True

2. 将 keystone 使用的支持多域的 policy.json 文件拷贝到目录/etc/openstack-dashboard/keystone_policy.json,然后修改文件local_settings.py:

POLICY_FILES = {
  'identity': 'keystone_policy.json'
}

3. 重启 horizon 服务,此时可以使用 domain 和 username,password 登录

4. 简单测试了一下,发现还是有不少问题。

比如 cloud admin dashboard 中只能出来它所在的domain,而不能出来所有的 domains:

以domain admin 登录,直接报错:

以普通用户登录,还能显示 Admin/System 面板。

备注:Keystone V3 中的概念较多,涉及的面较广,本文只是说明了一部分,甚至不是很准确。接下来会根据需要持续更新。

(0)

相关推荐

  • OpenStack之日志详细介绍

    OpenStack日志                 最近做项目用到OpenStack,由于刚刚开始使用,有很多错误,然后查询日志,抽空把日志系统的资料整理下来,大家可以看下. 日志对于一个稳定的系统来说相当重要,对于OpenStack这样一个大型的系统,日志当然也是必不可少,理解Openstack系统的日志对于保证OpenStack环境稳定非常重要.对于出现系统错误,查看日志是一个很好的习惯. OpenStack通过生成大量日志信息来帮助排查系统安装运行期间出现的问题,接下来介绍几个常见服务

  • 一步一步教你安装openstack(图文)

    openstack,安装的门槛比较高,而且相当麻烦,很多的安装文档作者省了不少安装步骤.这对初学的人带来了很大的麻烦,也许作者轻易节省一步,就会创成后面的安装失败.而且初学者由于对openstack不是很了解,错误无法排查,因此很多人都在中途放弃对openstack的学习.其实有一个安装工具可以快速的安装openstack,不需要了解openstack各个组件的之间的关系,只需鼠标轻轻一点,就可以完成对openstack的安装:而且还有诸多功能,如对openstack健康检查,查看节点日志等.

  • Fuel 30 分钟快速安装OpenStack(图文教程)

    一直以来,对于openstack 的初学者来讲,安装往往是入门的头大难题.在E版本之前,要搭建一个基本能用的openstack 环境那是相当麻烦,自己要装机,自己搞源,自己照着文档敲命令,又没有靠谱的文档,官方给出的文档依旧有好多坑,还有语言问题往往用上好几天时间都装不起来,慢慢地就丧失了学习openstack 的信心! 不过后来情况有了很大改观,从E版本开始,以后安装过程简化许多,文档质量提高不少.尽管如此对于初学者还讲还是比较复杂,其实很多时候,很多人只是想体会一下openstack,完全不

  • Openstack 使用migrate进行数据库升级实现方案详细介绍

    Openstack 使用migrate进行数据库升级实现方案详细介绍 OpenStack中随着版本的切换,新版本加入一些数据库表或者增加字段等是必然的事情,如何比较容易的进行这些数据库升级的适配和管理,这里就要用到oslo_db中的migrate了,这里以为M版本的heat为例,讲解一下migrate管理db的原理. 我们使用migrate需要用到的主要包含以下两部分:1.versions里面的为版本号+数据库适配脚本:2.migrate.cfg为migrate需要用到的配置文件,两部分的命名是

  • CentOS 6.4下安装部署OpenStack云计算平台的方法

    前言 OpenStack 是一个开源的 IaaS(基础设施及服务)云计算平台,让任何人都可以自行建立和提供云端运算服务. OpenStack 由一系列相互关联的项目提供云基础设施解决方案的各个组件,核心项目(9 个): 1.计算 (Compute) - Nova: 2.网络和地址管理 - Neutron: 3.对象存储 (Object) - Swift: 4.块存储 (Block) - Cinder: 5.身份 (Identity) - keystone: 6.镜像 (Image) - Glan

  • 什么是OpenStack 开源的云计算管理平台项目

    OpenStack是一个由NASA(美国国家航空航天局)和Rackspace合作研发并发起的,以Apache许可证授权的自由软件和开放源代码项目. OpenStack是一个开源的云计算管理平台项目,由几个主要的组件组合起来完成具体工作.OpenStack支持几乎所有类型的云环境,项目目标是提供实施简单.可大规模扩展.丰富.标准统一的云计算管理平台.OpenStack通过各种互补的服务提供了基础设施即服务(IaaS)的解决方案,每个服务提供API以进行集成. OpenStack是一个旨在为公共及私

  • CentOS 一键安装Openstack详细介绍

     CentOS 一键安装Openstack 最近再看Openstack相关知识,一直想试试安装一下,可是参考了很多资料,并不如人意.由于一直用的Linux版本为CentOS,大部分Openstack安装都要求在Ubuntu上进行.我也不知到什么原因,并不喜欢Ubuntu,可能是觉得太花哨了,而且总提示更新什么的,好了,废话不多说. 找到一个网站,国外的,  http://openstack.redhat.com/Main_Page,进入到quickstart页面中,简单翻译如下: 用到的工具是一

  • Fuel快速安装OpenStack图文教程

    1 介绍 1.1关于 Mirantis Mirantis,一家很牛逼的openstack服务集成商,他是社区贡献排名前5名中唯一一个靠软件和服务吃饭的公司(其他分别是Red Hat, HP, IBM, Rackspace).相对于其他几个社区发行版,Fuel的版本节奏很快,平均每两个月就能提供一个相对稳定的社区版. 1.2Fuel 是什么? Fuel 是一个为openstack 端到端"一键部署"设计的工具,其功能含盖自动的PXE方式的操作系统安装,DHCP服务,Orchestrati

  • OpenStack之虚机热迁移的代码详细解析

    话说虚机迁移分为冷迁移以及热迁移,所谓热迁移用度娘的话说即是:热迁移(Live Migration,又叫动态迁移.实时迁移),即虚机保存/恢复(Save/Restore):将整个虚拟机的运行状态完整保存下来,同时可以快速的恢复到原有硬件平台甚至是不同硬件平台上.恢复以后,虚机仍旧平滑运行,用户不会察觉到任何差异.OpenStack的虚机迁移是基于Libvirt实现的,下面来看看Openstack虚机热迁移的具体代码实现. 首先,由API入口进入到nova/api/openstack/comput

  • openstack 重启的服务命令整理总结

    openstack重启的服务命令集合 最近公司项目需要使用Openstack   由于Openstack 重启服务命令比较多,于是就在网上找了下资料,整理下来,希望能帮助到读者! 重启openstack的整个服务 openstack-service restart 1. 重启dashboard service httpd  restart service memcached restart 2. 重启 ceilometer 2.1 cinder service mongod restart 2.

随机推荐