Data Lake Analytics帳號和權限體系詳細介紹

1、Data Lake Analytics介紹
數據湖（Data Lake）是時下大數據行業熱門的概念：https://en.wikipedia.org/wiki...。基於數據湖作分析，能夠不用作任何ETL、數據搬遷等前置過程，實現跨各類異構數據源進行大數據關聯分析，從而極大的節省成本和提高用戶體驗。

阿里雲數據湖分析產品Data Lake Analytics（簡稱DLA）：https://www.aliyun.com/produc...
產品文檔：https://help.aliyun.com/produ...

下圖是DLA的簡易架構（__MPP計算引擎+存儲計算分離+彈性高可用+異構數據集源等）__：

2、自建帳號
目前DLA是以MySQL協議方式對外提供服務，用戶須要經過JDBC鏈接，連到DLA服務。DLA內部的帳號和密碼是獨立自建的（與RAM不一樣），對應的帳號和密碼信息，在用戶開通DLA服務時以站內信、郵件、短信等方式通知您。

可能您會疑惑，爲何DLA不是以RAM或AK帳號作認證和受權，而須要自建帳號。在這裏，作一些簡單的介紹：

DLA是數據庫，在客戶端創建鏈接（須要認證）、訪問庫、表、字段（須要鑑權）時，大量跨服務訪問RAM系統，會給RAM系統形成很大壓力，且可能會影響DLA服務延時；
DLA是數據庫，須要兼容MySQL權限模型，庫、表、字段等領域對象很難一一映射到RAM體系；同時RAM下的資源對象的權限粒度可粗可細，且更多偏向於管理數據生命週期而非詳細數據層面的權限；
用戶習慣的Grant、Revoke、Show grants等邏輯，都是直接和傳統數據庫的庫、表、字段一一映射。
參考了阿里雲上及業界雲服務平臺上其餘數據庫產品的設計，存在同樣的考量；
目前DLA帳號體系與RAM帳號體系的關係：

3、三種帳號模型
Root/Service帳號：RAM主帳號在某個Region內開通DLA服務時，系統會自動建立第一個DLA帳戶，並以站內信、短信、郵件方式通知RAM主帳號，Root帳號只有一個，不能刪除；
User/子帳號：由RAM主帳號後續在Console上建立的新的DLA的User帳號（注意，不是由Root帳號建立的），雲帳號用戶能夠建立、刪除User帳號，也能夠爲其修改密碼等；
Product帳號：其餘雲產品（好比DBS）與DLA交互時，由用戶在RAM中爲該雲產品受權過，由DLA自動產生並派發給雲產品的帳號；
Root帳號和User帳號，關聯的RAM uid都是對應的雲帳號，從而Root和User帳號都有機會訪問雲帳號全部的資源（固然，這都是在受權管理以內）；
4、帳號實測操做
a）開通服務並初始化服務
找到服務：

購買：

開通完成，點擊進入控制檯：

爲不一樣的Region初始化服務：

初始化完成，獲得一個Root帳號：

從新回到主頁：https://openanalytics.console...，設置服務訪問點：

image.png | left | 747x379

配置服務訪問點

image.png | left | 747x431

image.png | left | 747x353

b）鏈接數據庫並經過認證
鏈接DLA服務，並進入服務

鏈接DLA服務，帳號和密碼都在您的收件箱內，服務訪問點則在服務頁面

[root]# mysql -u<您的dla用戶名> -p<您的dla密碼> -h<您的dla服務訪問點> -P10000

進入DLA服務，開始測試之旅

mysql> show databases;
Empty set (0.09 sec)
image.png | left | 747x213

到此，咱們已經完成了服務開經過程，並認證和鏈接成功。

c）建立子帳號，並鏈接數據庫
image.png | left | 747x325

image.png | left | 747x206

image.png | left | 747x163

鏈接DLA服務，並進入服務，也能正常工做了：

image.png | left | 747x233

5、權限模型
DLA中有兩層權限驗證機制，確保您的數據被安全訪問：

DLA層受權和校驗校驗，基於MySQL語法而定義和實現（Grant：https://dev.mysql.com/doc/ref...、Revoke：https://dev.mysql.com/doc/ref...、Show Grants：https://dev.mysql.com/doc/ref...）
數據源和RAM層受權和校驗，基於RAM的的訪問控制而實現（好比OSS、TableStore等雲原生產品）：https://help.aliyun.com/produ...，或者基於數據源自己的權限校驗（好比RDS，是自建帳號，於是也有自建權限系統）
用戶的SQL發送到DLA，作完DLA的權限校驗後，再轉發到後端數據源層，執行RAM層和數據源的權限校驗，最後再真正訪問到用戶的數據；
a）DLA層校驗原理
DLA是根據用戶操做對象的範圍「從大到小」驗證的，從Global級（全局權限），到Schema級，再到Table級，最後到Column級（目前不支持）一層層驗證權限。任何一層有權限校驗成功，到最後一層也沒權限時校驗失敗：

image.png | left | 351x557

b）DLA層受權方法
基本上參考了MySQL的Grant/Revoke/Show Grants語法來實現：

grant相關

GRANT {SELECT | SHOW | ALTER | DROP | CREATE | INSERT | UPDATE | DELETE | GRANT OPTION | ALL | ALL PRIVILEGES | USAGE }
ON { | . | xxDb. | xxDb.yyTable | yyTable }
TO { oa_1234546 | 'oa_123456' | 'oa_123456'@'1.2.3.4'}
[with grant option]

revoke相關

REVOKE {SELECT | SHOW | ALTER | DROP | CREATE | INSERT | UPDATE | DELETE |GRANT OPTION | ALL | ALL PRIVILEGES | USAGE}
ON { | . | xxDb. | xxDb.yyTable | yyTable }
FROM { oa_1234546 | 'oa_123456' | 'oa_123456'@'1.2.3.4'}

show grants相關

SHOW GRANTS
[for [ current_user | current_user() | oa_123456 | 'oa_123456' | 'oa_123456'@'localhost'] ]
相關關鍵信息說明：
受權人：

只能由DLA的root帳號給其餘非Root帳號受權；
暫時不支持非Root帳號給其餘帳號受權；
不能跨雲帳號受權和回收權限；
privilege列表：

能夠用','鏈接在一塊兒，好比SELECT,DELETE,UPDATE,INSERT,...
有ALL或ALL PRIVILEGES就會所有受權或者所有回收，無視其餘的Privilege；但必定要注意，grant option這個權限自己，不包含在ALL中，必須顯式受權或者回收
暫時不支持其餘類型的受權；
SELECT是爲Query受權；
SHOW爲show、use命令受權（這裏與mysql的邏輯差別比較大）；
ALTER爲alter或其餘變動型的ddl受權；
CREATE爲create型的ddl受權；
DROP爲drop型的ddl受權；
INSERT爲insert型的dml受權；
UPDATE爲update型的dml受權；
DELETE爲delete型的dml受權；
GRANT OPTION爲dcl受權（grant和revoke相關）；能夠在Privilege中指定GRANT OPTION，也能夠經過語句片斷with grant option來作grant 受權；
USAGE其實啥也沒有，表示爲空；
ResourceType中：

• 表示當前鏈接使用了某個庫xxDB，而後針對xxDB作受權，庫級別權限；

. 表示全部庫的全部表受權，Global級別權限；
xxDb.* 表示針對xxDB這個庫作受權，庫級別權限；
xxDb.yyTable 表示針對xxDB庫的xxTable作受權，表級別權限；
yyTable 表示當前鏈接使用了某個庫xxDB，針對xxDB庫的xxTable作受權，表級別權限；
暫時不支持字段級別的受權；
被受權用戶定義：

直接寫用戶名：oa_123456
用戶字符串來表示：'oa_123456'
即便寫了ip、host信息，也不會用於鏈接的白名單校驗；
只有相同雲帳號下的Root用戶才能爲別人show grants；
不能跨不一樣uid執行show grant
必須有show權限和grant權限才能執行show grants，或者爲本人執行__；__
SHOW GRANTS FOR 'jeffrey'@'localhost'：目前不支持ip地址；
c）DLA與RAM間權限映射
由於DLA中的子帳號與RAM中的子帳號並非一一對應，於是RAM中資源的權限和DLA中庫表的權限也不是天然映射的，而是須要在DLA中以特殊定義的方式來作資源的映射和權限的隔離。

目前DLA中受權單位是Schema級別的，也就意味着若是Root帳號給某個User帳號受權了一個庫的權限，那這個User帳號可以訪問這個庫下全部的表，也就意味着可以訪問該庫映射到RAM上全部的資源，這些訪問並不受RAM的子帳號權限控制。

好比，咱們看一個典型的建庫語句（假設用戶已經能夠在DLA中建立相關的庫）：

CREATE DATABASE db_name
with dbproperties (
CATALOG = 'ots',
LOCATION = 'https://test-hangzhou.ots.ali...',
INSTANCE = 'test'
)
若是Root帳號給某個User帳後執行Grant操做後，該User帳號就能夠訪問這個庫：

grant all on db_name.* to xxx_s1519122757;
上述過程都假設雲帳號的系統角色受權已經完成，下一節咱們介紹首先如何完成系統角色受權，從而容許DLA訪問你在其餘雲產品中的數據。

d）系統角色受權
系統角色受權是指：用戶給DLA受權，容許DLA訪問用戶相關雲服務裏的數據，從而實現DLA關聯分析用戶數據的目標，或者經過DLA實現ETL，將數據迴流到用戶的庫。具體過程能夠參考：https://help.aliyun.com/docum...

e）跨帳號訪問
DLA支持跨帳號，容許A用戶在DLA上，鏈接B用戶的OSS上的數據進行分析計算，不過這須要作一些操做，後續文檔會以圖形化的方式來介紹和引導用戶：

image.png | left | 563x426

6、權限實測操做（以TableStore爲案例）
a）準備TableStore的庫表
咱們來到OTS的首頁，https://ots.console.aliyun.co...，建立但願DLA作分析的庫和表：

image.png | left | 747x384

庫建完後，去建表

image.png | left | 747x301

image.png | left | 747x313

image.png | left | 747x243

image.png | left | 747x331

插入一行數據

image.png | left | 747x250

b）開通TableStore給DLA的雲服務角色受權
關於訪問控制和角色受權等信息，請參考：https://help.aliyun.com/produ...

回到DLA主頁：https://openanalytics.console...

image.png | left | 747x432

點擊贊成受權：

image.png | left | 747x342

受權完成以後的狀態：

image.png | left | 747x484

查看角色受權已經成功：

image.png | left | 747x413

c）在DLA中建立庫和表，關聯TableStore庫和表
咱們從新回到DLA Root帳號（oa_xxx），經過JDBC協議鏈接到DLA（帳號信息、DLA訪問點、JDBC鏈接方式，請參考前面文檔）

╰─○ mysql -u<您的DLA Root帳號> -p<您的DLA Root帳號的密碼> -h<您的DLA-jdbc訪問點> -P10000

mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 194631
Server version: 5.6.40-log Source distribution

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.

mysql>
開始建立庫，去關聯TableStore中的實例：

mysql> select user();
user()
oa_xxxxxxxxxxx

1 row in set (0.08 sec)

mysql> show databases; Empty set (0.02 sec)

mysql> create database ots_account_test
with dbproperties(
catalog = 'ots',
location = 'https://account-test.cn-shang...',
instance = 'account-test'
) comment 'test account and privileges';
Query OK, 0 rows affected (0.10 sec)

mysql> show databases;
Database
ots_account_test

1 row in set (0.01 sec)

mysql> show create database ots_account_test;
Database	Create Database
ots_account_test	CREATE DATABASE ots_account_test

WITH DBPROPERTIES (

catalog = 'ots',
location = 'https://account-test.cn-shanghai.ots-internal.aliyuncs.com',
instance = 'account-test'

)

COMMENT 'test account and privileges'

1 row in set (0.03 sec)
開始建立表，去關聯TableStore中的表，並查詢數據（結果與OTS中的結果一致）：

mysql> use ots_account_test;
Database changed

mysql> show tables;
Empty set (0.03 sec)

mysql> create external table account_test (

-> pk1 int not null primary key,
-> name varchar(20) 
-> );

Query OK, 0 rows affected (0.15 sec)

mysql> show create table account_test;
Table	Create Table
account_test	CREATE EXTERNAL TABLE account_test (

`pk1` int NOT NULL COMMENT '',
`name` varchar(20) NULL COMMENT '',
PRIMARY KEY (`pk1`)

)

COMMENT ''

1 row in set (0.04 sec)

mysql> select * from account_test;
pk1	name
123	account-test

1 row in set (1.61 sec)
至此，咱們已經成功完成了數據關聯並實現數據查詢的過程！！

d）把庫和表受權給子帳號來訪問
上訴都是Root帳號在操做，從前面的分析可知，Root帳號是能夠操做對應雲帳號全部的雲資源的，可是DLA的User帳號卻不行，必須經過Root帳號給User帳號Grant權限，DLA才能容許某個User帳號訪問對應的庫和表：

切換到User帳號/子帳號鏈接頁面，此時看不到任何庫表：

mysql> select user();
user()
test_sxxxxxxxxxxxxxxxx

1 row in set (0.14 sec)

mysql> show databases;
Empty set (0.02 sec)

mysql> show grants ;
Grants for test_sxxxxxxxxxxxxxxxx
GRANT USAGE ON . TO 'test_sxxxxxxxxxxxxxxxx'

1 row in set (0.03 sec)
切換Root帳號鏈接頁面，咱們給前面的帳號受權：

mysql> select user();
user()
oa_xxxxxxxxxxx

1 row in set (0.14 sec)

mysql> show grants for test_sxxxxxxxxxxxxxxxx;
Grants for test_sxxxxxxxxxxxxxxxx
GRANT USAGE ON . TO 'test_sxxxxxxxxxxxxxxxx'

1 rows in set (0.02 sec)

mysql> grant all on ots_account_test.* to test_sxxxxxxxxxxxxxxxx;
Query OK, 0 rows affected (0.05 sec)

mysql> show grants for test_sxxxxxxxxxxxxxxxx;
Grants for test_sxxxxxxxxxxxxxxxx
GRANT USAGE ON . TO 'test_sxxxxxxxxxxxxxxxx'
GRANT ALL ON ots_account_test.* TO 'test_sxxxxxxxxxxxxxxxx'

2 rows in set (0.03 sec)
切換User帳號鏈接頁面，從新查詢看看，已經有權限了，而且能夠讀取數據：

mysql> select user();
user()
test_sxxxxxxxxxxxxxxxx

1 row in set (0.14 sec)

mysql> show grants ;
Grants for test_sxxxxxxxxxxxxxxxx
GRANT USAGE ON . TO 'test_sxxxxxxxxxxxxxxxx'
GRANT ALL ON ots_account_test.* TO 'test_sxxxxxxxxxxxxxxxx'

2 rows in set (0.02 sec)

mysql> show databases;
Database
ots_account_test

1 row in set (0.02 sec)

mysql> select * from ots_account_test.account_test;
pk1	name
123	account-test

1 row in set (0.43 sec)
至此，子帳號受權訪問就能夠了！

e）支持跨帳號訪問
通常狀況，用戶大部分使用DLA的場景是，雲帳號A使用DLA訪問雲帳號A在其餘雲產品中的數據，從前面的分析能夠知道，只要用戶在DLA的console上選擇具體的數據源（好比TableStore）給DLA作系統角色受權以後，就能夠打通數據源，建立庫表和查詢數據了。

可是，還有一種場景是：雲帳號A使用DLA來訪問雲帳號B在其餘雲產品（如下以TableStore）中的數據，這須要專門的角色受權才能正常運行：

image.png | left | 563x426

假設上述測試帳號對應的雲帳號爲A，下面就以TableStore和另外一個雲帳號B（DLA另外一個真實的測試雲帳號）做爲案例，演示B帳號給A帳號針對TableStore中某個instance作跨帳號受權，而且A在DLA中完成查詢的過程。

首先，須要到B帳號內，在"訪問控制（https://ram.console.aliyun.com）"中建立一個跨帳號受權的角色：

image.png | left | 747x445

選擇一個「服務角色」，選擇一個合適的模板，快速建立：

image.png | left | 747x323

image.png | left | 747x407

image.png | left | 747x283

image.png | left | 747x355

從新回到角色管理頁面，找到這個角色作修改（修改爲支持DLA的模板）：

image.png | left | 747x412

image.png | left | 747x278

image.png | left | 747x315

image.png | left | 747x273

跨帳號的角色建立和修改完成，開始作「角色受權策略」的配置，這裏咱們以TableStore爲例，其餘數據源相似：

image.png | left | 747x337

image.png | left | 747x144

跨帳號角色定義，以及角色受權都操做完成，咱們開始進入DLA的實際測試，首先查看雲帳號B的TableStore中的instance和table的狀況：

image.png | left | 747x393

image.png | left | 747x259

從新使用雲帳號A的DLA Root帳號，經過MySQL-cli鏈接到DLA，而後鏈接和訪問雲帳號B的數據：

mysql> select user();
user()
oa_xxxxxxxxxxx

1 row in set (0.06 sec)

mysql> show databases;
Database
ots_account_test

1 row in set (0.24 sec)

mysql> create database ots_cross_account_test
with dbproperties(
catalog = 'ots',
location = 'https://test-sh.cn-shanghai.o...', --雲帳號B的TableStore instance
instance = 'test-sh',
cross_account_accessing_arn= 'acs:1013xxxxxx:role/test-cross-account-accessing-role' --雲帳號B爲雲帳號A@雲服務DLA的跨帳號角色受權時的Arn信息
);
Query OK, 0 rows affected (0.14 sec)

mysql> show databases ;
Database
ots_account_test
ots_cross_account_test

2 rows in set (0.18 sec)

mysql> show create database ots_cross_account_test;
Database	Create Database
ots_cross_account_test	CREATE DATABASE ots_cross_account_test

WITH DBPROPERTIES (

catalog = 'ots',
location = 'https://test-sh.cn-shanghai.ots-internal.aliyuncs.com',
instance = 'test-sh',
cross_account_accessing_arn = 'acs:ram::1013xxxxxx:role/test-cross-account-accessing-role'

)

COMMENT ''

1 row in set (0.19 sec)

mysql> use ots_cross_account_test;
Database changed

mysql> show tables;
Empty set (0.19 sec)

mysql> create external table test_table1 (
id1 int not null primary key,
col1 int
);
Query OK, 0 rows affected (0.31 sec)

mysql> show tables;
Table_Name
test_table1

1 row in set (0.20 sec)

mysql> show create table test_table1;
Table	Create Table
test_table1	CREATE EXTERNAL TABLE test_table1 (

`id1` int NOT NULL COMMENT '',
`col1` int NULL COMMENT '',
PRIMARY KEY (`id1`)

)

COMMENT ''

1 row in set (0.20 sec)

mysql> select * from test_table1;
id1	col1
0	-111
111111	111

2 rows in set (1.29 sec)
順便提醒一下，普通的建庫流程中是不須要cross_account_accessing_arn參數的，意味着默認是雲帳號本身給本身開通了DLA訪問雲服務的權限，而有了cross_account_accessing_arn參數，就表示跨帳號服務的開啓，這個DLA中的庫以及庫下面的表，都有了跨帳號訪問的權限！！

到這裏，咱們跨帳號訪問的全過程就完成啦！！若是你但願鏈接OSS等雲服務，你也能夠按照上述流程操做一遍！！