深入理解Keystone 认证

最近在搞keystone，学习一下keystone的几种认证方式：UUID， PKI。

 

UUID 认证流程

 

1．用户输入用户名密码，发送给keystone。Horizon登陆时候输入的用户密码或者CLI中的source的用户名密码环境变量。

2．Keystone验证用户名密码，并且生成token（UUID），发送给客户端。

3．客户端缓存UUID token

4．客户端发送具体的执行请求（nova boot）和UUID给keystone。

5．Keystone从http请求中获取token，并检查token是否有效

6．Token有效，处理请求，并返回客户端请求结果

7．Token失效，拒绝客户端请求，返回401。

 

PKI认证

通过keystone-manage pki_setup生成私钥及自签署证书。

 

对与pki（包括pkiz）认证方式，keystone相当于一个权威的认证中心，他用自己和的私钥证书对用户的token进行签名。 OpenStack服务中的每一个API Endpoint都有一份keystone签发的证书，失效列表和根证书。API不用在直接去keystone认证token是否合法，只需要根据keystone的证书和失效列表就可以确定token是否合法。但是这里还是会有每次都需要请求keystone去获取失效列表的操作，不可避免。

 

 

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

 

PKI认证流程大部分和UUID相似，可以对比上边两个图。只有下边几处不相同。

1) CMS格式的token

CMStoken包含三部分：service catalog，user role 和metadata。实例如下：

{
   "access": {
       "metadata": {
           ....metadata goes here....
       },
       "serviceCatalog": [
           ....endpoints goes here....
       ],
       "token": {
           "expires": "2013-05-26T08:52:53Z",
           "id": "placeholder",
           "issued_at": "2013-05-25T18:59:33.841811",
           "tenant": {
               "description": null,
               "enabled": true,
               "id": "925c23eafe1b4763933e08a4c4143f08",
               "name": "user"
           }
       },
       "user": {
           ....userdata goes here....
       }
   }
}

2) Token的验证

Token的验证包含三个方面：token的签名，token是否失效和token是否已经在撤销列表。

用openssl cms -verify -certfile /tmp/keystone-signing-nova/signing_cert.pem -CAfile /tmp/keystone-signing-nova/cacert.pem -inform PEM -nosmimecap -nodetach -nocerts -noattr < cms_token命令验证token签名。

根据expiration date判断token是否失效

向keystone查询token是否已经在撤销列表。

 

 

Openstack相关技术交流请加群：314889201