有关Openstack keystone组件的理解

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了有关Openstack keystone组件的理解相关的知识,希望对你有一定的参考价值。

  Keystone(OpenStack Identity Service)是 OpenStack 框架中负责管理身份验证、服务规则和服务令牌功能的模块。用户访问资源需要验证用户的身份与权限,服务执行操作也需要进行权限检测,这些都需要通过 Keystone 来处理。Keystone类似一个服务总线, 或者说是整个Openstack框架的注册表, 其他服务通过keystone来注册其服务的Endpoint(服务访问的URL),任何服务之间相互的调用, 需要经过Keystone的身份验证, 来获得目标服务的Endpoint来找到目标服务。

openstack是一个SOA架构,各个项目独立提供先关的服务,且互不依赖,如nova提供计算服务,glance提供镜像服务等。防止耦合性,且扩展性不高实际上所有的组件都依赖keystone,

它有两个功能:

(1)用户管理:验证用户身份信息合法性

(2)服务目录管理:提供各个服务目录的(Service Catalog:包括service和endpoint)服务,无论任何服务或者客户访问openstack都要访问keystone获取服务列表,以及每个服务的endpoint


KEYSTONE基本概念

User

User即用户,他们代表可以通过keystone进行访问的人或程序。Users通过认证信息(credentials,如密码、API Keys等)进行验证。

Tenant

Tenant即租户,它是各个服务中的一些可以访问的资源集合。例如,在Nova中一个tenant可以是一些机器,在Swift和Glance中一个tenant可以是一些镜像存储,在Quantum中一个tenant可以是一些网络资源。Users默认的总是绑定到某些tenant上。

Role

Role即角色,Roles代表一组用户可以访问的资源权限,例如Nova中的虚拟机、Glance中的镜像。Users可以被添加到任意一个全局的 或 租户内的角色中。在全局的role中,用户的role权限作用于所有的租户,即可以对所有的租户执行role规定的权限;在租户内的role中,用户仅能在当前租户内执行role规定的权限。

Service

Service即服务,如Nova、Glance、Swift。根据前三个概念(User,Tenant和Role)一个服务可以确认当前用户是否具有访问其资源的权限。但是当一个user尝试着访问其租户内的service时,他必须知道这个service是否存在以及如何访问这个service,这里通常使用一些不同的名称表示不同的服务。在上文中谈到的Role,实际上也是可以绑定到某个service的。例如,当swift需要一个管理员权限的访问进行对象创建时,对于相同的role我们并不一定也需要对nova进行管理员权限的访问。为了实现这个目标,我们应该创建两个独立的管理员role,一个绑定到swift,另一个绑定到nova,从而实现对swift进行管理员权限访问不会影响到Nova或其他服务。

Endpoint

Endpoint,翻译为“端点”,我们可以理解它是一个服务暴露出来的访问点,如果需要访问一个服务,则必须知道他的endpoint。因此,在keystone中包含一个endpoint模板(endpoint template,在安装keystone的时候我们可以在conf文件夹下看到这个文件),这个模板提供了所有存在的服务endpoints信息。一个endpoint template包含一个URLs列表,列表中的每个URL都对应一个服务实例的访问地址,并且具有public、private和admin这三种权限。

public url可以被全局访问(如http://compute.example.com),端口 5000

private url只能被局域网访问(如http://compute.example.local),端口 5000

admin url被从常规的访问中分离  端口:35357

Credentials

用于确认用户身份的凭证。说白了就是“信物”,可以是:

    (1):用户名和密码

    (2):用户名跟API Kye(秘钥)              #(1)(2)用户第一次确认身份的方法

    (3):一个keystone分配的身份的token            #(3)用户已经确认身份后的方法 (token是有时间限制的)

Auhentication

    (1):用户身份验证的过程。keystone服务通过检查用户的Credentials来确定用户的身份

    (2):第一次验证身份是使用用户名与密码或者用户名与API Key的形式。当用户的Credentials被验证后,keystone会给用户分配一个Authentication token 供该用户的后续请求操作(返回的token中就包含User的Role列表)

 

Token

    (1):是一串数字字符串,当用户访问资源时需要使用的东西,在keystone中主要是引入令牌机制来保护用户对资源的访问,同时引入PKI、PKIZ、fernet、UUID其中一个随机加密产生一串数字,对令牌加以保护

    (2):token并不是长久有效的,是有时效性的,在有效的时间内可以访问资源。

Policy

    (1):对于keystone service 来说,Policy就是一个JSON文件,rpm安装默认是在/etc/keyston/policy.json。通过配置这个文件,keystone实现了对User基于Role的权限管理(User <-- Role(ACL) <--Policy)

    (2):Policy就是用来控制User对Project(tenant)中资源的操作权限

 

Project(Tenant)

    (1):Project(Tenant)是一个人或服务所拥有的资源集合。不同的Project之间资源是隔离的,资源可以设置配额

    (2):Project(Tenant)中可以有多个User,每一个User会根据权限的划分来使用Project(Tenant)中的资源

    (3):User在使用Project(Tenant)的资源前,必须要与这个Project关联,并且制定User在Project下的Role,一个assignment(关联) 即:Project-User-Role

Service 

    即服务,如Nova,Glace,等各个组件

Keystone管理对象之间的关系

技术分享

在Openstack-M版本中就使用了Keystone-V3。V3在V2的基础上引入了域和用户组的概念,将 Tenant 改称为 Project,V3将逐步替代V2。

V3的组织结构

技术分享

V3的改进

问题1:在Keystone V2中,资源分配是以Tenant为单位的,这不太符合现实世界中的层级关系。如一个公司在 Openstack中拥有两个不同的项目,他需要管理两个Tenant来分别对应这两个项目,并对这两个Tenant中的用户分别分配角色。由于在Tenant之上并不存在一个更高层的概念,无法对 Tenant 进行统一的管理,所以这给多 Tenant 的用户带来了不便。
解决:V3 利用 Domain 的概念实现真正的多租户(multi-tenancy)架构,Domain 担任 Project 的高层容器。云服务的客户是 Domain 的所有者,他们可以在自己的 Domain 中创建多个 Projects、Users、Groups 和 Roles。通过引入 Domain,云服务客户可以对其拥有的多个 Project 进行统一管理,而不必再向过去那样对每一个 Project 进行单独管理。
简而言之,Domain的引入是为了将多个Project进行封装,成为单一实体再交付给相应的一个客户使用。

问题2:在 Keystone V2中,用户的权限管理是以每一个用户为单位,需要对每一个用户进行角色分配,并不存在一种对一组用户进行统一管理的方案,这给系统管理员带来了额外的工作和不便。
解决:V3引入了Group的概念,Group 是一组 Users 的容器,可以向 Group 中添加用户,并直接给 Group 分配角色,那么在这个 Group 中的所有用户就都拥有了 Group 所拥有的角色权限。通过引入 Group 的概念,Keystone V3 实现了对用户组的管理,达到了同时管理一组用户权限的目的。这与 V2 中直接向 User/Project 指定 Role 不同,使得对云服务进行管理更加便捷。
类比操作系统中的用户组,是批量便捷操作的体现。

Keystone 和其它 OpenStack service之间的交互和协同工作:首先User向Keystone提供自己的Credentials(凭证:用于确认用户身份的数据,EG. username/password)。Keystone会从SQL Database中读取数据对User提供的Credentials进行验证,如验证通过,会向User返回一个Token,该Token限定了可以在有效时间内被访问的 OpenStack API Endpoint和资源 。此后User所有的Request都会使用该Token进行身份验证。如用户向Nova申请虚拟机服务,Nova会将User提供的Token发送给Keystone进行Verify验证,Keystone会根据Token判断User是否拥有执行申请虚拟机操作的权限,若验证通过那么Nova会向其提供相对应的服务。其它Openstack和Keystone的交互也是如此。

技术分享

本文出自 “滴水穿石孙杰” 博客,请务必保留此出处http://xjsunjie.blog.51cto.com/999372/1972092

以上是关于有关Openstack keystone组件的理解的主要内容,如果未能解决你的问题,请参考以下文章

OpenStack入门之核心组件梳理——Keystone篇

openstack组件之keystone

OpenStack——Keystone组件

OpenStack 的部署——Keystone组件

OpenStack 的部署——Keystone组件

openstack 装逼之路~keystone之HTTP协议