OpenStack Keystone 总结

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