什么是運維編排服務？

阿里云運維編排服務（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: describeRunningInstancesByTagAction: ACS::ExecuteApiDescription: Views running ECS instances by specifying tag.Properties:Service: ECSAPI: DescribeInstancesParameters:Status: RunningTags:- 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" }

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的玩转运维编排服务的权限：Assume Role+Pass Role的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。