Shulou(Shulou.com)05/31 Report--

This article will explain in detail about MaxCompute and DataWorks permissions and example analysis, the content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Background: users are not clear about using the two permission models of MaxCompute and DataWorks, and are not very familiar with the permission execution statements of the relevant MaxCompute, so that they can not establish a complete permission policy in their actual operation, resulting in confusion of permission control, and even often encounter errors of permission problems in the development process, resulting in delays in the promotion of business progress. This document integrates the main rights knowledge points and integration. The commonly used MaxCompute permission statements and the classic examples of empowerment between the development environment and the production environment are introduced.

I. the security model of MaxCompute

Cdn.com/255487b7ccafbc3d139d0090569bf520a3284d74.png ">

2. DataWorks security model

Restrictions on the addition of sub-accounts

IV. MaxCompute Authorization Management Map

V. Authorization scenarios and considerations

6. Remove the user's notes

VII. Sentences related to member management

View members:

Project owner or admin command line execute List users;-- View member list Show grants for;-- View member permissions

Add members:

1.DataWorks adds RAM sub-account; 2.Project owner or admin command line executes add user-- can be RAM sub-account or other cloud account

Delete a member:

Delete RAM sub-account by 1.DataWorks; execute by 2.Project owner or admin command line: remove user

8. Related sentences of role management:

View roles:

View role list: List roles; View permissions in role: describe role check which role a user is in: show grants for View which user a role is assigned to: not supported at this time!

Create a role:

Create role:Create role; authorize roles: grant actions on object to to add users to roles: grant TO

Delete a role:

Delete user in role: REVOKE FROM; revoke authorization to role: revoke on from role delete role: DROP ROLE

IX. Introduction to policy authorization

Policy authorization is a kind of subject-based authorization. The permission data (that is, the access policy) authorized through Policy is regarded as the "kind" resource of the authorization subject. Only when the principal (account or client) exists can you enter the authorized operation of Policy. When the principal is deleted, the permission data authorized by Policy will be deleted dynamically. Policy authorization enables the access policy language defined by "MaxCompute" to grant authorization, allowing or disabling the principal's access to item space objects.

Policy authorization mechanism, which mainly solves some complex authorization scenarios solved by ACL authorization mechanism, such as:

This operation authorizes the entry of group objects, such as all functions, all tables starting with "taobao"

Authorization with restrictions, such as authorization will only take effect within a specified period of time, when the requester initiates a request from the specified IP address, or only allows the user to access a table with SQL (which does not allow other types of Task).

The format of Policy authorization statement is as follows:

GET POLICY;-- read the Policy PUT POLICY; of the project space-- set (override) the Policy GET POLICY ON ROLE of the project space;-- read the Policy PUT POLICY ON ROLE of a role in the project space;-- set (override) the Policy of a role in the project space

Basic terminology of policy

A Principal (Principal) is an object to which permissions in an access policy are assigned. For example, the subject of the access policy "allowing Zhang San to perform CreateObject operations on the resource SampleBucket before December 31, 2011" is "Zhang San".

Action (Action) refers to the principal's access to resources. For example, the operation in the access policy "allows Zhang San to perform CreateObject operations on the resource SampleBucket before December 31, 2011" is "CreateObject".

Resource (Resource) Resource (Resource) is the object that the principal requests access. For example, the resource in the access policy "allows Zhang San to perform CreateObject operations on the resource SampleBucket before December 31, 2011" is "SampleBucket".

Access restrictions (Access Restriction) access restrictions (Access Restriction) are restrictions on the validity of permissions. For example, the restriction in the interview policy "allowing Zhang San to perform CreateObject operations on resource SampleBucket before December 31, 2011" is "before December 31, 2011".

The ect authorization effect includes two actions: allow action (Allow) and deny action (Deny). In general, Deny is more efficient and gives priority to permissions when checking permissions. Note: "deny operation" and "revoke authorization" are two completely independent concepts. Revoking authorization usually includes revoking authorization for two different effects, Allow and Deny, and holding Revoke and Revoke Deny operations as traditional databases do.

Authorization statement (Statement) structure

E permission ect: indicates the permission type of the statement. The value must be Allow or Deny.

Principal: if Policy is bound to a subscriber or subscriber at the time of authorization, then you are no longer allowed to specify Principal, such as MaxCompute's Role Policy. If Policy is bound to an object in the item space or item space at the time of authorization, it must refer to Principal, such as the Project Policy of MaxCompute.

Action: it represents an authorized operation, can be one or more operation names, and can hold wildcard symbols "" and "?". For example, A c t i o n = "" indicates all operations.

Resource: it represents an authorized object, can be one or more object names, and can hold the wildcard symbols "and"?. For example, R e s o u r c e = "" represents all objects.

Condition Block: a conditional block is a condition for the permissions stated in this authorization statement to be valid. The structure of the condition block is described in the next section.

10. Authorization cases for the actual use of Policy

Based on previous experience, we created two basic roles in the odps project, namely the development role dev and the query role adhoc.

Create role dev;create role adhoc

Our permission requirements for roles are roughly divided into the following two categories:

A Development permission: you cannot modify project attributes but can read project information. You can create tables, resources, Job and other common permissions. You can modify and delete tables created by yourself in the development library, but you only have read permissions for tables created by other students.

B query permissions: can only read project information, can not build tables, build resources, build Job; can only read tables, but do not have any permission to modify or delete.

Our security policy goes something like this:

On the development library, give A development rights to all development students.

On the production library, give B query rights to all development students.

About MaxCompute and DataWorks permissions and sample analysis is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.