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

什么是运维编排服务？

阿里云运维编排服务（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帮助文档的连接

---

本文做者：云普

阅读原文

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