OpenStack 学习笔记 （一）

后续的文章都贴在：臭蛋上

这一系列笔记已经记录很长一段时间了，种种原因没有贴出来，现在陆陆续续的贴出来。可能由于自己理解的

错误和疏忽，导致存在错误，欢迎大家指正，交流。

所有的源码分析都是基于OpenStack Folsom版本。

参考文档：http://hi.baidu.com/chenshake/item/184767c22c1231ba0d0a7bc7

参考文档：https://www.ibm.com/developerworks/community/blogs/e93514d3-c4f0-4aa0-8844-497f370090f5/entry/openstack_keystone_workflow_token_scoping?lang=zh

这篇博客的前半部分基本上参照ibm（链接如上）的内容。

在理解OpenStack 授权机制之前，先明白其中的一些基本概念：

1. User： 所谓的User代表着一些人或者能够通过keystone获取访问的something。User通过自身的证书例如username & password 或者 api keys来访问服务。
2. Tenant：Tenant代表nova中的一个project，就是能够聚合一些服务中的一些资源。例如，一个tenant能够有一些nova中的虚拟机，glance中的一些images，quantum中的一些networks，users默认的绑定到某个tenant中。
3. Role：代表一组用户能够一定程度的访问资源。例如能够访问nova中的vms，glance中的images。Users能够被添加到所有的tenants中或者某个tenant。用户就获取了对相应tenant中对应角色获取的访问资源的权限。
4. service： 某类型的服务，例如nova， quantum， glance等等都是服务
5. endpoint: 访问服务的入口点，一个http路径。例如：catalog.RegionOne.image.internalURL = http://10.10.102.14:9292，可以通过此URL访问image服务

接下来，分析用户在访问一个服务的过程中，keystone都做了哪些工作，整个过程描述如下：

1.　获取token

      首先，需要确认你将访问那个tenant，必须使用keystone来获取一个unscoped token（意味着这个token没有和特定的tenant绑定），这个unscoped token能够用来深入查询keystone service，确定你能访问哪些tenants。获取一个unscoped token，使用典型的REST API，在request的body中不指定tenantName。例如：

　　经过成功的验证，返回的response大致如下，其中的token id就是获取到的unscoped token（访问路径：/access/token/id），token id 将被在下一次的请求中作为X-Auth-Token的值，用来标识身份。

2.　获取tenants

　　接下来的一步是，使用unscoped token来获取能访问的tenants，其中租期已经由你分配的角色决定了，对于每个tenant，都有一个确定的角色。所有在service endpoint上执行的操作都需要一个scoped token。获取能访问的tenants，使用 GET /tenants keystone API，其中将unscoped token写入X-Auth-Token。例如：

　　返回的响应如下：

　　这是一个tenants数组，包含了能够访问的tenants。

3.　获取scoped tokens

　　获取了能够访问的tenants之后，决定访问某个tenants，就开始需要获取一个scoped token，这个scoped token与某个特定的tenant绑定，能够提供这个tenant的metadata和在tenant中的角色。获取scoped token需要使用POST /tokens keystone API，像第一步一样，这有两种形式的API。

　　1. 使用第一步中一样的request body，传递user id 和 credentials，还指定tenantName

　　2. 使用包含unscoped token和tenant name的request body，这样无需再post credentials。

　　在返回的response中，包含一个scoped token和相关的metadata。

　　更重要的是，其中包含了一组service endpoints。这些endpoints 确定了获取的token能够访问的服务，Keystone service manage都是基于service/endpoing catalog的.通过这些endpoings，决定访问其中的service。

　　关于keystone 管理的endpoint/service catalog：

　　l  Keystone管理了一些的service，这些service在keyston的service catalog中定义了，定义方式大致是，type，name，description

　　l  在service catalog中，endpoint包含了region中一些基本的URL。

　　l  每个endpoint与一个service关联。

　　l  Endpoint url都是base urls，作为api方位的前缀。

4.　获取scoped tokens

　　现在已经获取了scoped tokens，并且知道了endpoint API的url，下一步就是调用这些service endpoint。在这一步，使用keystone来确证token的有效性。存在两种类型的token，一种基于UUID的，一种基于PKI（Public Key Infrastructure）。

　　l  UUID  Keystone 将维护一个token的UUID到他们的metadata和有效性的索引，token id没有携带嵌入的metadata，则endpoint service将调用keystone的service，应用这个token id的有效性，keystone将会返回这个token所相关联的metadata，包括角色，tenancy（租期），能够用在处理api请求的内部使用，endpoint service会为每个api request去调用keystone服务验证有效性。

　　l  PKI  PKI使得endpoint service不需要每次api request都进行调用keystone验证token的有效性。PKI使用public/private certificate pair，基于X.509 技术。Keystone 拥有Public private certificate。任何人都能通过REST API获取到public certificate，private certificate只能keystone拥有。当使用PKI，第一次使用endpoint service时，endpoint service将请求keystone的public certificate，并且保存起来。使用PKI模式，keystone将会创建json格式的对象，包含token的metadata，使用private certificate来加密token，再使用MD5来为加密的token创建指纹，这样的token将作为第三步中token ID返回，这样token ID包含了metadata而不仅是一个UUID字符串。Endpoint service将会确认签名，使用public certificate解密token。这样，token包含所有的metadata了，endpoint service不需要再去找keystone获取这些信息。

能够在keystone.conf配置文件中配置token_format.

5.　验证role metadata

　　Endpoint service 使用token的metadata来验证用户能够访问请求的服务。这一般都涉及到Role Base Access Control(RBAC)。基于服务的policy.json文件，使用rule engine来决定用户的token包含适当的角色访问。

6.　service API request

　　到此，user就能够去通过api访问有权限访问的资源。

　　 有了上面基本知识，下面结合具体的代码粗略的描述上面的流程。

　　从最开始的shell命令行开始，譬如，nova list命令，但在使用命令之前，我们需要配置一下环境变量：

　　将这些参数配置正确，便能够正确的执行nova list命令了。从nova 命令启动之后，python-novaclient 的main函数首先获取一个base parser，用来解析命令行，在获取这个base parser的过程中，就会添加参数，例如os-username等等，并且设置其默认值为，从环境变量中读取出来的值。例如下面的os-username

　　接着，从命令行参数中去获取os_username,os_password,os_tenant_name,os_auth_url,endpoint_type等等和授权相关的参数，有些参数如endpoint_type为空，则获取默认的，若os_username，os_password，os_auth_url都为空，则命令报错。

如果endpoint_type是空的，则读取默认的值publicURL，前面介绍过service endpoint type的类型，有三类，publicURL,adminURL,internalURL。若service_type为空，则读取默认的值compute或者通过命令具体执行的命令是属于什么类型的service来确定。（在定义一个命令行将调用的函数时，可以为它添加装饰器，指定所属的service）

　　譬如通过命令 nova volume-list,就会获知service_type为volume，而不是默认的compute。

然后，从auth_url指定的服务中获取授权，程序运行到这儿之后，就到了前面介绍的第一步了，获取tokens，并且在body中指定了tenantName。

　

　　在返回的body中，就已经获取了所有的service catalog，根据service_type，endpoint_type则可以生成management_url.http://10.10.102.31:8774/v2/eacac8f7935348c7a6aa3ea6fe54e18c，此url则是访问nova compute服务的base url。然后在此url基础上，加上命令的具体参数，就访问此URL的服务--nova compute。

　　nova compute接受到此请求之后，会验证次请求，然后完成请求。