OpenStack关键技术系列: KeyStone鉴权认证系统详解

转载自：https://mp.weixin.qq.com/s/tsmAJa9TF7IqDlMaECbpbQ

 今天，我们深入到每一个服务组件详细的来说说OpenStack了，接下来还是从比较重要的Keystone组件服务说起。

 

 

      先来举几个平时能够看到的例子:

 

业务系统认证示意图

 

      上面的这个图所示的一般常用于企业多个业务系统的模型认证。用户端访问不同的业务系统，采用不同的username和password，每个业务系统有独立的用户信息库。这样多个的业务系统认证缺陷也是显而易见的，用户信息的维护以及统一认证和权限控制都面临着问题。

 

统一认证业务系统示意图

 

      上面的这个图是针对前一者，将各个业务系统的用户信息进行集中，这样各个系统就可以去一个地方去取用户信息而在本地去做对比验证用户正确与否。这样虽然解决了一部分用户信息维护和统一管理的问题，但是还是存在各个业务系统之间”各自为政”自己进行独立权限控制，无法进行统一标准的权限管理控制。

 

 Openstack架构组件认证流示意图

 

       在来看keystone方式，上一篇文章说过了，openstakc整体架构也是遵循着”高内聚、低耦合”设计的，组件内部相关部件关联形成组件的功能，组件之间有标准的Endpoint可以直接调用。

 

      而Openstack整体与多个业务系统整体也不太一样，拿上图来说，每个Openstack服务组件就相当于一个业务系统，比如:nova-OA系统、glance-ERP系统、neutron-CRM系统，可以完成相应的操作。

 

      Nova维护虚拟机的生命周期，虚拟机创建、启动、重启、注销、删除等等；Glance维护虚拟机原生镜像，Windows Server 2008 R2、RHEL7、Centos 6等等。

 

      Neutron则维护着关于虚拟机全部的网络信息，比如:私有网络，子网划分，ACL等等。但同时不一样的一点是，企业的各个业务系统之间其实是可以互相独立完成一个企业业务的信息流整合，两者之间可以没有任何关系(可以仔细看看图1和图2红色字体)

 

      而Openstack的各个组件之间则不是这样，单独的使用keystone、nova、glance、neutron是不可以的，因为这些组件是依托整个openstack工程架构存在的，属于强关联，无法单独使用。

 

      当然了，你可以单独的选择每一个服务组件的底层实现技术，将其挑选出来而进行相关Coding研发成产品对市场推广也是可以作为云的解决方案的，比如我上一家公司，就是将维护虚拟机生命周期管理的计算虚拟化使用开源的KVM、而维护虚拟机数据的分布式存储使用开源的GlusterFS、解决虚拟机跨物理节点通信则使用VxLAN技术，以上的这样也是可以的。但是，我们不能说单独的使用nova做一个服务器虚拟化产品，这样是错误的。

 

      所以，在整体有强关联性的组件之间，要实现3A(认证Authentication、授权Authorization、计帐Accounting)则就是keystone在整体openstack工程架构出现的意义了。

 

      从上图中可以看到，用户首先提交的是用户名和密码(图中绿色标记)，然后Keystone返回Token凭证(图中绿色标记)，然后从用户发出创建VM虚拟机一直到VM创建完成的全部过程中，使用都是使用Token凭证进行用户身份认证与权限控制(图中橙色标记)，同时每次均为各个服务组件去跟Keystone请求验证(图中灰色标记)，对于前端用户来说完全透明。

 

      而新建虚拟机是由nova服务组件主要负责操控，所以nova会向相关的服务组件发出相关操作请求(图中蓝色标记)，以此来完成虚拟机创建的任务。

 

      以上为keystone的简单介绍，下面我们详细的说道说道。

 

Keystone发布时间

 

      首先keystone是在openstack的Essex版本正式推出的，一直沿用至今，基本的作用总结一句话就是：用于为其他组件提供统一认证服务，包含身份验证、令牌发放和校验、服务列表、用户权限定义等。

 

      而在openstack整体架构中有很多关于keystone的基本概念，比如: User、Credentials、Authentication、Token、Tenant、Service、Endpoint、Role。

 

      详细内容，可以参考下面的思维导图。

Keystone基本概念关键词思维导图

 

      接下来举一个创建虚拟机VM的例子，来简单的认识一下keystone的大概流程，请看下图。

 

keystone的workflow示意图

 

• 1.User发送相关认证信息，一般是用户名和密码。

• 2.Keystone在自身的Mysql(默认情况会采用mysql进行用户信息存储)中查询，发现含有正确的用户名和密码。则返回该对应用户的凭证Token。

• 以上步骤如果是GUI操作，则为登录成功后显示到控制台界面了。

• 3.User发出创建VM虚拟机操作，在后台其实是将创建的请求+Token一起发送给Nova节点。

• 4.Nova在后台与Keystone沟通，一问Token是否正确，二问该Token是否有权限创建VM。

• 5.以上如果验证通过后，则Nova会与Glance通信，发出请求原VM镜像请求，同样在这个后台通信过程中，也是带有Token通信的。

• 6.Glance发现Nova发出的调用镜像请求后，则会从请求数据包中同时取到Token，这时会向keystone服务组件发去效验，一问Token是否正确，二问是否有使用权限。

• 7.确认没问题后，Glance调取并推送镜像给Nova，这时Nova可以根据原镜像进行复制克隆创建出来一个新的*.qcow2镜像给虚拟机使用。

• 8.下面Nova同样需要给新的虚拟机配置一些网络周边的信息，所以一样将请求发送给Neutron。

• 9.Neutron拿到该请求后，则做同样验证操作，向Keystone沟通，一问Token凭证是否正确，二问Token是否有权限创建网络相关内容。

• 10.经Keystone确认没问题后，Neutron进行相关网络操作，而后向Nova服务组件上报操作完毕。想在这里说一下的是，以上这部分操作全部是我们在控制台上，点击确认提交创建要求后，后端自动发生的一系列行为，最终我们在前端这部分是看不到的。

• 11.Nova组件服务，在控制台GUI页面显示创建完成，至此用户User可以得知虚拟机创建完成。这步是最后创建虚拟机完成后最终在控制台的GUI页面上面表示出来的，也即为虚拟机成功创建完成。

 

      在整体的Keystone流程中，很有可能出现的两个Error错误:

 

keystone内部认证流程示意图

 

• 1.如果User发出的请求Token在Keystone验证无效后，则显示401错误代码。

• 2.如果Token有效，但是Keystone无法提供服务，则显示503错误代码。

 

      总结一下: 其实在openstack整体认证过程中，只要很好的理解Token凭证认证就很好的理解整体的3A控制了，简单一句话就是KeyStone根据用户提供的信息，返回Token凭证，以后在用户任何的操作过程中，均有Token凭证代替传统的Username/Password，以此来避免多次用户敏感信息的交互，增加安全性。

 

      同时Token的工作方式能够很好的满足openstack各个组件强关联之间的认证和权限控制，使得整体架构在用户身份鉴别方面设计的不必过度复杂，使得整体架构更加”松耦合”。

 

      再来看看实际应用，我们拿一些公有云先来看看，下面是阿里云和百度云的截图示例:

 

阿里云AK/SK生成页面

 

百度云AK/SK生成页面

 

      我相信众多的IT大佬们在玩公有云的时候，多多少少会用到AK(Access Key)/SK(Secret Key)，类似上面的截图，目前基本上公有云厂商都应该具备，如果连这个都没有，那可以认为这个公有云做的真心一般还没有能够提供对外服务API接口的能力。

 

阿里云API产品文档

 

百度云产品文档(Endpoint地址)

 

百度云产品文档(API使用须知)

 

      我们登录到各个公有云Console控制台后，创建的AK/SK其实就是手动生成Token凭证的过程，然后可以对接各个服务组件的API Web访问的Endpoint地址就可以对接该平台的公有云了，AK/SK实现用户认证与权限控制，Endpoint实现远程后台接入，两者叠加就可以操作云平台了，我相信以后的混合云也应该是走这个方式与各家的公有云进行对接。