Mitaka版OpenStack的授权管理分析与研究

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

Mitaka版OpenStack的授权管理分析与研究

杨灿;李秦伟;叶延婷

【摘要】研究分析Mitaka版OpenStack云平台的访问控制机制、用户及角色管理模型,针对其缺乏层次管理、云用户缺乏授权等问题,在默认的OpenStack授权

策略基础上,提出加入区域管理员角色,并修改授权策略文件,赋予角色相应的权限.实验结果表明,区域管理员角色与设定的权限关联成功,用户可通过扮演该角色获得相

应的管理员权限,对OpenStack在实际中的应用具有参考价值.

【期刊名称】《电子科技》

【年(卷),期】2017(030)005

【总页数】4页(P158-161)

【关键词】OpenStack;RBAC;授权管理;区域管理员

【作者】杨灿;李秦伟;叶延婷

【作者单位】贵州大学大数据与信息工程学院,贵州贵阳550025;贵州大学计算机

科学与技术学院,贵州贵阳550025;贵州大学计算机科学与技术学院,贵州贵阳550025

【正文语种】中文

【中图分类】TP311

OpenStack是由NASA和和Rackspace合作研发的开源云计算[1]平台管理项目,作为IaaS 层的云操作系统,OpenStack为虚拟机提供并管理3大类资源:计算、网络和存储,目前第13个版本Mitaka已于2016年4月发行。本文主要以

VMware Workstation10作为虚拟机容器,以ubuntu-14.04.2-server-

amd64.iso为底层操作系统,参考OpenStack官网的指导说明搭建了基于Mitaka版本的OpenStack私有云平台[2-4],在此基础上对其授权管理进行分析

研究。

OpenStack是一个分布式系统,可由若干不同功能的节点组成。在本次实验环境中,手动部署了控制节点controller1、计算节点compute两个核心节点,每一

个节点都是由单独的虚拟机完成,云平台的搭建过程在本文中不做详细介绍,仅对部署的两个节点简要说明。控制节点作为OpenStack的主控节点,主要安装了keystone、nova、glance、neutron以及dashboard等模块,计算节点上则主

要安装了nova和neutron模块。

1.1 用户身份认证及管理

在OpenStack云平台中,负责用户管理及认证的是核心组件之一的keystone[5]。该服务通过检查用户的credential来确定用户的身份,credential是由用户名/密码或者用户名/API key组成,keystone验证通过后会给用户分配一个具有一定有效期的token供后续请求使用。

在Mitaka版本中,keystone组件由原来的V2版API替换为V3版API,支持域的创建和添加,域的实现对于租户可进行更细粒化的管理,域的管理员可以通过仪表盘接口或者命令行创建项目、用户、群组和分配角色等。现有的OpenStack用户管理模型如图1所示。

从图中可以看出,一个项目只属于一个域,一个用户可以属于多个项目,一个项目可以有多个用户,具有不同的角色。此外,OpenStack也支持用户组的创建,但

在Web界面[6]只能为组添加用户,无法管理权限,管理员需要使用命令行给用户组赋予某一角色,进而赋予一定权限。域管理员作为全局用户,负责项目、用户、云资源等的管理,当云用户数量越来越多,身份关系也会越来越复杂,现有的管理

模型显然加重了域管理员的负担,不能够满足实际需要。

1.2 OpenStack授权

OpenStack默认的授权设置只允许管理员创建项目资源,主要有两种类型的授权策略,一种是以操作为主,指定访问特定的操作标准,另一种是以资源为主,对特定资源的访问进行授权[7]。当前OpenStack云平台中,默认有超级管理员、普通用户这两种角色,通过各组件中的policy.json来实现基于角色的访问控制[8-9](Role Based Access Control, RBAC)。但与其余组件不同的是,keystone中的RBAC 实现根据需求要做token 验证,再做 policy 检查,其请求处理过程如图2所示。keystone对用户名和密码进行验证,若成功则返回用户令牌token。用户发送访问请求,验证其令牌的有效性,返回结果与token相关的metadata,其中包含的service endpoints 决定了获取的token能够访问的服务。用户有没有权限执行该服务取决于 role 和基于roles 的鉴权,即policy.json策略文件。

在身份服务中,token包含用户能承担的角色列表,以及每个角色可以访问的资源或进行的操作。policy.json由应用程序编程接口API负责调用并校验的,用户向API请求后,API通过token获取用户的role、project等信息,调用源码文件keystone/policy/backends/rules.py中部分代码。

class Policy(policy.PolicyDriverV8):

def enforce(self, credentials, action, target):

LOG.debug(’enforce %(action)s: %(credentials)s’, {’action’: action,

’credentials’: credentials})

enforce(credentials, action, target)

其中enforce(credentials, action, target)函数定义为:

def enforce(credentials, action,target,do_raise=True):

init()

相关文档
最新文档