在MaxCompute中配置Policy策略遇到結果不一致的問題

背景信息:

本文以以下場景爲基準進行編寫,以下:json

  1. 用戶經過DataWorks-簡單模式使用MaxCompute;
  2. 用戶具備DataWorks默認角色,如DataWorks開發者角色;
  3. 用戶經過console提交policy配置精細化權限管控,

本案例以禁止某一些用戶羣體(role)能夠刪除以tb_開頭的表爲例來展開討論。測試

解決方案:

經過policy進行deny某個role禁止刪除以tb_開頭的表,同時將屬於這一部分的user都添加到該角色中。
具體以下:spa

  1. create role denydroprole;
  2. put policy t_policy.json on role ``denydroprole;
  3. grant ``denydroprole to user RAM$..;

t_policy.json配置文件以下:3d

{
    "Version": "1",
    "Statement": [{
        "Effect": "Deny",
        "Action": "odps:Drop",
        "Resource": "acs:odps:*:projects/sz_mc/tables/tb_*"
    }]
}

查看上述配置的子帳號權限:code

針對上圖的說明:blog

  1. [roles]該子帳號同事隸屬與兩個角色,一個是新建的denydroprole,一個是DataWorks的開發者角色role_project_dev。
  2. [Authorization Type: Policy]其中A表明Allow,D表明Deny,當二者同事存在時,deny優先原則。

是否符合預期:

(1)在DataWorks上進行測試:項目管理

竟然刪除成功了!!!納尼,是咱們配置策略不對嘛???開發

(2)再在console上進行驗證:get

在MaxCompute console上測試策略生效了,刪除以tb_開頭的表直接被拒絕而且返回錯誤。io

這是爲何呢??爲何呢??
其實在這一塊須要注意的是,在DataWorks-工做空間配置-計算引擎信息-訪問身份()配置狀況。

訪問身份大科普:

這個要看下咱們在項目管理裏面的帳號設置是我的帳號仍是系統帳號。兩個最大的區別以下:
dataworks這裏的角色,會有兩種權限,一種是dataworks界面操做權限,一種是MaxCompute數據相關權限(建表、查詢等)。

而後有兩種狀況:

1)若是MaxCompute訪問身份爲 我的帳號,那麼角色的「MaxCompute數據相關權限」就會生效,這個子帳號用其餘客戶端操做MaxCompute均可以有這個project的相關權限。

2)若是MaxCompute訪問身份爲 系統帳號,那麼角色的「MaxCompute數據相關權限」就不會生效,這個子帳號在dataworks上提交的MaxCompute任務由於是經過系統帳號提交因此只要系統帳號有權限就能夠。可是子帳號用非dataworks的客戶端提交MaxCompute就會沒權限。
詳情能夠參考:https://yq.aliyun.com/articles/686800

對應以下邏輯示意圖:

那麼,到這裏親們應該明白了,爲何在DataWorks中測試發現policy策略沒有生效麼?是由於配置的訪問身份爲系統帳號,那麼經過DataWorks提交的Query都會用系統帳號來執行(project owner擁有最大權限且並無受到該policy限制)。

你只須要在這裏設置爲【我的帳號】便可知足上述需求。

 



本文做者:禕休

原文連接

本文爲雲棲社區原創內容,未經容許不得轉載。

相關文章
相關標籤/搜索