Openstack Keystone 服务剖析

Openstack Keystone 服务剖析

写在最前面

本文根据Openstack Grizzly版本编写，基于v3 Identity API

v3 API中租户（tenant）更名为project

v3 API的admin和service url已经合二为一v3 url

对于keystone感兴趣，第一是因为他的名字，keystone -> 拱顶石，总是让我想起《达芬奇密码》

1、概述

keystone的核心功能是为openstack系统提供统一的用户标识服务，使用户可以方便的接入openstack的其它服务（etc：compute，volume，glance），同时作为一个通用的云OS验证系统可以和已有的后端用户目录服务整合，例如：LDAP。

keystone支持多种的用户验证方式，包括：用户名/密码，token，AWS形式；另一方面，keystone还提供目录服务（catalog）的功能，为openstack系统提供一个同一个的服务注册中心，使用户和第三方系统可以通过编码的方式查找和选择需要接入的服务资源。

G版的keystone主要管理如下对象模型：user，project，role，service，endpoint，token，policy，group，domain，trust等。

从openstack系统的整体视角来看keystone提供的功能，用一句话来描述，就是，用户登录keystone，获得一个token，用此token作为一个统一标识，访问其他的计算、存储和网络等服务。围绕此中心，keystone可以分解为两个核心功能，单点登录和服务发现。

2、核心对象

user：一个使用openstack云服务的人、系统或者服务。

project：租户，一个人或者组织，直接和虚拟机、卷等资源关联。

role：用户角色，和policy配合使用。

token：一个通过keystone验证的用户标识，它的范围与user+project或者user+domain关联，根据获取的token的方式来区分。

service：compute，image，identity，volume，network。

endpoint：service的网络接入地址，具有region属性。

domain：类似命名空间，解决v2 API用户名和租户名只能全局唯一的问题。

group：用户的集合，便于给用户整体授予和取消权限

policy：对于服务的操作规则，和角色相关，可以定义哪个角色可以进行哪些操作（v3版本只增加了crud操作，没有逻辑实现替代policy.json的功能）

trust：一个用户可以通过trust将自己的role和个人信息转交给另一个用户使用

3、配置文件

keystone配置文件目录为/etc/keystone/，/etc/keystone/有如下默认配置文件

• keystone.conf keystone的核心配置文件
• logging.conf keystone的日志配置文件
• policy.json keystone的policy配置文件（v3版本API中提到集中管理policy，API和代码中都有policy的模型，但是API没有体现policy模型如何与其他的模型关联，实际的集中管理policy无法使用，个人认为后续keystone应该会把各个服务compute，volume，glance等的policy统一管理，例如和catalog中的service模型关联，在Grizzly版本中先提出一个概念）
• default_catalog.templates keystone的catalog后端配置为template模式时的catalog模板

4、认证流程

参考

上图为API v2.0对应的流程图，v3版本略有不同

1. 用户alice登录keystone系统（password或者token的方式），获取一个临时的token和catalog服务目录（v3版本登录时，如果没有指定scope，project或者domain，获取的临时token没有任何权限，不能查询project或者catalog）。
2. alice通过临时token获取自己的所有的project列表。
3. alice选定一个project，然后指定project重新登录，获取一个正式的token，同时获得服务列表的endpoint，用户选定一个endpoint，在HTTP消息头中携带token，然后发送请求（如果用户知道project name或者project id可以直接第3步登录）。
4. 消息到达endpoint之后，由服务端（nova）的keystone中间件（pipeline中的filter：authtoken）向keystone发送一个验证token的请求。（token类型：uuid需要在keystone验证token，pki类型的token本身是包含用户详细信息的加密串，可以在服务端完成验证）
5. keystone验证token成功之后，将token对应用户的详细信息，例如：role，username，userid等，返回给服务端（nova）。
6. 服务端（nova）完成请求，例如：创建虚拟机。
7. 服务端返回请求结果给alice。

5、keystone中间件

为了使token验证流程尽量通用并减少对于应用的侵入性，keystone将验证token的机制（auth_token）独立出来，封装在keystone client中，设计为Openstack wsgi标准组件，继承wsgi.Middleware，作为pipline的一个可配置的paste filter，在nova、cindier、neutron、swift、glance中都有配置，作为一个openstack单点登录（SSO）的必要组成部分，实现用户调用openstack服务时的统一鉴权认证。nova的keystone中间件配置如下：

api-paste.ini

   
   
   
   

    
    
    
    [filter:authtoken]
   
   
   
   
   
   
   
   

    
    
    
    paste.filter_factory 
    
    
    
    = 
    
    
    
    keystoneclient.middleware.auth_token:filter_factory
   
   
   
   
   
   
   
   

    
    
    
    auth_host 
    
    
    
    = 
    
    
    
    127.0.0.1
   
   
   
   
   
   
   
   

    
    
    
    auth_port 
    
    
    
    = 
    
    
    
    35357
   
   
   
   
   
   
   
   

    
    
    
    auth_protocol 
    
    
    
    = 
    
    
    
    http
   
   
   
   
   
   
   
   

    
    
    
    admin_tenant_name 
    
    
    
    = 
    
    
    
    service
   
   
   
   
   
   
   
   

    
    
    
    admin_user
    
    
    
     
    
    
    
    =
    
    
    
     
    
    
    
    nova
   
   
   
   
   
   
   
   

    
    
    
    admin_password = 
    
    
    
    nova123
   
   
   
   
   
   
   
   

    
    
    
    auth_version 
    
    
    
    = 
    
    
    
    v2.0
   
   
   
   

详细的keystone v3 API 请参考：

https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md

此API仅能作为参考，文档中的某些接口在Grizzly中并未实现，也有参数不能和例子对应的地方，需要结合keystone源代码理解