云计算的鉴权和租户管理

[e-mail] 

黑米老爸
欢迎转载，转载请注明出处

前言

   研究openstack算起来有三年多了，接触过计算、网络、存储，一直在打酱油，虽然对openstack的代码还算了解，但对于架构、对于需求、对于openstack背后的实现原理，从没有深入的去研究过。借这次做系统设计的机会，去静下心来研究云计算、研究openstack。记录总结下来，有些东西可能理解的不对，希望各位大牛能在评论中留言指正。

1、鉴权和租户

1.1 鉴权

        鉴权很好理解，作为一个系统，需要进行权限的鉴别，来保证整个系统和服务的安全。云计算由于系统庞大、服务多、分布式，所以鉴权一般都采用统一鉴权设计。采用鉴权控制中心架构来对外来请求进行鉴权。

1.2 租户

     云计算平台的最重要的本质是什么？资源管理和分配，将所有的物理资源通过一定的手段收集起来统一分配给用户使用。对于用户来说，感知不到资源的收集和管理，资源按需申请。 

   对于云计算来说，无论是私有云还是公有云，都会有大量对资源不同需求的用户，我们称这样的用户为租户（tenant），即申请资源的最小单位。

2、云计算的租户管理

2.1 云计算的租户需求

• 公有云：

　　租户自助申请和注销

　　租户资源的限制

　　租户和租户之间的资源隔离

　　租户级别的资源监控

　　租户级别的计费

　　租户下用户的管理

　　租户下还可以提供虚拟的租户（VPC）

• 私有云：

　　私有云的规模要远远小于公有云，实际上公有云的租户管理适用于私有云，但往往为了简化管理，

　　私有云不提供以下功能：

　　租户级别的计费

　　租户下虚拟租户的功能（VPC）

　　

　　总结起来两个方面：

　　权限管理

　　资源管理

3、openstack认证管理

     Openstack由于项目庞大，组件众多，为了方便管理，使用统一的认证管理和服务管理。Openstack的服务管理和权限管理都是基于keystone来实现的。首先介绍一下keystone的功能。

3.1 keystone作用

  Keystone主要功能为两方面：
　 1. 判断用户合法性
  2. 提供服务列表和服务地址

3.2 keystone中的概念

  Tenant
　 租户。即一个资源申请的最小单位，可以对租户进行配额限定，包括CPU、内存、存储资源等。
  Role
　 角色。配置给user的权限。分为admin和非admin角色（实际上可以为一个字符串）。
  User
　 User即我们说的最终用户（ps：最终用户不仅仅指一个操作用户，也可以是一个分布式应用程序）。User将会调 用API进行一系列操作，申请资源等。所以需要将user划归到租户下，同时要给其加上role以限制其操作权限。
　 User在keystone中是独立创建的，但是必须绑定tenant和role才能使用，一个user可以同时绑定多个tenant和role。
  Token
  令牌。每一个user去请求API时，首先需要鉴权，每次都用带用户名和密码吗？为了安全，同时也为了简便，使用token机制。token是     user向keystone获取的，user第一次使用用户名和密码获取token，使用此token可以向各个服务发送API请求，由各服务再向keystone确认token的有效性。当然，token是有时效性的，过期了就不能用了。
  Service
　 服务。Keystone提供系统服务目录。所以新加的服务都需要在keystone注册，这样可以很方便的查询目前可提供的服务。需要注册的内容包括：服务名称和服务地址。
Endpoint
　 Endpoint

  即服务地址。Keystone又把其划为内部服务地址（private url）和外部服务地址（public url）。
  关键的两点：1) User从Keystone获取令牌、服务列表和服务地址；
          2) User访问服务时，亮出自己的令牌。相关的服务向Keystone求证令牌的合法性。

3.3 用户合法性校验

• 流程详解：

   1. User根据用户名和密码向keystone获取token；
   2. User访问API（例如创建虚拟机），在request中带入token；
   3. Nova收到token后，首先会去keystone对token验证；
   4. 验证成功，继续后续流程；
   5. 要获取image时，glance会将token拿去验证；
   6. 获取网路时，quantum会将token拿去验证；
   7. 流程走完，nova返回successful

   总结来说，token服务于整个流程。

3.4 服务列表管理

      Openstack服务众多，并且可以部署在不同的服务器上，所以需要一个统一的服务管理。Keystone提供了一个服务列表和服务地址管理。
　　例如：
　　计算服务部署在192.168.0.1服务器上，网络服务部署在192.168.0.2服务器上，对于用户来说，要访问计算服务，就得使用计算服务的IP地址，访问网络服务，使用网络服务的IP。如果没有一个统一的服务管理，用户需要记录服务列表和各个服务地址。导致用户上层设计复杂。
　　Openstack提供的服务管理，能够使用户访问一个地址就能获取所有服务列表和地址。
　　具体流程如下：
　　用户向keystone获取token；
　　Kestone返回token给用户，同时消息中的catlog带有服务列表和地址信息；
　　用户获取catlog，从而获取服务列表和地址；
　　用户根据服务地址进行访问

4、Openstack权限和租户管理

4.1 访问权限管理

　 访问权限分为两部分理解：
　 1. API访问权限
　 2. 访问范围权限

• Policy的介绍

  openstack通过keystone用来完成authenticate（认证），真正的鉴权（authorize）是在各个模块分别做的，具体实现为每个模块都有一个policy文件，叫policy.json，里面定义了鉴权用的rules。
  以nova为例，policy文件的位置在：/etc/nova/policy.json，下面先来看几条rules，了解其基本含义：   

   "compute:create": "",                         "compute:create:attach_network": "",            "compute:create:attach_volume": "",             "compute:create:forced_host": "is_admin:True",

   语法规则为：rule:[result]
    rule：指这条规则是干啥的，通常对应一个action，以类似scope:action的形式给出，scope表示作用范围，action表示执行哪种操作
    result: 表示这条rule的判定结果或者如何进行判定，比如"compute:create:forced_host": "is_admin:True",如果执行此操作的用户具有admin角色（role），则这条结果的判定结果就是True，表示可以访问。实际生产环境中，根据不同服务需求，还可以加入tenant的自动匹配比较，由于这块还没研究透，后续再补充。
    另外，rule是可以嵌套的，比如"compute:stop": "rule:admin_or_owner",表示compute:stop这条规则的结果为admin_or_owner这条规则的结果，而admin_or_owner规则如下：
    "admin_or_owner规则如下：
    "admin_or_owner": "is_admin:True or project_id:%(project_id)s",
    如果调用这个操作的用户的角色是admin，就返回True，或者返回用户所属的project的id.

• policy框架访问流程

   1. 用户访问服务API；
   2. 服务根据policy框架（具体代码见附件），读取policy.json文件；
   3. 根据policy.json文件来进行API的访问控制和访问范围。

4.2 租户管理

   租户是申请资源的最小单位，同时也是资源隔离的最小单位。所以，对于整个系统来说，需要对每个租户的资源进行限制，以避免资源的无限消耗。
   1、租户申请和注销
   初始使用超级token创建一个超级管理员用户，使用这个用户去创建租户和注销租户。

   2、配额

           Openstack提供了API去修改配额，默认的配额在初始配置中配置。

   

   3、用户管理

   Openstack提供了API去绑定用户和租户，一个租户内可以有多个用户，同时，一个用户也可以加入多个租户。用户只有绑定了租户才能够对服务进行操作，任何一个虚拟机实例一定都属于某个租户。