今年企業對Java開發的市場需求，你看懂了嗎？ >>>   

通過policy配置許可權過程中遇到的一些問題

背景資訊：

本文以如下場景為基準進行編寫，如下：

1. 使用者通過DataWorks-簡單模式使用MaxCompute；
2. 使用者具有DataWorks預設角色，如DataWorks開發者角色；
3. 使用者通過console提交policy配置精細化許可權管控，

解決方案：

通過policy進行deny某個role禁止刪除以tb_開頭的表，同時將屬於這一部分的user都新增到該角色中。
具體如下：

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

t_policy.json配置檔案如下：

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

檢視上述配置的子賬號許可權：

針對上圖的說明：

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

是否符合預期：

（1）在DataWorks上進行測試：

居然刪除成功了！！！納尼，是我們配置策略不對嘛？？？

（2）再在console上進行驗證：

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

這是為什麼呢？？為什麼呢？？
其實在這一塊需要注意的是，在DataWorks-工作空間配置-計算引擎資訊-訪問身份（）配置情況。

訪問身份大科普：

這個要看下我們在專案管理裡面的賬號設定是個人賬號還是系統賬號。兩個最大的區別如下：
dataworks這裡的角色，會有兩種許可權，一種是dataworks介面操作許可權，一種是MaxCompute資料相關許可權（建表、查詢等）。

然後有兩種情況：

1）如果MaxCompute訪問身份為 個人賬號，那麼角色的“MaxCompute資料相關許可權”就會生效，這個子賬號用其他客戶端操作MaxCompute都可以有這個project的相關許可權。

2）如果MaxCompute訪問身份為 系統賬號，那麼角色的“MaxCompute資料相關許可權”就不會生效，這個子賬號在dataworks上提交的MaxCompute任務因為是通過系統賬號提交所以只要系統賬號有許可權就可以。但是子賬號用非dataworks的客戶端提交MaxCompute就會沒許可權。

對應如下邏輯示意圖：

那麼，到這裡親們應該明白了，為什麼在DataWorks中測試發現policy策略沒有生效麼？是因為配置的訪問身份為系統賬號，那麼通過DataWorks提交的Query都會用系統賬號來執行（project owner擁有最大許可權且並沒有受到該policy限制）。

你只需要在這裡設定為【個人賬號】即可滿足上述需求。

原文連結
本文為雲棲社群原創內容，未經