Permission to play transshipment maintenance choreography service: Assume Role + Pass Role

Time:2019-10-11

What is Operations and Maintenance Choreography Service?

Operation Orchestration Service (OOS) is an automated operation and maintenance platform on the cloud, providing the management and execution of operation and maintenance tasks. Typical usage scenarios include event-driven operation and maintenance, batch operation and maintenance, timing operation and maintenance tasks, cross-regional operation and maintenance, etc. OOS provides approval, notification and other functions for important operation and maintenance scenarios. OOS helps users to achieve standardized operations and maintenance tasks, thereby practicing the advanced concept of operations as code. OOS supports cross-product use. Users can use OOS to manage cloud products such as ECS, RDS, SLB and VPC.

In plain language, Aliyun users write a template containing operation and maintenance logic, submit it it to OOS, and then OOS in the cloud to execute the operation and maintenance logic in the template as a user.

Aliyun OOS public templates are already available in GitHub

For more information, please refer to the previous article. Aliyun’s blockbuster release of Cloud Automation Tool – Operations, Maintenance and Arrangement OOS
Or refer to Operations and Maintenance to compile official help documents

Three basic concepts of privilege: user, authorization policy, and role

First of all, users are accounts. This concept is well understood. Users are divided into two categories: main account and sub account.

Users on Aliyun will register a cloud account when they first use Aliyun service. The account generated by this registration is called the main account, which can be understood as root account and has the highest privileges.

Next, if a user with a primary account wants to create a subaccount, he or she needs to launch a cloud product called RAM (Resource Access Management). After opening RAM, you can create sub-accounts on the RAM console. The purpose of creating sub-accounts is to restrict the rights of sub-accounts and avoid the risk of abuse and disclosure of root accounts.

So, how to limit the rights of sub-accounts? Here we need to introduce the concept of authorization policy. Authorization policies represent a set of privileges, such as the set of privileges to create destroy start-stop for ECS. Authorization strategies can also be divided into two categories, one is the built-in system authorization strategy in Aliyun, the other is user-defined authorization strategy. OOS service includes two system authorization policies by default. One is called OOS Full Access, which is equivalent to having all the permissions of OOS service. The other is called OOSReadOnlyAccess, which is equivalent to reading only OOS templates and historical execution data, not modifying templates or starting execution.

There is a many-to-many relationship between accounts and authorization strategies. The main account or administrator can decide which permission policies each subaccount has. For example, OOSFull Access privilege policy is assigned to user1, while OOSReadOnlyAccess privilege policy is assigned to user2.

So what is a role? A role is a virtual user that does not correspond to any account that can be logged on to the console, but a primary account or administrator can create a Role and give it authorization policies like ordinary users. So who will use these virtual users? A typical usage scenario is cloud products. The main account or administrator can configure a “trust relationship” for the role, that is, to determine which cloud products can use these virtual accounts.

Privilege Question 1: Assume Role

The core function of OOS is to execute the template written in advance according to the user’s identity. This involves a basic question: what identity does OOS use as a cloud product to execute user-written templates?

If only from a simple implementation point of view, without considering security, then Aliyun directly gives OOS a super privilege, anyway, it is a “own” product. Is that OK? We don’t think so. Users need to be able to restrict OOS. They need to be able to decide which resources OOS can and cannot operate. That is to say, when OOS executes a user’s template, it must “play” a user’s controllable identity.

I believe smart readers have already thought of using the role described earlier and the function Assume Role. Assume Role is a cloud product that plays a role of a user. Users need to take two steps: the first step is to create a role and trust the Operations and Maintenance Choreography Service, as shown in the following figure:

Permission to play transshipment maintenance choreography service: Assume Role + Pass Role

The second step is to give this role a permission policy. If users want OOS to manage ECS, they can consider giving this role the permission policy of Aliyun ECS Full Access.

Permission to play transshipment maintenance choreography service: Assume Role + Pass Role

So, next, how does OOS Assume Role execute templates? In the OOS template, you can specify a role through the field “RamRole”, which OOS will try to play when it executes the template in the background. If the template is not specified, the OOS will try to play the default role, that is, the OOS Service Role.

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'

If the user does not create the corresponding role beforehand, it will report an error when executing. The error message is similar to “: Assumes role failed. Code: EntityNotExist. Role, msg: The role does not exist: acs:: 111111111: role / OOSService role.”

If the user creates this role but does not trust the Operations and Maintenance Choreography Service, an error message will be reported, similar to “Assumes role failed. Code: NoPermission, msg: You are not authorized to do this action. You should be authorized by RAM.”

Users can manually edit the trust policy for the Role

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

Permission Question 2: Pass Role

If OOS is operated by either the main account or the administrator, then the problem seems to have been solved. But in fact, enterprise IT departments will have the demand for sub-accounts. The powers of sub-accounts are often varied. Although administrators trust OOS services to play the roles specified in the template, administrators do not necessarily trust all subaccounts to use the roles mentioned above by performing OOS services. In this case, the OOS service becomes a middleman, subaccounts use OOS, and OOS uses roles. So, how to determine the indirect access rights of subaccounts to roles? This takes advantage of the Pass Role function.

Next, we have two different scenarios to explain and explain.

Scenario 1: The subaccount executes a common template, such as setting a timed startup for a batch of ECS and choosing to use the non-default role MyOOSRole (our common template allows users to select roles at execution time). This scenario is very common. Administrators should take two steps in advance: first, prepare a permission policy, and allow PassRole to call MyOOSRole. The specific content of the permission policy is as follows:

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

The second step is to assign this permission strategy to the sub-account.

If the sub account does not have the corresponding passrole permission, an error message “user has no permission to do the action: (passrole)” will be displayed.

Scenario 2: Delegate authorization. We imagine a scenario in which a high-specification ECS can be created only after the approval of the Department manager. According to the Passle scenario described earlier, we can arrange the whole workflow of “Application-Approval-Create ECS-Initialize ECS” into a template, prepare a role with ECS privileges and trust OOS services, and then give the template to ordinary users. The problem here is that we do not want to grant PassRole privileges to ordinary users, nor to create ECS privileges to ordinary users. What should we do? In order to achieve security and convenience at the same time, we recommend “delegation authorization”. In this scenario, there are two different sub-accounts. The first is the template manager, who is responsible for the development and maintenance of custom templates, such as the template of “applying for a high-specification ECS instance”. Another type of sub-account is the executor of the template, which needs to be executed to initiate applications for ECS. The administrator of the template has the right to edit the template, assigns a role to the template, and has PassRole privileges corresponding to that role. The executor of the template only needs to have the execution authority of the template, and does not need to perceive the corresponding role behind the template, let alone the Passler authority of the role. In this scenario, the administrator of a template “delegates authority” to the executor of the template.

Permission to play transshipment maintenance choreography service: Assume Role + Pass Role

In a delegated authorization scenario, PassRole’s authentication action occurs when the template administrator creates the template, not when the template executor executes the template, on the grounds that the role of the template (assumed to be OOS Service Role) is specified by the template administrator at the creation time, and the executor is not aware of the role. In the allocation of privilege policy, template manager needs PassRole to call OOS Service Role’s privilege + edit template’s privilege, template executor only needs to read and execute template’s privilege. Note that this does not apply to scenario 1 where subaccounts choose roles autonomously when executing templates.

In practical use, administrators may create multiple roles and trust OOS to play them. It would be cumbersome to List roles one by one when granting PassRole privileges to subaccounts. To simplify, administrators can decide to allow PassRole calls to a subaccount whenever OOS can play a role. For example, the system permission strategy of Aliyun OOSFull Access is:

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

Welcome to OOS

Links to the OOS Management Console: https://home.console.aliyun.com/redirect.htm?ProductId=ecs&path=automation/region/
Links to OOS Help Documents



Author: Yunpu

Read the original text

This article is the original content of Yunqi Community, which can not be reproduced without permission.