【摘要】本文介绍了Ansible Tower的权限管理及其使用方法,先从Ansible Tower的权限管理使用对象和权限控制对象介绍入手,通过引入一个场景,实战演示了Ansible Tower的权利管理逻辑及使用方法,文章末尾总结了Ansible Tower权限管理的要点,适用于熟悉Ansible但还不太了解AnsibleTower的读者

【作者】ManMaster,就职于某国有大行数据中心,拥有三年x86平台Linux系统的运维管理经验,熟悉Linux系统管理及Ansible自动化工具。


一、Ansible tower介绍

Ansible Tower是企业级的自动化运维平台,ansible自动化工具的改良和升级版,具有许多ansible自身并没有的如web图形化展示,权限管理,REST API,日志审计,计划任务等功能和特性。

Ansible Tower的特点:

  • 一键执行任务和计划任务

    通过Tower的Web界面可以点击鼠标来轻松触发任务的运行。

  • 基于角色的访问控制

    不同用户拥有不同的访问资源的权限,可以设置某些项目为自己可见。

    所有的用户密码等信任关系都是加密保存。

  • 任务面板实时显示

    Tower的面板提供ansible任务的实时运行信息。

    显示当前有多少项目、主机、任务模板,统计展示。

  • 强大的 RESTful API和 CLI工具

    Tower所支持的RESTful API可以覆盖所有的功能。

    Tower 提供详细的REST API 文档。

    Tower还包含CLI工具,可以完成Tower的管理,比如创建用户,更改密码等。

Ansible Tower相比与ansible多进行了一层软件封装,把nginx, celery,rabbit mq, postgresql等组件进行了一次集成封装,提供ansible tower集成服务。


二、Ansible Tower权限管理简述

Ansible可以解决日常批量运维中的自动化问题,而Ansible Tower则是解决如何管理ansible的问题。而管理好ansible的关键则在于对ansible的使用人员进行权限划分,对操作ansible tower的人员实现最小化权限管理。

在AnsibleTower中对于使用对象的划分有三层,Organizations,Teams,Users。Users是使用对象的最小划分,即一个Ansible Tower的账号对应一个User。Teams次之,Organizations是使用对象的最大划分。在官方说明中An Organization is a logical collection of Users, Teams, Projects,and Inventories, and is the highest level in the Tower object hierarchy。也清楚的表达了这一点。

一个Organization拥有users,teams,inventories,projects,jobtemplates,admins六个元素。不同的Organization是相互隔离的,谁也不知道谁的信息,这六个元素在创建时也必须指定一个organization才可以。下图展示了organization的管辖范围。   

Ansible Tower 权限管理使用实例技术手册 | 干货_java

而对于权限的控制对象则有Job Templates,Workflow Templates,Projects,inventories,credentials这几类。而不同的控制对象的权限管理则有所不同,其中通用的权限只有一个admin,表示对该类控制对象具有全部控制权。

JobTemplates具有admin和execute两项权限,分别代表管理员权限和仅执行权限。

WorkflowTemplates具有admin,execute,read三项权限,分别代表管理员权限,仅执行权限和只读权限。

Projects具有admin,use,update三项权限,分别代表管理员权限,使用权限(只读权限)和更新权限(修改写权限)。

Inventories具有admin,use,ad hoc,update四项权限,分别代表管理员权限,使用权限(只读权限),ad hoc权限(可运行adhoc命令权限)和update权限(修改写权限)。

Credentials具有admin和use两项权限,分别代表管理员权限和使用权限(只读权限)。

对于新创建的用户来说,用户则也分为Normal User,System Auditor,System Administrator三个类型。分别代表普通用户,全局系统审计员,全局系统管理员。普通用户具有最低权限,全局系统审计员则具有对所有元素的只读权限,全局系统管理员则具有对所有元素的修改权限。下面是官方给出的对这三种用户类型的解释。

  • Normal User: Normal Users have read and write access limited to theresources (such as inventory, projects, and job templates) for which that userhas been granted the appropriate roles and privileges.

  • System Auditor: Auditors implicitly inherit the read-only capabilityfor all objects within the Tower environment.

  • System Administrator: A Tower System Administrator (also known asSuperuser) has full system administration privileges for Tower – with full readand write privileges over the entire Tower installation. A System Administratoris typically responsible for managing all aspects of Tower and delegatingresponsibilities for day-to-day work to various Users. Assign with caution!

对于Organization中的角色则有Auditor,Admin和Member三个角色。Auditor代表组织审计员,具有对该组织内的所有元素具有只读权限,Admin代表组织管理员,具有对该组织内的所有元素具有修改权限,Member代表成员,具有该组织内的最低权限。

对于AnsibleTower的管理者而言,特权用户必须要局限在一个可控的范围内,否则将会失去权限管理的意义。


三、创建User和Organization管理

由于Organizations是使用对象的最大划分,为了便于理解和操作使用,从该章节开始引入一个实际场景描述Ansible Tower的权限管理方式。

某公司在全国各地都有机房部署,每个地方的机房管理方式不同,运维方式,运维对象也都不同。上海机房作为总部负责管理Ansible Tower的服务器及Zabbix agent的部署工作,其余四地西安,南京,深圳,武汉分别管理不同的业务系统。上海地区拥有三名经验丰富的一线工程师,一名管理员,两名实习生负责运维,其余各地均有一名管理员负责主管本地机房的运维,各地机房自治管理,跨地区机房不能操作管理异地的服务器。

那针对于这种场景则可以在总部部署一套Ansible Tower用于全国所有机房的管理,但各地的实际环境不同,则可以把各地机房分别定义成各自的organization,这样可以实现各地机房的自治管理。

由于该公司需要把各地机房各定义为organization,为了方便统一管理,在总部设置一个管理员组的organization,为了演示方便这里只创建上海机房和管理员组两个organization,后续使用均以上海机房organization为主。

在使用Ansible Tower之前需要使用System Administrator用户建立Organizations和Users。创建Users,Teams,Organizations和credentials均是在设置里面进行的,我们可以在这个地方先创建组织和几个用户。

Ansible Tower 权限管理使用实例技术手册 | 干货_java_02

在设置里面点击Organizations创建组织,输入Name点击SAVE即可创建,我们分别创建上海机房和管理员组两个organization。在创建好的organization上点击user可以设置哪些用户属于该organization,在User那也可以设置。

Ansible Tower 权限管理使用实例技术手册 | 干货_java_03

点击users进入用户设置页面,继续点击Add创建用户,将星号部分填好SAVE即可创建出一个用户,其中username即为用户登录使用的用户名,密码为用户登录的密码。注意在user type项选择Normal User,这里创建一个上海管理员的用户,并将该用户的组织指向上海。Ansible Tower 权限管理使用实例技术手册 | 干货_java_04


在关键字NEW USER字段下面有几个选项可以设置user所属的organizations,teams以及permissions。在用户创建完成后这几个按钮会变亮,后面会提到在这里也可以设置该用户的权限。

回到Organizations页面,点击组织名下面的user可以添加和管理该组织的用户有哪些,我们把各地的管理员用户加到管理员组中。添加用户时可以设置该用户在该组织中的角色是怎样的,下拉菜单里也能看到Auditor,Admin和Member三个选项,这里把上海管理员用户设置为管理员组的admin。

Ansible Tower 权限管理使用实例技术手册 | 干货_java_05


同理也把上海管理员用户设为上海机房的Admin。后续操作均使用上海管理员用户操作。


四、User和Team管理

在创建好上海机房和管理员组两个organization之后,我们继续添加用户,把全国的管理员建立好,再针对于上海机房的实际使用情况创建几个特殊的用户。

其中南京管理员,上海管理员,深圳管理员,武汉管理员,西安管理员均属于管理员组organization,我们再把上海管理员也设置为管理员组的admin,这样上海管理员即为两个organization的admin。Ansible Tower 权限管理使用实例技术手册 | 干货_java_06


除了上海管理员之外,上海机房还有五名工作人员,其中小李,小刘,小王为一线运维工程师,小秦和小张则为实习生,这样上海机房组里就有6个用户了。

现在开始创建Team,对于组也有相应的权限划分,对于上海机房而言我们根据职位进行划分,因为一线运维工程师需要对运维环境做很多复杂的实际操作,而对于实习生来说他们只需要做一些简单的事就行了。Ansible Tower 权限管理使用实例技术手册 | 干货_java_07


在设置里点击Teams创建组,输入Name,选择上海机房organization保存即可,这里我们创建一线运维组和二线学习组两个team。

创建完team之后,Team名称下的users选项会变亮,点击users可以把用户关联到该组中,关联时用户可以多选。我们把小李,小刘,小王加入一线运维组,并把小王设置成admin。Ansible Tower 权限管理使用实例技术手册 | 干货_java_08


同理把小张和小秦加入二线学习组,加入之后可以看到二线学习组里有两个member。Ansible Tower 权限管理使用实例技术手册 | 干货_java_09


至此,我们把ansible tower中的organization,user和team三层使用对象建立完毕,接下来将创建权限管理的控制对象inventories,credentials,projects,,templates,通过对控制对象指定不同的权限,加深对Ansible Tower权限管理的理解。


五、Inventories和Credentials管理

inventory和credential是AnsibleTower控制对象的两个不可或缺的部分,inventory决定了Ansible Tower所管理的对象是哪些服务器,而credential则决定了这些服务器的认证方式。

由于不同的Ansible Tower版本创建inventory的链接位置有所不同,我这里的3.2.5版本的inventory在上沿,点击INVENTORIES,输入inventory名称,选择organization即可创建完成。Ansible Tower 权限管理使用实例技术手册 | 干货_java_10


这里我们创建5个inventory,其中全国全量服务器属于管理员组,其余inventory均属于上海机房组,这样划分的结果就是管理员组里的成员看不到上海机房组里有哪些inventory,并且上海机房组里的成员也并不知道管理员组里的inventory是怎样的。

属于上海机房的四个inventory则可以根据运维工程师的管辖范围进一步去区分。点击inventory名称进入inventory详情页面,点击details边上的permissions设定对该inventory的权限。对于上海全量服务器inventory,我们可以直接使用组划分权限,点击TEAMS设置组权限,对于一线运维组我们把其角色设置为update,表示可以更新该inventory,若有日常运维需要也可以把ad-hoc权限追加到一线运维组中;对于二线学习组我们只能给其use权限,不能让实习生们随意修改或删除该inventory中的数据。Ansible Tower 权限管理使用实例技术手册 | 干货_java_11


对于上海全量服务器inventory我们可以使用组进行大范围的赋权操作,但对于其他更细的服务器列表则必须把权限限制到指定用户。拿上海Ansible Tower服务器inventory举例,上海小刘负责Ansible Tower的运维工作,而其实习生徒弟小秦也跟着小刘负责Ansible Tower,对于上海Ansible Tower服务器inventory来说权限必须控制在这两个人之内。我们给一线运维工程师小刘赋予admin权限,让其可以添加或者修改该inventory,而小秦则只能拥有use权限。Ansible Tower 权限管理使用实例技术手册 | 干货_java_12


对于小秦而言,他对上海全量服务器inventory和上海Ansible Tower服务器而言均只有use权限,使用小秦登录Ansible Tower之后可以看到上海全量服务器inventory可修改的部分均是灰色只读的。Ansible Tower 权限管理使用实例技术手册 | 干货_java_13


上面也提到过,inventory决定管理对象是哪些服务器,而credential则决定了这些服务器的认证方式。对于不同的inventory也需要不同credential去认证管理,credential的权限管理同样重要。我们点击设置中的credentials创建credential,输入name上海服务器认证,选择organization上海机房,credential type选择machine即可创建。Ansible Tower 权限管理使用实例技术手册 | 干货_java_14

这里credential type可根据实际情况选择,在type details输入服务器认证的用户名密码,或者在下方粘贴认证私钥,Ansible Tower会将credential信息以加密的形式存入数据库中。

创建完成后点击details旁边的permissions设置对该credential的权限,对于credential的权限设置更要细致,我们先将二线学习组赋予use权限。Ansible Tower 权限管理使用实例技术手册 | 干货_java_15


对于一线运维工程师而言,也不是所有一线运维工程师都需要去修改该credential,基于权限管理最小化原则,我们把上海小王赋予admin权限,仅允许小王可修改,而小李和小刘也只能拥有use权限。Ansible Tower 权限管理使用实例技术手册 | 干货_java_16


同理,我们再创建全国服务器认证和git仓库权限认证两个credential,其中git仓库认证则是用于后面projects认证。由于不同的organization之间是隔离的,处于上海机房组的成员是无法看到全国服务器认证credential的,反之一样。

Ansible Tower 权限管理使用实例技术手册 | 干货_java_17

 

六、Projects和Templates管理

对于projects和templates可以理解为项目和执行计划,project只是一个静态的项目,而templates则是关联了inventory,credential,project的一个可执行任务。

点击inventory左侧的project来创建项目,我们创建一个部署zabbix agent的项目,隶属于上海机房,SCM Type选择git,输入git的url,选择SCM credential为刚才创建的Git仓库权限认证即可。Ansible Tower 权限管理使用实例技术手册 | 干货_java_18


实际运维中SCM Type可根据实际需要自行选择,同样操作,我们再创建一个查看服务器中的错误日志的project,为这个project把控权限。

创建完成后点击details旁边的permissions设置该项目的权限,由于该项目的常用性,我们还可以对用户和组同时设置权限,只需要勾选就可以。我们给一线运维组均赋予update更新权限;对于实习生小秦来说,他还需要使用这个project去做一些Ansible Tower的排错工作,所以单独给小秦赋use权限;资深老员工小李作为兼顾项目管理工作自然需要该project的admin权限。Ansible Tower 权限管理使用实例技术手册 | 干货_java_19


创建完projects之后,要想让projects真正运行起来需要依靠执行计划。我们继续创建两个job template对应刚创建的两个project。

Job Template需要的参数比较多,输入Name任务名称查找Ansible Tower中的错误日志,Job Type选择Run,inventory则选择上海Ansible Tower服务器,project选择刚创建的查看服务器中的错误日志,playbook则选择项目中需要执行的哪一个yaml文件,credential选择上海服务器认证,verbosity使用默认输出,其他选项根据实际需求添加,保存即可创建好该job template。Ansible Tower 权限管理使用实例技术手册 | 干货_java_20


同样操作我们创建另一个更新zabbix agent版本的job template,创建完成后我们对查找Ansible Tower中的错误日志赋权限,点击details旁边的permissions进行赋权。由于小李是上海Ansible Tower项目的主要负责人,需要该job template的admin权限,而实习生小秦则只需要在有问题的时候帮忙收集下日志,故只需要给小秦赋execute执行权限即可。Ansible Tower 权限管理使用实例技术手册 | 干货_java_21


至此,整个Ansible Tower运维流程中的权限管理设置均已完毕,我们切换到小秦用户,在dashboard页面可以正常看到小秦可以看到的权限,下方也能看到小秦的执行记录。

Ansible Tower 权限管理使用实例技术手册 | 干货_java_22

使用小秦用户执行Ansible Tower中的错误日志Job也完全正常运行,只是这里的上海Ansible Tower服务器是空的,没有跑出来项目的实际结果而已。

Ansible Tower 权限管理使用实例技术手册 | 干货_java_23

最后我们再切换到深圳管理员用户,可以看到深圳管理员所在的管理员组organization与上海机房是完全隔离的,属于上海机房organization的元素在深圳管理员的dashboard上完全看不到。

Ansible Tower 权限管理使用实例技术手册 | 干货_java_24


七、用户权限的其他设置方法

上面按照实际使用Ansible Tower的过程中,举例说明了Ansible Tower的权限管理办法,随着Ansible Tower使用过程中inventories,projects以及job template的增多,不可能还是停留在从控制元素的维度去设置用户权限,其实Ansible Tower也可以选择从User或Team的维度去设置哪个用户或组拥有对哪些控制元素的权限,这样在Ansible Tower上每新增一个用户,就只需要在用户上设置一次权限赋值即可。

点击设置,点击User,点击details旁边的organizations可以设置该用户属于哪个组织,点击Teams可以设置该用户属于哪个组。

Ansible Tower 权限管理使用实例技术手册 | 干货_java_25

点击permissions可以设置该用户的权限,这里我们可以看到一个用户可以对Job Templates,Workflow Templates,Projects,Inventories,Credentials和Organization设置归属权限。

在organizations中可以设置该用户可以归属于哪个organization,在该页面选择任意一个控制元素项可以看到该赋权用户里有哪些可以赋权的项目,选择某一项比如job templates,勾选对应的job,在下方赋权限即可。对用户的统一权限设置可以一次性的把Job Templates,Workflow Templates,Projects,Inventories,Credentials和Organization均设置完成。

Ansible Tower 权限管理使用实例技术手册 | 干货_java_26

点击key可以看到该控制对象可以设置的权限有哪些。同样的,对Teams也可以使用这种集中赋权模式,对于上海小王用户我们赋完的权限可以在details看到详细情况。

 Ansible Tower 权限管理使用实例技术手册 | 干货_java_27

八、总结

本文简述了下Ansible Tower权限管理的范畴,通过举例实际演示了如何通过Ansible Tower划分不同的权限。以下总结几点作为Ansible Tower权限管理的回顾。

1、Organization是使用对象的最大划分,User是使用对象的最小划分,Team介于两者之间。

2、原则上Organization中的控制元素是相互隔离的,但也可以让指定元素可见,比如一个上海管理员用户同时在上海机房和管理员组两个organization中。

3、新建organization必须使用拥有system administrator权限的用户,新建用户或组可以使用该organization的admin用户即可。

4、只有organization的admin用户才具有在该organization中新建inventories,credentials,projects的权限,而job templates普通用户就可以创建。

5、Credentials的类型有很多种,可以根据日常需要选择,也可以自定义credential types,但只有system administrator才能自定义。

6、Inventories的ad-hoc权限其实就是执行ansible静态命令的权限,不加ad-hoc权限无法对该inventory执行静态命令。

7、Projects只代表项目,对于项目中ansible playbook新增修改的权限管理则不在Ansible Tower权限管理的管辖范围内。

8、对于权限管理应遵循最小化原则,不建议为了方便管理操作将用户的权限放大,这样也失去了权限管理的意义。