问题导读 1、 Keystone 的功能 有那些？2、Keystone的重点有哪些呢？ 3、V3 版本 Keystone API是怎么样的呢？ 1. Keystone 的功能 1.1 Keystone 管理的相关概念 这些Keystone 管理对象之间的关系：
1.2 Keystone 管理这些概念的方法 组件名称 管理对象 生成方法 保存方式 配置项 identity user，以及 user group - sql , kvs, ldap[identity]
driver = keystone.identity.backends.[sql |kvs|ldap].Identity
token 用户的临时 token pki，pkiz，uuid sql, kvs,memcached [token]
driver = keystone.token.persistence.backends.[sql |kvs|memcached].Token
provider=keystone.token.providers.[pkiz|pki|uuid ].Providercredential EC2 credential sql [credential]
driver = keystone.credential.backends.sql.Credential
catalog region,service,endpoint sql |kvs| template[catalog]
driver = keystone.catalog.backends.[sql |kvs| template].Catalog
assignment tenant，domain，role 以及它们与 user 之间的关系 external, password, token [assignment]
methods = external, password, token
password = keystone.auth.plugins.password.Password
trust trust sql ，kvs [trust]
driver = keystone.trust.backends.[ssql |kvs].Trust
policy Keystone service 的用户鉴权策略 sql [default]
policy_file = policy.json
[policy]
driver = keystone.policy.backends.sql .Policy
1.3 Keystone 代码结构
（1）bin 目录下：
keystone-manage 是个 CLI 工具，它通过和 Keystone service 交互来做一些无法使用 Keystone REST API 来进行的操作，包括：db_sync: Sync the database. db_version: Print the current migration version of the database. mapping_purge: Purge the identity mapping table. pki_setup: Initialize the certificates used to sign tokens. saml_idp_metadata: Generate identity provider metadata. ssl_setup: Generate certificates for SSL. token_flush: Purge expired tokens. keystone-all 用于启动 Keystone 的服务，下面有章节描述其服务启动过程。 （2）keystone 目录下：
每个Keystone 组件，比如 catalog， token 等都有一个单独的目录。 每个组件目录中： routes.py 定义了该组件的 routes （routes 见 探索 OpenStack 之（9）：cinder-api Service 启动过程分析 以及 WSGI / Paste deploy / Router 等介绍 ）。其中，identity 和 assignment 分别定义了 admin 和 public 使用的 routes，分别供 admin service 和 public service 使用。controller.py 文件定义了该组件所管理的对象，比如 assignment 的controller.py 文件定义了 Tenant、Role、Project 等类。 core.py 定了了两个类 Manager 和 Driver。Manager 类对外提供该组件操作具体对象的方法入口； Driver 类定义了该组件需要其Driver实现类所提供的接口。 backend 目录下的每个文件是每个具体driver 的实现 contrib 目录包括resource extension 和 extension resource 的类文件 1.4 Keystone 服务启动 [composite:main]
use = egg:Paste#urlmap
/v2.0 = public_api
/v3 = api_v3
/ = public_version_api
[composite:admin]
use = egg:Paste#urlmap
/v2.0 = admin_api
/v3 = api_v3
/ = admin_version_api 复制代码 名称 middlewares factory 功能区别 admin 比 public 多 s3_extension keystone.service:public_app_factory 从 factory 函数来看， admin service 比 public service 多了 identity 管理功能， 以及 assignment 的admin/public 区别：
1. admin 多了对 GET /users/{user_id} 的支持，多了 get_all_projects， get_project，get_user_roles 等功能
2. keystone 对 admin service 提供 admin extensions, 比如
OS-KSADM 等；对 public service 提供 public extensions。
简单总结一下， public service 主要提供了身份验证和目录服务功能；admin service 增加了 tenant、user、role、user group 的管理功能。
public sizelimit url_normalize build_auth_context token_auth admin_token_auth xml_body_v2
json_body ec2_extension user_crud_extension
keystone.service:admin_app_factory
/usr/bin/keystone-all 会启动 admin 和 public 两个 service，分别绑定不同 host 和 端口。默认的话，绑定host 都是 0.0.0.0； admin 的绑定端口是 35357 （admin_port）， public 的绑定端口是 5000 （public_port）。因此，给 admin 使用的 OS_AUTH_URL 为 http://controller:35357/v2.0， 给 public 使用的 OS_AUTH_URL=http://controller:5000/v2.0.
2. Keystone 中的几个重点
2.1 用户的 username/password 身份验证和 token 生成
HTTP Verb：POST /tokens
HTTP params: {'auth': {u'tenantName': u'admin', u'passwordCredentials': {u'username': u'admin', u'password': u'1111'}}}
method: <bound method Auth.authenticate of <keystone.token.controllers.Auth object at 0x7fb58f611610>>
基本步骤：
（3）通过 user name 获取 user id，最终会从 identity backend 中获取到。
（6）校验用户的 password 和 identity backend 中的 password 的一致性。sql backend 的话，直接比较两个值。
（8）获取 project info，接下来检查 domain，project，tenant 是否都是 enabled。
（19）获取 catalog 和 roles。
（22）使用 user_ref,tenant_ref,metadata_ref,expiry,audit_id 构造 token_auth_data。
user_user_ref : {'name': u'admin', 'domain_id': u'default', 'enabled': True, u'email': u'admin@admin.com', 'id': u'1dc0db32a936496ebfc50be54924a7cc'},tenant_ref : {'domain_id': u'default', 'description': u'Admin Tenant', 'enabled': True, 'id': u'43f66bb82e684bbe9eb9ef6892bd7fd6', 'name': u'admin'},metadata_ref : {'roles': [u'ea26bd3b3d0b4ce187ab606cd83eff69', u'4135d78453fb4975a959cd860bacdca0']}, expiry : 2015-02-08 15:41:31.064022, bind : None, audit_id: None
（23）再基于 catalog，roles 和 token_auth_data，创建 token data，创建好了以后该 token 会被保存到 persistence backend 中。 token data其内容包括：
user data，比如name，domain id，id， role names 等 tenant data，包括id，name，enabled 等。 catalog data，包括catalog 数组。比如： "endpoints": [
{
"adminURL": "http://controller:8776/v2/43f66bb82e684bbe9eb9ef6892bd7fd6",
"region": "regionOne",
"internalURL": "http://controller:8776/v2/43f66bb82e684bbe9eb9ef6892bd7fd6",
"id": "652eb96c0d2f41e0ab17f4b61a1b8ee3",
"publicURL": "http://controller:8776/v2/43f66bb82e684bbe9eb9ef6892bd7fd6"
}
],
"endpoints_links": [],
"type": "volumev2",
"name": "cinderv2" 复制代码 metadata，比如 is_admin 以及 role ids。其中，is_admin 仅仅在headers中的 token 等于 keystone.conf 中设置的 admin_token 时设置为true。 token data，比如issued_at，token id，expire 等 trust data 其中，token_id 是调用相应的 token provider 的 _get_token_id 方法生成的：
UUID：uuid.uuid4().hex PKI：token_id = str(cms.cms_sign_token(jsonutils.dumps(token_data), CONF.signing.certfile,CONF.signing.keyfile)) PKIZ：token_id = str(cms.pkiz_sign(jsonutils.dumps(token_data),CONF.signing.certfile,CONF.signing.keyfile)) 从中可见：
UUDI PKI PKIZ 的 token id 是使用 pkiz_sign 函数，使用 cert file 和 key file 对 token data 加密的结果。从下面的 code 可以看出，pkiz 生成的 token id 其实就是使用 zlib 对 PKI 生成的 token id 进行压缩，然后加上 PKIZ_ 前缀而已。其原因应该是 PKI 的 token id 太长了。供结果估计，PKIZ 能压缩 PKI 一半左右，感觉这压缩率也不高。 def pkiz_sign(text, signing_cert_file_name, signing_key_file_name, compression_level=6):
signed = cms_sign_data(text, signing_cert_file_name, signing_key_file_name, PKIZ_CMS_FORM)
compressed = zlib.compress(signed, compression_level)
encoded = PKIZ_PREFIX + base64.urlsafe_b64encode(
compressed).decode('utf-8')
return encoded 复制代码
2.2 keystone 验证及 keystonemiddleware filter
2.3 Role 和 Policy 策略 Keystone 在每个子模块的 controller.py 文件中的各个控制类的方法上实施 RBAC。有几种方法，比如：
@controller.protected()
@controller.filterprotected('type', 'name')
或者直接在函数体中使用 self.assert_admin(context)：
def get_services(self, context):
其中，protected 和 filterprotected 在 /keystone/common/controller.py 中实现。
protected/filterprotected 最终会调用 /keystone/openstack/common/policy.py 中的 enforce 方法，具体见 2.3.2 （2）中的描述。keystone 与 openstack 其它component 中的 RBAC 实现的不同之处在于 keystone 中有时候需要做 token 验证再做 policy 检查。
2.3.2 Keystone V3 API 中的 policy 操作
支持的policy 操作：
POST /v3/policies 创建一个 policy GET /v3/policies 获取所有 policys GET /v3/policys/{policy id} 获取一个policy PATCH /v3/policies/​{policy_id}​ 修改一个 policy DELETE /v3/policies/​{policy_id}​ 删除一个 policy 2.3.3 Keystone V3 API 中的 Endpoint Policy Assignment Keystone 的 V3 API 的 OS-ENDPOINT-POLICY 扩展资源提供了 API 来支持：
给特定的 endpoint 分配 policy。 REST API： /endpoints/{endpoint_id}/OS-ENDPOINT-POLICY/policy 给特定的 service 的所有 endpoint 分配 policy。 REST API：PUT/DELETE /policies/{policy_id}/OS-ENDPOINT-POLICY/services/{service_id} 给指定 region 中的指定 service 的所有 endpoint 分配 policy。REST API：GET/HEAD/PUT/DELETE /policies/{policy_id}/OS-ENDPOINT-POLICY/services/{service_id}/regions/{region_id} 支持 policy 存放在 sql db 中。
它的实现在 /keystone/contrib/endpoint_policy 中。
2.3.4 Cinder 中的 RBAC (Role Based Access Controll)
（1）使用 /etc/cinder/policy.json 文件
（2）Volume/Backup/ConsistencyGroup 等 API 类中的接口函数上的 @wrap_check_policy 或者在函数体内显式调用 check_policy(context, 'get', volume) 来判断调用用户的 role 是否满足 policy.json 中定义的要求。比如 /volume/api.py 中的 delete 方法：
@wrap_check_policy
def delete(self, context, volume, force=False, unmanage_only=False)
def wrap_check_policy(func):
"""Check policy corresponding to the wrapped methods prior to execution. This decorator requires the first 3 args of the wrapped function to be (self, context, volume) """
@functools.wraps(func)
def wrapped(self, context, target_obj, *args, **kwargs):
check_policy(context, func.__name__, target_obj)
return func(self, context, target_obj, *args, **kwargs)
return wrapped
def check_policy(context, action, target_obj=None):
target = {'project_id': context.project_id, 'user_id': context.user_id,}
target.update(target_obj or {})
_action = 'volume:%s' % action
cinder.policy.enforce(context, _action, target)
def enforce(self, rule, target, creds, do_raise=False, exc=None, *args, **kwargs):
#rule:volume:get_all
#target: {'project_id': u'43f66bb82e684bbe9eb9ef6892bd7fd6', 'user_id': u'1dc0db32a936496ebfc50be54924a7cc'},
#creds 中包括 user role 等信息
self.load_rules() #重新读取 policy.json 文件
...
result = self.rules[rule](target, creds, self) #使用特定的 rule 来检查 user 的权限
...
return True or PolicyNotAuthorized(rule) 复制代码 cinder 的 policy.json 文件片段：
{
"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' 是 API 的类别名称，比如’volume‘，’snapshot‘等。任何role的经过验证的用户都可以调用该API。
"volume:get_volume_admin_metadata": "rule:admin_api", #'get_volume_admin_metadata' 是 API 函数名称。该函数需要 is_admin:True。
"volume:delete_volume_admin_metadata": "rule:admin_api",
"volume:extend": "",
"volume:update_readonly_flag": "",
"volume:retype": "", 复制代码 如果要添加新的 role 来限制 cinder api 的话，需要（1）在keystone 中创建新的 role （2）修改 cinder 的 policy.json 文件，修改policy条件 （3）设置 user 的role 到新的role.
其它模块，比如 nova， glance 等，和 cinder 模块类似，只是区分了 admin role 和 非 admin role 的用户。
3. V3 版本 Keystone API
V3 与 V2 相比，Keystone 的 API 得到了很大的增强：
1. 增加了 Domain，Group，Policy， Catalog 等对象的操作API
2. 似乎又将 Tenant 改成了 Project
相关内容： 学习OpenStack之 (1)：安装devstack 学习OpenStack之 (2)：Cinder LVM 配置 学习OpenStack之 (3)：Devstack Screen 使用技巧 学习OpenStack之（4）：在Mac上部署Juno版本OpenStack 四节点环境 学习OpenStack之（5）：Neutron 深入学习之 OVS + GRE 之 Compute node 篇 探索 OpenStack 之（6）：Neutron 深入探索之 OVS + GRE 之 完整网络流程 篇 探索 OpenStack 之（7）：深入块存储服务Cinder （功能篇） 探索 OpenStack 之（8）：深入镜像服务Glance 探索 OpenStack 之（9）：cinder-api Service 启动过程分析 以及 WSGI / Paste dep 探索 OpenStack 之（10）：cinder-api Service 处理 HTTP Request 的过程分析 探索 OpenStack 之（11）：研究 Keystone 
/2 
京ICP备2020039040号
简书网举报电话：021-34700000
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
