Keystone组件详解

目录

一、Keystone的主要功能模块

二、Keystone的基本概念介绍

三、Keystone的管理层次结构

四、Keystone交互流程

一、用户是如何来与Keystone交互的？

二、keystone认证流程（与其他服务的交互）

五、其他

---

一、Keystone的主要功能模块

Token：用来生成管理token

Catalog： 用来存储和管理service和endpoint

indetity：用来管理user，tenant，role的认证

Policy：用来管理访问权限

二、Keystone的基本概念介绍

（1）认证（Authentication）确认用户身份的过程，又称为身份验证。keystone验证由用户提供的一组凭证来确认传入请求的有效性。

（2）凭证（Credentials）确认用户身份的数据。例如：用户名和密码、用户名和密钥（API密钥）或者由身份服务提供的认证令牌。

用户第一次请求认证时，需提供用户名和密码或用户名和密钥（API密钥），keystone会给用户分配一个Authentication token 供该用户的后续请求操作，后续请求认证，只需提供由身份服务提供的认证令牌Token即可。（返回的Token中包含user的role列表）

（3）令牌（Token）是一串数字和字母组成的文本字符串，当用户要去访问资源时，keystone提供Token来保护用户对资源的访问。如：提供访问的范围和有效时间。

keytone提供对Token进行加密的方式：PKI、PKIZ、fernet、UUID。（常用fernet）

（4）用户（User）指使用openstack 云服务的个人、系统和服务的账户名称，即就是访问openstack的对象。

（5）项目（Project）早期版本是租户（Tenant），是分配和隔离资源或者身份对象的一个容器，也是一个权限组织形式。

（6）域（Domain）域是项目和用户的集合，目的是为身份实体定义管理界限。

（7）组（Group）组是一个表示域所拥有的用户集合的容器。为了更好的管理用户，向组中添加用户，会相应地授予该用户对关联的域或项目的角色和认证。

（8）角色（Role）角色是一个用于定义用户权力和权限的集合。系统默认使用管理Role的角色管理员用户：admin 普通用户：member（老版本） user（新版本）

通常权限管理是由角色、项目和用户相互配合来实现的。一个项目中往往要包含用户和角色，用户必须依赖与某一项目，而角色必须以一种角色的身份加入到项目中。

（9）端点（Endpoint）

相当于OpenStack服务对外的网络地址列表，通常是一个URL

任何服务都访问openstack service中的资源时，都要访问keystone

endpoint分为三类：

1.admin url ：管理员用户使用 Port：35357

2.internal url ：openstack内部组件间互相通信 Port：5000 （组件之间通信基于Restful api）

3.public url ：其他用户访问地址 Port：5000

（10）服务（Service）服务像Nova，Glance等，它们提供一个或者多个端点，供用户通过这些端点访问资源和执行操作

（11）分区（Region）分区表示openstack部署的通用分区。每个分区有自己独立的端点，分区之间完全隔离，但是多个分区之间共享同一个keystone服务和仪表板。

三、Keystone的管理层次结构

关于keystone的管理层次结构，在identify API v2版本中（以弃用），用户的权限管理以用户为单位，需要对每一个用户进行角色分配，并不存在对一组用户进行统一管理的方案。虽然在v2版本中有租户（Tenant）的概念，可以包含多个用户，不同租户之间相互隔离。但没有更高层的单位来对多个租户进行统一的管理。

针对这些问题，identify API v3版本引进了域和组这两个新的概念，并将租户改为项目。

对图片的解释：一个域中包含3个项目，可以通过组Group1将角色admin这季节授予该域，这样组Group1中的所有用户将对域中的所有项目拥有管理由权限

也可以通过组Group2将角色_member_仅分配给项目project3，这样组Group2中所有用户就只拥有对项目Project3的相关权限。

 四、Keystone交互流程

（1）用户是如何来与Keystone交互的？

这里以user访问glance为例

（2）keystone认证流程（与其他服务的交互）

 

从上图中可以看出用户访问其他组件都需要从keystone中获取的Token和endpoint，并且通过服务列表选择要访问的服务。其中keystone在交互过程起到一个中间人的作用，即访问其他组件都离不开keystone。

五、其他

值得提下oslo.policy库，也就是对用户访问资源分配的角色（权限）。

oslo.policy库用于实现基于角色的权限访问控制，使用策略控制某一个人用户权限，规定用户能执行什么操作，不能执行什么操作。

oslo.policy库存放的地方在/etc/服务名/policy.json文件中。如：/etc/keystone/policy.json

语法格式如下："目标":"规则"

以keystone为例

规则可以是一下任意一种（逻辑结果为True或False）

(1）总是允许，可以使用空字符串（"")、中括号（[]）或＂@＂来表示。

(2）总是拒绝，只能使用感叹号（""）来表示。

(3）特定的检查结果。

(4）两个值的比较。

(5）基于简单规则的逻辑表达式。

特定的检查结果可以是一下几种形式之一。

（1）角色：角色名称——测试API凭证是否包括该角色

（2）规则：规则名称——别名定义

（3）http：目标URL——将检查委托给远程服务器，远程服务器返回True则API被授权

两个值的比较采用以下语法格式

"值1:值2"

其中值可以是一下形式之一。

（1）常量：可以是字符串、数字、True或False

（2）API属性：可以是项目ID、用户ID、或域ID

（3）目标对象属性：这是来自数据库中对象描述的字段。如，compute:start 说明对象是实例被启动。

（4）标志is_admin：表明管理特权admin令牌机制授予。admin令牌允许在admin角色存在之前初始化Identify（身份管理）数据库。

策略定义还支持别名，语法如下：

"别名名称":"<别名定义>"

一旦定义别名，就可以在策略中使用该关键字