玩轉運維編排服務的權限：Assume Role+Pass Role

時間 2019-11-16

標籤轉運編排服務權限 assume role+pass role pass 简体版

原文原文鏈接

什麼是運維編排服務？

阿里雲運維編排服務（Operation Orchestration Service，簡稱OOS）是雲上的自動化運維平臺，提供運維任務的管理和執行。典型使用場景包括：事件驅動運維，批量操做運維，定時運維任務，跨地域運維等，OOS爲重要運維場景提供審批，通知等功能。OOS幫用戶實現標準化運維任務，從而實踐運維即代碼（Operations as Code）的先進理念。OOS支持跨產品使用，用戶可使用OOS管理ECS、RDS、SLB、VPC等雲產品。html

用大白話講，就是阿里雲的用戶編寫一個包含運維邏輯的模板，提交給OOS，而後OOS在雲端，以用戶的身份執行這個模板裏面的運維邏輯。git

阿里雲OOS的公共模板已經開源在githubgithub

更多的信息請參考以前的文章阿里雲重磅發佈雲上自動化利器——運維編排OOS
或參考運維編排官方幫助文檔安全

權限相關的三個基本概念：用戶，受權策略，角色

先說用戶，用戶就是帳號，這個概念很好理解。用戶分爲兩類：主帳號和子帳號。運維

阿里雲上的用戶在最開始使用阿里雲服務的時候，都會註冊一個雲帳號，這個註冊生成的帳號就叫作主帳號，能夠理解爲root帳號，擁有最高的權限。ui

接下來，擁有主帳號的用戶若是想要建立子帳號，就須要開通一個叫作RAM (Resource Access Management)的雲產品。開通RAM以後，就能夠在RAM控制檯上，建立子帳戶。建立子帳戶的目的，是爲了限制子帳戶的權限，避免root帳戶被濫用和泄露的風險。this

那麼，子帳戶的權限如何限制呢？這兒就要先引入受權策略的概念。受權策略表示一組權限的集合，好比針對ECS的建立銷燬啓停的權限集合。受權策略也分兩類，一類是阿里雲內置的系統受權策略，另外一類是用戶自定義的受權策略。OOS服務默認包含了兩個系統受權策略，一個叫作OOSFullAccess，至關於擁有了OOS這個服務的所有權限，另外一個叫作OOSReadOnlyAccess，至關於只能讀取OOS的模板和歷史執行的數據，不能作修改模板也不能啓動執行。阿里雲

帳號和受權策略之間，是多對多的關係。主帳戶或者管理員，能夠決定，每個子帳號擁有哪些權限策略。好比，給user1分配OOSFullAccess權限策略，而給user2分配OOSReadOnlyAccess權限策略。spa

那麼，什麼是角色（Role）呢？角色是一種虛擬的用戶，它不對應任何能夠控制檯登陸的帳戶，但主帳號或管理員能夠建立Role並給Role像普通用戶同樣賦予受權策略。那麼誰來使用這些虛擬用戶（Role）呢？典型的使用場景就是雲產品。主帳戶或者管理員，能夠爲角色配置「信任關係」，也就是能夠決定哪些雲產品可以使用這些虛擬帳戶。code

權限問題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"
}