初识keystone-领域模型与安装配置

前言

OpenStack概念不多讲了，因为讲不明白。只了解过keystone，其他服务是干什么的，怎么用的，目前还没有驱动力去了解，所以就自觉闭嘴了，只贴一张比较有意思的图。

Openstack社区非常活跃，开发者很多，代码和文档更新也很频繁，最近几天看文档的过程中就发现过文档内容调整的情况，虽然官网上的文档非常多，但是感觉有点分散，加上V2和V3 版本并存，有些概念和设计在不断演进，新学者刚开始不太容易理出头绪，下面对这段时间学习keystone的一些心得做个总结。

“keystone"的中文意思是拱心石，就是石拱门上面最中间那块石头，将两边的石头塞住不会掉下来，如图：

Keystone是Openstack家庭的一个成员，在2012年的Essex版本成为核心服务，它将内部的Identity, Catalog, Token和Policy服务统一对外提供给Openstack的其他服务。两个最主要的功能一是用户身份认证以及允许用户做什么，另一个功能是为服务编目，有哪些服务可用以及它们的访问点是什么。

基本概念

Keystone的核心概念主要包括：user, project(tenant), domain，token, role, service, endpoint等，V3版本将V2 版本的tenant改名为project，同时增加了domain概念。

下面是我总结的领域模型：

• user代表一个用户，有相关联的用户名和密码以及其他诸如email等数据
• project包含了一些基础设施资源，记得有人举例说project（以前的tenant）就好比一个宾馆，里面有各种设施
• domain是V3新增加的概念，类似于命名空间，在不同的domain之间，用户名、project、group名字可以相同。但是domain和role的名字必须全局唯一
• role就是角色，比如admin，member等，名字可以随便起，叫”女王陛下“完全没问题，但是各个服务有权利自己解释角色的定义，后面会进一步说明这一点
• group似乎也是V3新增的概念，可以将用户分组，直接给group赋予权限，有GBP(Group based policy)。group在Keystone中不是必须的
• token就是令牌，用户认证通过后被分配给一个令牌，以后拿着这个令牌可以在规定的范围内活动，也就是说令牌不仅有身份信息，比如用户角色，还有作用范围，通常是project和domain；另外token还有有效期，过期失效；如果中间表现不好，还可能被提前吊销(revoke)

进一步说明一下上面几个概念的关系： role是相对的，一个用户在不同project里面可以有不同的role，在给user或者group授予role时必须指定domain或者project； domain是目前最大的概念，可以包含project，user等，在两个domain里面可以建立两套名称完全相同，但是功能各不相同的系统。

catalog就是目录或者注册表，它可以提供service的索引服务，告诉用户有哪些service以及如何找到这些服务(endpoint)。在云中，不同服务可能分布在各个角落，或者一个服务可能根据地域(region)不同提供就近的服务接入点。Keystone支持两种方式来注册catalog，一种是模板文件，另一种是SQL存储方式，前者参考Keystone源码目录中的etc/default_catalog.templates，后者需要在keystong启动后通过API来注册。

还有一个关键概念没讲到，就是policy，理解它花了我好几袋烟的功夫。下面的表述未必完全正确，但目前还讲得通。

Policy提供了RBAC(Role based access control)功能，policy是由每个服务自己来管理的，由一组rule组成， 每个service定义自己的rule。 用户访问服务提供的API时，要告诉service你是一个什么角色，但是service自己来解读role的含义。比如说英女王到了一个英联邦国家，人家一看元首来了，赶紧给你吃香的喝辣的，好酒好肉伺候着，基本上你想干啥就干啥，但是，如果女王到了一个阿拉伯国家，人家可能最多跟你客气一下，能干什么还要听人家的，甚至搞不好门都不让进，压根不欢迎你。

Keystone做的很灵活的一点就是所有后端的provider都是可配置的，用户也可以自定义provider。对于Policy，各个service默认采用oslo-incubator policy engine，它通过读取policy.json文件来解析action和role之间的对应关系，决定用户是否有权限进行相应操作。oslo-incubator的实现在openstack/common/policy.py中。

V3版本中，keystone提供了操作policy的API，数据保存在DB中，可能为今后集中控制权限做准备。但是目前，这个特性并没有真正使用。

Keystone中间件-auth_token

这个东东没有仔细研究过，这里一带而过了。

Keystone既然为各个service提供了认证服务，那各个服务怎么用呢？一种高大上的方式就是用auth_token，放到pipeline中，各个服务自己负责auth_token安装和配置。其实就是http拦截器，拦截每一个http请求，检查头部token信息，提取用户、角色等信息，如果验证通过，放行，否则拒绝请求。

认证流程

贴上随处可见的流程图，详细说明可以参阅这篇文章：OpenStack Keystone Workflow & Token Scoping

UUID&PKI

Keystone的token有两种格式：UUID和PKI。UUID是一个定长的随机字符串，PKI全称是public key Infrastructure，这个概念应该属于加密的范畴，并不是Keystone的独创的，详情请度娘或谷歌。

两种格式各有优劣，最大的不同是UUID必须每次都经过Keystone才能认证，而PKI是自包含的，service可以自己根据标准算法来检查签名，这样的好处就是提高了验证效率，Keystone不会成为整个Openstack的瓶颈。但是PKI token也带来了一个问题，因为PKI token包含了很多元数据以及catalog等信息，会很大，不仅带来了网络开销，而且可能超出一些服务器的限制，引发异常。下面就讲一下如何验证PKI签名以及解决token过大的几种方法。

插一句，昨晚写到这里的时候已经夜里12点了，突然无法保存文章，再一刷新，CSDN直接返回500，内部升级... 还好丢掉的不多，否则白码了这么多字，岂不哭死。

PKI离线验证

在测试环境中，通过keystone-manage pki_setup生成私钥及自签署证书，关于公钥、私钥、证书等概念请参考我转发的上一篇文章《CentOS6.5下openssl加密解密及CA自签颁发证书详解》，这里不再解释了。

Keystone的PKI token实际上是将包含元数据，比如用户、角色、catalog等信息的json数据用自己的私钥和CA证书来签名，用到的命令是：

openssl cms -sign -signer /etc/keystone/ssl/certs/signing_cert.pem -inkey /etc/keystone/ssl/private/signing_key.pem -outform PEM -nosmimecap -nodetach -nocerts -noattr < metadata.json

如果不用重定向，可以用-in和-out参数生成cms格式的文件。上面命令生成的密文就是token。

验证token合法性就是拿Keystone的证书以及CA的签字证书来检查，命令是：

openssl cms -verify -certfile /etc/keystone/ssl/certs/signing_cert.pem -CAfile /etc/keystone/ssl/certs/ca.pem -inform PEM -nosmimecap -nodetach -nocerts -noattr < cms_token

如果命令返回成功就能看到原始的metadata了。

但是，从Keystone API得到的token并不符合CMS标准，不能直接调用上面的命令，需要做一下转换，参考Keystone的源码：

https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/common/cms.py

def token_to_cms(signed_text):
    copy_of_text = signed_text.replace('-', '/')

    lines = ['-----BEGIN CMS-----']
    lines += textwrap.wrap(copy_of_text, 64)
    lines.append('-----END CMS-----\n')
    return '\n'.join(lines)

也就是要将原始的token做一些字符替换，加上头尾两端CMS注释，然后将token字符串按每行64个字符折叠起来。这样再调用上面的验证命令就OK了。

Token太大

这个问题在Keystone社区也有很多讨论，给出了各种方案，这里总结一下我看到的几种，供大家参考

• 改用UUID Token，废话了~
• 用PKI Token的MD5值替代原始Token放到HTTP请求header的X-Auth-Token属性中。我验证过，工作没有问题，但是就丢失了原来包含的元数据。
• 关掉catalog，给元数据减肥，验证时用这个URL：v3/auth/tokens?nocatalog
• 使用zlib压缩token，在keystone.conf中配置Token的provider为：provider=keystone.token.providers.pkiz.Provider

Keystone在Ubuntu上的安装配置

据说Ubuntu是对Openstack支持比较好的Linux发行版本，但是直接使用apt-get install安装的Keystone版本比较老，跟Ubuntu的repository有关，我后来是直接从源码安装的。

环境Ubuntu 14.04 LTS，步骤如下：

git clone http://github.com/openstack/keystone.git
python setup.py install

有些python的依赖需要提前安装，比如python-dev, python-setuptools, python-pip

安装配置mysql，Keystone默认使用sqllite，我改用mysql，更熟悉些

sudo apt-get install python-mysqldb mysql-server

配置mysql权限

mysql> CREATE DATABASE keystone;
mysql> GRANT ALL ON keystone.* TO 'keystone'@'%' IDENTIFIED BY [YOUR_KEYSTONE_PASSWORD];  flush privileges;

将Keystone源码目录etc目录下的配置文件拷贝到/etc/keystone目录下，修改一下配置文件后缀

修改主配置keystone.conf，主要改了几个地方，数据库连接、token provider、[signing]段除第一项外全部打开

•connection=mysql://keystone:[PASSWORD]@127.0.0.1/keystone

•provider=keystone.token.providers.pki.Provider

初始化数据库，执行：keystone-manage db_sync，可能又有python依赖，安装之

初始化SSL，先创建keystone用户，然后执行pki_setup

sudo groupadd keystone
sudo useradd -g keystone keystone
sudo chown -R keystone:keystone /etc/keystone
sudo keystone-manage pki_setup --keystone-user keystone --keystone-group keystone

最后启动keystone

Keystone-all [--debug]

使用命令行

Keystone有两个客户端，一个是python-keystoneclient，一个是openstack client。前者目前不支持V3的API，官方推荐用openstack client。

安装方式：

wget http://tarballs.openstack.org/python-openstackclient/python-openstackclient-0.4.0.tar.gz
sudo python setup.py install

执行openstack客户端命令时需要带一些参数，也可以设为环境变量

export OS_IDENTITY_API_VERSION=3
export OS_AUTH_URL=http://localhost:5000/v3
export OS_TOKEN=netscreen 
export OS_URL=http://localhost:35357/v3

然后就可以执行类似于：openstack user list 这样的命令了，返回结果如图

使用Curl

这里只举个例子，更多参考：http://docs.openstack.org/developer/keystone/api_curl_examples.html#

curl -i \
  -H "Content-Type: application/json" \
  -d '
{ "auth": {
    "identity": {
      "methods": ["password"],
      "password": {
        "user": {
          "name": "admin",
          "domain": { "id": "default" },
          "password": "secrete"
        }
      }
    },
    "scope": {
      "project": {
        "name": "demo",
        "domain": { "id": "default" }
      }
    }
  }
}' \
  http://localhost:5000/v3/auth/tokens ; echo

返回如图

结束语

花了两个多星期，把Keystone翻了一遍，只为技术选型。但是如果不是基于openstack，只用keystone来做一个集群应用的RBAC是否有意义，答案恐怕偏向于否定。“云”对我而言还飘在高高的天上，遥不可及，以后如果有需要会进一步研究下去。

如果上面有理解错误或者选型建议，请不吝赐教，谢谢。