1

什么是运维编排服务?

阿里云运维编排服务(Operation Orchestration Service,简称OOS)是云上的自动化运维平台,提供运维任务的管理和执行。典型使用场景包括:事件驱动运维,批量操作运维,定时运维任务,跨地域运维等,OOS为重要运维场景提供审批,通知等功能。OOS帮用户实现标准化运维任务,从而实践运维即代码(Operations as Code)的先进理念。OOS支持跨产品使用,用户可以使用OOS管理ECS、RDS、SLB、VPC等云产品。

用大白话讲,就是阿里云的用户编写一个包含运维逻辑的模板,提交给OOS,然后OOS在云端,以用户的身份执行这个模板里面的运维逻辑。

阿里云OOS的公共模板已经开源在github

更多的信息请参考之前的文章 阿里云重磅发布云上自动化利器——运维编排OOS
或参考运维编排官方帮助文档

权限相关的三个基本概念:用户,授权策略,角色

先说用户,用户就是账号,这个概念很好理解。用户分为两类:主账号和子账号。

阿里云上的用户在最开始使用阿里云服务的时候,都会注册一个云账号,这个注册生成的账号就叫做主账号,可以理解为root账号,拥有最高的权限。

接下来,拥有主账号的用户如果想要创建子账号,就需要开通一个叫做RAM (Resource Access Management)的云产品。开通RAM之后,就可以在RAM控制台上,创建子账户。 创建子账户的目的,是为了限制子账户的权限,避免root账户被滥用和泄露的风险。

那么,子账户的权限如何限制呢?这儿就要先引入授权策略的概念。授权策略表示一组权限的集合,比如针对ECS的创建销毁启停的权限集合。授权策略也分两类,一类是阿里云内置的系统授权策略,另一类是用户自定义的授权策略。OOS服务默认包含了两个系统授权策略,一个叫做OOSFullAccess,相当于拥有了OOS这个服务的全部权限,另一个叫做OOSReadOnlyAccess,相当于只能读取OOS的模板和历史执行的数据,不能做修改模板也不能启动执行。

账号和授权策略之间,是多对多的关系。主账户或者管理员,可以决定,每一个子账号拥有哪些权限策略。比如,给user1分配OOSFullAccess权限策略,而给user2分配OOSReadOnlyAccess权限策略。

那么,什么是角色(Role)呢?角色是一种虚拟的用户,它不对应任何可以控制台登录的账户,但主账号或管理员可以创建Role并给Role像普通用户一样赋予授权策略。那么谁来使用这些虚拟用户(Role)呢?典型的使用场景就是云产品。主账户或者管理员,可以为角色配置“信任关系”,也就是可以决定哪些云产品能够使用这些虚拟账户。

权限问题1:Assume Role

OOS的核心功能,是要按照用户的身份去执行用户提前编写好的模板。这里面就涉及到了一个基本问题:OOS作为一个云产品,用什么样的身份去执行用户编写的模板呢?

如果单从简单实现的角度,而不考虑安全,那么阿里云直接给OOS赋予一个超级权限就可以了,反正是“自家”产品。这样做可以吗?我们认为不可以。用户需要有能力对OOS进行限制,需要可以决定OOS可以操作哪些资源,不可以操作哪些资源。也就是说,OOS在执行用户的模板的时候,一定是“扮演”了某个用户可控的身份。

相信聪明的读者已经想到了,这里用到了前面介绍的角色(Role),以及Assume Role这个功能。Assume Role,就是云产品,扮演用户的某个角色。用户,需要进行两个操作步骤:第一步,就是创建一个角色(Role),并且信任运维编排服务,如下图所示:

第二步,就是给这个角色赋予权限策略,用户如果希望OOS来管理ECS,就可以考虑把AliyunECSFullAccess这个权限策略赋予给这个角色。

那么,接下来,OOS是怎么Assume Role执行模板的呢? 在OOS模板里面,可以通过“RamRole”这个字段指定一个角色,OOS在后台执行这个模板的时候,就会尝试扮演这个Role。如果模板没有指定,那么OOS就会尝试扮演默认的角色,也就是OOSServiceRole这个角色。

FormatVersion: OOS-2019-06-01
RamRole: 'OOSServiceRole'
Tasks:
- Name: describeRunningInstancesByTag
  Action: ACS::ExecuteApi
  Description: Views running ECS instances by specifying tag.
  Properties:
    Service: ECS
    API: DescribeInstances
    Parameters:
      Status: Running
      Tags:
      - Key: 'tagkey'
        Value: 'tagvalue'

如果用户没有预先创建相应的角色,那么在执行的时候,就会报错,错误消息类似于“:Assumes role failed. Code: EntityNotExist.Role, msg: The role not exists: acs::111111:role/OOSServiceRole.”

如果用户创建了这个角色,但是并没有信任运维编排服务,那么,就会报错,错误消息类似于“Assumes role failed. Code: NoPermission, msg: You are not authorized to do this action. You should be authorized by RAM.”

用户可以手动编辑该Role对应的信任策略

{
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "oos.aliyuncs.com"
                ]
            }
        }
    ],
    "Version": "1"
}

权限问题2:Pass Role

如果操作OOS的都是主账号或者管理员,那么问题似乎已经解决了。但事实上,企业IT部门,都会有子账户的需求。子账户的权限,往往各种各样。虽然管理员信任OOS服务来扮演模板中指定的角色,但是管理员未必信任所有的子账户,通过执行OOS服务来使用上述的角色。这里面,OOS服务成了一个中间人,子账户使用OOS,OOS使用角色。那么,如何决定子账户对于角色的间接使用权限呢?这就利用到了角色传递(Pass Role)这个功能。

下面,我们都过两个不同场景,来解释和说明。

场景1:子账户执行一个公共模板,比如给一批ECS设置定时启动,并选择使用非默认的角色MyOOSRole(我们的公共模板,是允许用户在执行时选择角色的)。这个场景非常常见。管理员要提前做两步动作:第一步,准备一个权限策略,要允许PassRole调用MyOOSRole这个角色,权限策略具体内容如下:

{
      "Version": "1",
      "Statement": [
        {
          "Effect": "Allow",
          "Action": "ram:PassRole",
          "Resource": "acs:ram::{parent_uid}:role/myoosrole"
        }
      ]
}

第二步,把这个权限策略赋予该子账户。

如果子账户没有相应的PassRole权限,会报错提示“User has no permission to do the action: (PassRole)”。

场景2:委托授权。我们想象一个场景,高规格的ECS是需要部门经理审批后才能创建的,按照前面介绍的PassRole场景,我们可以把“申请-审批-创建ECS-给ECS初始化”的整个工作流编排到一个模板里,同时准备一个拥有ECS权限并且信任OOS服务的角色,然后把这个模板交给普通用户使用。这里面有个问题,就是我们既不希望给普通用户授予PassRole权限,也不希望给普通用户授予创建ECS的权限,怎么办呢?为了同时实现安全性和方便性,我们推荐“委托授权”。在这个场景里面,有两类不同的子账户,第一类是模板的管理者,负责自定义模板的开发和维护工作,比如“申请一台高规格的ECS实例”的模板。另一类子账户是模板的执行者,需要通过执行这个模板来发起对于ECS的申请。模板的管理者拥有模板编辑的权限,给模板指定了一个角色,并拥有该角色对应的PassRole权限。而模板的执行者,只需要拥有该模板的执行权限就可以了,并不需要感知模板后面对应的角色,更不需要该角色的PassRole权限。这种场景,就叫做模板的管理者把PassRole权限“委托授权”给了模板的执行者。

在委托授权的场景下,PassRole的鉴权动作,发生在模板管理员创建模板的时候,而不是在模板执行者执行模板的时候,理由是该模板的角色(假设为OOSServiceRole)是在创建时刻被模板管理员指定的,执行者不感知角色。在权限策略的分配上,模板管理者需要PassRole调用OOSServiceRole的权限 + 编辑模板的权限,模板执行者只需要读取和执行模板的权限。请注意,这不适用于场景1中,子账户在执行模板时自主选择角色的情况。

在实际使用中,管理员可能会创建多个角色,都信任给OOS来扮演。那么在给子账户赋予PassRole权限的时候,如果把角色一个个都列出来,也会很繁琐。为了简化,管理员可以决定,只要是OOS能扮演的角色,就都允许某个子账户PassRole调用。比如,AliyunOOSFullAccess这个系统权限策略就是:

{
    "Statement": [
        {
            "Action": "oos:*",
            "Effect": "Allow",
            "Resource": "*"
        },
        {
            "Action": "ram:PassRole",
            "Resource": "*",
            "Effect": "Allow",
            "Condition": {
                "StringEquals": {
                    "acs:Service": "oos.aliyuncs.com"
                }
            }
        }
    ],
    "Version": "1"
}

欢迎使用OOS

OOS管理控制台的链接: https://home.console.aliyun.com/redirect.htm?productId=ecs&path=automation/region/
OOS帮助文档的链接



本文作者:云普

阅读原文

本文为云栖社区原创内容,未经允许不得转载。


如果觉得我的文章对你有用,请随意赞赏

你可能感兴趣的

载入中...