随笔-132  评论-572  文章-45 

探索 OpenStack 之(13):研究 Keystone

Keystone 是 OpenStack Identity Service 的项目名称。本文就试着尽可能深入地研究 Keystone。

1. Keystone 的功能

做为 OpenStack 云系统的入口,Keystone 提供了云系统入口所需要的许多功能:

(1). 用户身份验证:系统得知道用户是不是合法的用户。为此,Keystone 需要对 user 进行管理和保存;管理用户相关的 tenant、role、group 和 domain等;用户 credential 的存放、验证、令牌管理等。

(2). 服务目录列表:用户需要知道系统提供的服务目录。为此,Keystone 得提供服务目录的管理,包括 service、endpoint 等。

1.1 Keystone 管理的相关概念

(1)User 用户:一个使用 OpenStack 云服务的人、系统或者服务的数字表示。 用户需要登录,然后被分配 token 去访问资源。用户可以被分配到一个tenant。
(2)Credential 用户证据:用来证明用户身份的证据,可以是用户名和密码、用户名和API key,或者一个 Keystone 分配的身份token。
(3)Authentication 身份验证:验证用户身份的过程。Keystone 服务通过检查用户的 Credential 来确定用户的身份。最开始,使用用户名/密码或者用户名/API key作为credential。当用户的credential被验证后,Kestone 会给用户分配一个 authentication token 供该用户后续的请求使用。
(4)Token 令牌:一个用于访问 OpenStack API 和资源的 alpha 数字字符串。一个 token 可能在任何时间被撤销(revoke),因此其有效期是有限的。OpenStack中,token 是和特定的 tenant 绑定的,因此如果 user 如果访问多个tenant的话他就需要多个tocken。
(5)Tenant 租户:一个用于分组或者隔离资源的容器。一个 tenant 可能对应一个客户、账号、组织或者项目。在 OpenStack 中,用户至少必须在一个tenant中。tenant 容器的可使用资源的限制成为 Tenant Quota,它包括tenant 内各子资源的quota。
(6)Service 服务:一个 OpenStack 服务,比如Nova、Swift或者Glance等。每个服务提供一个或者多个 endpoint 供用户访问资源以及进行操作。
(7)Endpoint 端点:一个网络可访问的服务地址,通过它你可以访问一个服务,通常是个 URL 地址。不同 region 有不同的service endpoint。endpoint告诉也可告诉 OpenStack service 去哪里访问特定的 servcie。比如,当 Nova 需要访问 Glance 服务去获取 image 时,Nova 通过访问 Keystone 拿到 Glance 的 endpoint,然后通过访问该 endpoint 去获取Glance服务。我们可以通过Endpoint的 region 属性去定义多个 region。Endpoint 该使用对象分为三类:

  • adminurl 给 admin 用户使用
  • internalurl 给 OpenStack 内部服务使用来跟别的服务通信
  • publicurl 其它用户可以访问的地址

比如创建一个使用不同 IP 的 endpoint:

$ keystone endpoint-create \
 --region RegionOne \
 --service-id=1ff4ece13c3e48d8a6461faebd9cd38f \
 --publicurl='https://public-ip:8776/v1/%(tenant_id)s' \
 --internalurl='https://management-ip:8776/v1/%(tenant_id)s' \
 --adminurl='https://management-ip:8776/v1/%(tenant_id)s'
然后你可以配置 OpenStack service 使用另一个 service 的 endpoint 的 internalurl 去访问另一个资源。

(8)Role 角色:一个 role 可看着一个ACL的集合。Keystone 中,分配给用户的 token 包含了 role 列表。被访问的服务会判断访问它的用户的角色,以及每个role访问资源或者操作的权限。系统默认使用 admin 和 _member_ role。User 验证的时候必须带有制定的 tenant,roles 会被分配到指定的 tenant。

(9)Policy 策略:OpenStack 对用户的验证除了 OpenStack 的身份验证以外,还需要鉴别用户对某个服务是否有访问权限。Policy 机制就是用来控制某一个 User 在某个 Tenant 中某个操作的权限。这个 User 能执行什么操作,不能执行什么操作,就是通过 policy 机制来实现的。对于 Keystone 服务来说,policy 就是一个json 文件,默认是 /etc/keystone/policy.json。通过配置这个文件,Keystone Service 实现了对 User 的基于用户角色的权限管理。

这些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].Provider
credential 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 代码结构 

Keystone 的代码结果和 OpenStack 的其它组件一样,非常有层次感:

(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 之(11):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 服务启动

/usr/bin/keystone-all 会启动 keystone 的两个service:admin and main,它们分别对应 /etc/keystone/keystone-paste.ini 文件中的两个composite:

[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

可见 admin service 提供给administrator 使用;main 提供给 public 使用。它们分别都有 V2.0 和 V3 版本,只是目前的 keystone Cli 只支持 V2.0. 本文的分析以 V2.0 为对象,最后会看看两个版本你的区别。比较下 admin 和 public:

名称 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 的 token id 只是一个纯粹的32位十六进制字符串
  • PKI (Public Key Infrastructure) 的 token id 是使用 cert file 和 key file 对 token data 加密的结果
  • 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

客户端在调用 POST /tokens 后拿到返回结果,如果用户名和密码验证成功,则拿到诸如user,tenant,token,metadata,catalog等数据。从 catalog 中找到要访问的 service 的 endpoint 的 URL,然后在 headers 中放入 {X-Auth-Token,token id},就可以访问该 service 了。service 的 WSGI App 在收到该 Request 后,首先要验证该 token id 是否有效,该验证一般都使用一个 keystonemiddleware 的 middleware filter 来完成,其 AuthProtocol.__call__ 是处理Request 的入口函数。其处理过程大致如下:

这篇文章 understanding-openstack-authentication-keystone-pki 仔细分析了UUID/PKI/PKIZ token id 的生成和验证过程。 

2.3 Role 和 Policy 策略

上面 2.1 和 2.2 只是验证 user 的 credential,至于 user 有没有权限来执行某个操作则取决于 Role 和 基于 Roles 的鉴权。每个 OpenStack 组件分别实现了鉴权功能,Keystone 和 其它组件中的实现有一些不同。

Keystone API V3 与 V2 相比,对 policy 的支持有很多的增强。V2 的支持和 OpenStack 其它组件比如cinder,nova 等差不多,只支持基于 policy.json 文件的 policy 控制;而 V3 中,支持对 policy 的 CURD 操作,以及对 endpoint,service 等的 policy 操作等。

2.3.1 Keystone 中的 RBAC (Role Based Access Controll)

Keystone 在每个子模块的 controller.py 文件中的各个控制类的方法上实施 RBAC。有几种方法,比如:

@controller.protected()
def create_region(self, context, region)

@controller.filterprotected('type', 'name')
def list_services(self, context, filters)

或者直接在函数体中使用 self.assert_admin(context):

def get_services(self, context):
    self.assert_admin(context)
    service_list = self.catalog_api.list_services()
    return {'OS-KSADM:services': service_list}

其中,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": "",

这篇文章 HAVANA KEYSTONE中policy.json的解析过程 详细分析了该 enfore 过程。

如果要添加新的 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

 

posted on 2015-02-10 14:11 SammyLiu 阅读(...) 评论(...) 编辑 收藏