OpenStack Keystone 总结

2021-02-26 10:33:34 浏览数 (1)

OpenStack Keystone 总结

2018年05月15日 21:41:01 dylloveyou

所属专栏: OpenStack

版权声明:欢迎转载,但要注明原文链接。https://blog.csdn.net/dylloveyou/article/details/80329732

一、概述

Keystone(OpenStack IdentityService)是 OpenStack 框架中负责管理身份验证、服务访问规则和服务令牌功能的组件。用户访问资源需要验证用户的身份与权限,服务执行操作也需要进行权限检测,这些都需要通过 Keystone 来处理。Keystone 类似一个服务总线, 或者说是整个 Openstack 框架的注册表,OpenStack 服务通过Keystone 来注册其 Endpoint(服务访问的URL)。任何服务之间的相互调用,都需要先经过Keystone 的身份验证,获得目标服务的 Endpoint ,然后再调用。

Keystone 的主要功能如下:

· 管理用户及其权限;

· 维护 OpenStack 服务的Endpoint

· Authentication(认证)和 Authorization(鉴权)。

Keystone 在整个 OpenStack 架构中的位置如下图:

Keystone 的架构如下图:

对于架构图中的概念,比如 Policy、Token、Endpoint、Credentials等等,都是什么意思,应该怎样理解,下面我们进行详细介绍。概念理解后,对架构的理解也就清晰了。

二、基本概念

掌握 Keystone,需要理解下面这些基本概念:

1. User

User 指代任何使用 OpenStack 的实体,可以是真正的用户,其他系统或者服务。当 User 请求访问 OpenStack 时,Keystone 会对其进行验证。

Horizon 在 “身份管理->用户” 管理 User:

除了admin 和 demo,OpenStack 也为 nova、cinder、glance、neutron 等服务创建了相应的 User。 admin 也可以管理这些 User。

2. Credentials

Credentials 是 User 用来证明自己身份的信息。可以是:(1) 用户名/密码 (2) Token (3) API Key (4)其他高级方式。

3. Authentication

Authentication 是 Keystone 验证 User 身份的过程。User 访问OpenStack 时向 Keystone 提交用户名和密码形式的 Credentials,Keystone 验证通过后会给 User 签发一个 Token 作为后续访问的 Credential。

4. Token

Token 是由数字和字母组成的字符串,User 成功 Authentication 后由 Keystone 分配给 User。Token 用做访问 Service 的 Credential,Service 会通过 Keystone 验证 Token 的有效性。Token 还有 scope 的概念,表明这个 Token 作用在什么范围内的资源,例如某个 Project 范围或者某个 Domain 范围,Token 只能用于认证用户对指定范围内资源的操作。Token 的有效期默认是 24 小时。

Keystone 提供如下几种 Token,可以根据需要配置使用某种 Token:

UUID token:服务 API 收到带有 UUID token 的请求时,必须到 Keystone 进行验证token 的合法性,验证通过之后才能响应用户请求。随着集群规模的扩大,Keystone需处理大量验证 UUID token 的请求,在高并发下容易出现性能问题。

PKI token:携带更多用户信息并附上了数字签名,服务 API收到 PKItoken 时无需再去Keystone 验证,但是 PKItoken 所携带可能随着 OpenStack Region 增多而变得非常长,很容易超出 HTTP Server 允许的最大 HTTP Header(默认为 8 KB),导致 HTTP 请求失败。

PKIZ token:PKI token 的压缩版,但压缩效果有限,无法良好的处理 token 长度过大问题。

Fernet token:携带了少量的用户信息,大小约为 255Byte,采用了对称加密,无需存于数据库中。前三种 token 都会持久性存于数据库,与日俱增积累的大量 token 引起数据库性能下降,所以用户需经常清理数据库的 token;Fernet token没有这样的需要。

注:在Ocata版本中 Fernet 成为默认的 Token Provider。 PKI 和 PKIz token provider 被移除 。

5. Project

Project 用于将 OpenStack 的资源(计算、存储和网络)进行分组和隔离。在企业私有云中,Project 可以是一个部门或者项目组,和公有云的 VPC(虚拟私有网络)概念类似。资源的所有权是属于 Project 的,而不是 User。每个 User(包括 admin)必须挂在 Project 里才能访问该 Project 的资源,一个 User 可以属于多个 Project。

Horizon 在 “身份管理->项目” 中管理 Project:

可以通过 “管理成员” 将 User 添加到 Project 中。

6. Service

OpenStack 的 Service 包括 Compute (Nova)、Block Storage (Cinder)、Object Storage (Swift)、Image Service(Glance) 、Networking Service (Neutron) 等。每个 Service 都会提供若干个 Endpoint,User 通过Endpoint 访问资源和执行操作。

7. Endpoint

Endpoint 是一个网络上可访问的地址,通常是一个 URL。Service 通过Endpoint 暴露自己的 API。Keystone 负责管理和维护每个 Service 的 Endpoint。

8. Role

安全包含两部分:Authentication(认证)和 Authorization(鉴权)。Authentication 解决的是“你是谁?”的问题, Authorization 解决的是“你能干什么?”的问题。Keystone 是借助 Role来实现 Authorization 的。Role 是全局(global)的,因此在一个 keystone 管辖范围内其名称必须唯一。

Horizon 在 “身份管理->角色” 中管理 Role:

可以为 User 分配一个或多个 Role。

Service 决定每个 Role 能做什么事情。Service 通过各自的 policy.json 文件对 Role 进行访问控制。Role 的名称没有意义,其意义在于 policy.json 文件根据 role 的名称所指定的允许进行的操作。

上面是Nova 服务 /etc/nova/policy.json 中的示例,配置含义为:

· 对于 create、attach_network 和 attach_volume 操作,任何 Role 的 User 都可以执行; 但只有 admin 这个 Role 的 User 才能执行 forced_host 操作。

· OpenStack默认配置只区分 admin 和非 admin Role。 如果需要对特定的 Role 进行授权,可以修改 policy.json。

9. Group

Group 是一个 domain 部分 user 的集合,其目的是为了方便分配 role。给一个 group 分配 role,结果会给group 内的所有 users 分配这个 role。

Horizon 在 “身份管理->组” 中管理 Group:

10. Domain

Domain 表示 Project、Group和 User 的集合,在公有云或者私有云中常常表示一个客户,和 VDC(虚拟机数据中心)的概念类似。Domain 可以看做一个命名空间,就像域名一样,全局唯一。在一个 Domain 内,Project、Group、User 的名称不可以重复,但是在两个不同的 Domain 内,它们的名称可以重复。因此,在确定这些元素时,需要同时使用它们的名称和它们的 Domain 的 id 或者 name。

下图表示了 Domain、Project、User、Group、Role 之间的关系:

下面是一个整体关系图:

三、交互流程(图形界面操作)

Keystone 与 OpenStack 其他服务交互流程如下:

首先用户向 Keystone 提供自己的身份验证信息,如用户名和密码。Keystone 会从数据库中读取数据对其验证,如验证通过,会向用户返回一个 token,此后用户所有的请求都会使用该 token 进行身份验证。

如用户向 Nova 申请虚拟机服务,nova 会将用户提供的 token 发给 Keystone 进行验证,Keystone 会根据 token 判断用户是否拥有进行此项操作的权限,若验证通过那么 nova 会向其提供相对应的服务。其它组件和 Keystone 的交互也是如此。

下面通过 “查询可用 image” 这个实际操作示例,让大家对相关概念及交互流程建立更加感性的认识。

示例 :User admin 要查看 Project 中的 image。

第一步,登陆。

输入用户名密码后,点击“连接”按钮,OpenStack 内部发生了哪些事情?

返回的 token 中包含了User 的 Role 信息。

第二步,显示操作界面。

请注意,顶部显示 admin 可访问的 Project 为 “admin” 和 “demo”。

其实在此之前发生了一些事情:

同时,admin 可以访问 “实例”, “卷”,“映像” 等服务:

这是因为 admin 已经从 Keystone 拿到了各 Service 的 Endpoints:

第三步,显示 Image 列表。

点击“映像”,会显示映像列表:

背后发生了这些事:

首先,admin 将请求发送到Glance 的 Endpoint:

Glance 向 Keystone 询问 admin 身份的有效性:

接下来 Glance 会查看 /etc/glance/policy.json,判断 admin 是否有查看 image 的权限。

权限判定通过,Glance 将 image 列表发给admin。

四、REST API 调用

上面的示例是在界面操作完成的,我们也可以通过调用 REST API来实现。

同样的示例 :User admin 要查看 Project 中的 image。

第一步,获取Token。

URL http://controller:35357/v3/auth/tokens

传入的参数包括 user id,userpassword,project id,示例如下:

{

"auth": {

"identity": {

"methods": [

"password"

],

"password": {

"user": {

"id":"ee4dfb6e5540447cb3741905149d9b6e",

"password":"admin"

}

}

},

"scope": {

"project": {

"id":"a6944d763bf64ee6a275f1263fae0352"

}

}

}

}

执行成功后,会返回 Token 信息。

第二步,根据token获取image列表。

URL http://controller:9292/v2/images

其中请求的 Header 需要加上上一步返回的 Token。

下面是返回的 images 列表信息(JSON 格式):

五、总结

本文对 OpenStack 认证服务 Keystone 做了详细的介绍,包括其功能、架构、基本概念以及和其他服务的交互流程。本文内容参考了网络上的很多有价值的文章,在这里表示非常感谢!

参考文档

https://www.cnblogs.com/charles1ee/p/6293387.html

http://www.cnblogs.com/CloudMan6/p/5365474.html

http://www.cnblogs.com/CloudMan6/p/5373311.html

https://www.ibm.com/developerworks/cn/cloud/library/1506_yuwz_keystonev3/index.html

http://www.cnblogs.com/sammyliu/p/5955984.html

0 人点赞