玩转运维编排服务的权限：Assume Role+Pass Role

什么是运维编排服务？

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

用大白话讲，就是阿里云的用户编写一个包含运维逻辑的模板，提交给OOS，然后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"
}

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