Hello, everyone!
Today I'm going to introduce you DAYU
HUAWEI CLOUD’s Data Lake Catalog (DLCatalog) is based on HUAWEI CLOUD’s unified identity authentication (IAM) for user management and authentication. So for external users (such as Hadoop Kerberos users) who are not in the HUAWEI CLOUD’s IAM system , how to access the DLCatalog service and How to implement access control of DLCatalog service?
For DLCatalog, IAM’s DLCatalog strategy is used internally to achieve fine-grained access control of DLCatalog resources ; then from the outside, how to map the relationship between external users and the DLCatalog strategy on IAM.
theoretical analysis
IAM policies are the basic unit used to control IAM users' access rights to HUAWEI CLOUD resources. There are only two types of objects that can be authorized by IAM policies: " IAM user group " and " IAM delegation ." Therefore, the external user system needs to implement relationship mapping with IAM's DLCatalog strategy, which is essentially the realization of "the mapping between external users and IAM commissions ".
The most simple and understandable description of IAM commission is as follows: " The IAM administrator of HUAWEI CLOUD Account A" commissions "Huawei Cloud Account B" or "Huawei Cloud Service S", which represents account A, and assigns the designated Huawei owned by cloud account A. Cloud service resources are used . Here are a few points to clarify first:
The entrusting party is a person with IAM administrator authority under enterprise account A, which can be the boss himself (account A), a member of the board of directors (admin user group), or a full-time IAM administrator—the IAM administrator itself may be just one An ordinary IAM user does not have the right to use the target cloud service resources, but as an IAM administrator, he has the right to authorize all cloud service resources.
The delegated party here can be a cloud account or a cloud service. Their status in the delegated relationship is completely equivalent . For ease of understanding, we collectively refer to them as the "delegated party" below.
The cloud service resources that can be entrusted include all resources under enterprise account A, and naturally also include DLCatalog service resources
Program calls by external users can only use the delegated user token to access DLCatalog
According to the description of API authentication method and obtaining temporary AK/SK/SecurityToken in the official IAM document , the request to obtain temporary AK/SK/SecurityToken itself can use " user authentication and authentication (user Token or user ak_sk signature authentication) " and " Entrusted authentication authentication (delegating Token or entrusting ak_sk signature authentication) " two ways. Information security considerations as mentioned earlier
(1). The permanent AK and SK of the IAM user cannot be used, that is, the user ak_sk signature cannot be used to obtain temporary authentication
(2) The user name/login password cannot be used, that is, the temporary authentication cannot be obtained by logging in the user's user token;
(3) Similarly, because the acquisition of entrusted Token still requires the password of the entrusted user , it does not meet the information security requirements.
So, in the end, it is to obtain the Token for accessing DLCatalog by entrusting ak_sk signature authentication, replacement
The authorized ECS provides the entrusted AK/SK certification information
The next question is: how to get the ak/sk authentication information of the delegation, and how is the delegation created?
Because the permanent AK/SK and login password of any account/IAM user cannot be disclosed, the delegated party can only be a certain Huawei Cloud service . So which cloud service to use? The most convenient and direct answer is the ECS service .
In the official document of the Huawei Cloud ECS service, the easiest way to obtain the temporary AK/SK information of the commission is given , that is, to set a commission for the target ECS, such as agency_to_ecs in the following figure :

Then log in to the ECS shell and execute the curl http://169.254.169.254/openstack/latest/securitykey command to obtain this temporary AK/Sk/SecurityToken as the delegated ECS, that is, the delegated AK/SK authentication information . The next question is, how to set the details of this IAM commission?
The entrusted ECS will be assigned entrusted authority by the enterprise account, and the second entrustment method is adopted to quickly switch between multiple DLCatalog strategies.
In the agency_to_ecs delegation created earlier, the simplest idea may be to directly authorize the DLCatalog permission policy required by an external user to the agency_to_ecs delegation, and then the entrusted ECS can use "agency_to_ecs" based on its own delegation authentication information. "Does this delegate name obtain temporary authentication information for accessing DLCatalog resources? "
This is of course possible in theory, and each delegate corresponds to a DLCatalog fine-grained access strategy, but this will cause the following two problems:
This delegated ECS is authorized only by the single DLCatalog access policy in agency_to_ecs delegation. But for each different external user, the required DLCatalog access permissions are different.
Therefore, when different external users call the client program, they all need to call the IAM API interface to change the delegated setting of the delegated target ECS (that is, change to agency_2
, Agency_3, etc.), or the ECS delegation name agency_to_ecs remains unchanged, but the IAM DLCatalog strategy corresponding to agency_to_ecs delegation needs to be modified- for scenarios with multiple external users with different permissions, such delegation work efficiency is very low .
Moreover, such an ECS cannot respond to a request for "multiple external users to obtain temporary authentication information for different DLCatalog access rights" at the same time .
Therefore, we can solve this problem by packaging multiple original IAM delegation relationships into a secondary delegation. The specific plan is as follows:
The IAM administrator creates N IAM DLCatalog access policies for the DLCatalog permission requirements of N external users
The IAM administrator creates N IAM delegates, the delegate type is "account delegate", the delegate target is enterprise account A itself, and each delegate is granted a different IAM DLCatalog strategy created in step 1.
According to the delegation authority assigned on the IAM official website , the IAM administrator creates a dedicated IAM policy, in which the Resource --> url JSON array contains all the delegation IDs created in step two
The IAM administrator creates a delegation whose delegation type is "Cloud Service", and authorizes the policy created in step 3 to the "Global Service" --> "Global" project
The IAM administrator sets the target ECS delegation as the IAM delegation created in step 4.
When each external user wants to obtain the authentication information corresponding to different DLCatalog access rights, only when calling DLCatalog, when sending a temporary token request to IAM through APIG, the agency_name field in the Request Body is set to the target delegation ID created in step 2. That's it. Because IAM can support multiple concurrent access, multiple external users can naturally also obtain tokens corresponding to different DLCatalog permissions concurrently.
The entire process of DLCatalog is similar to the replacement process of OBS, except that the final access to the service is the ak/sk or token of the entrusted user. It can be seen that: The comparison of the two implementation methods of fine-grained access control of the OBS service gives the details. Granularity control scheme
Precautions
IAM defaults that the number of IAM delegations that can be created for each enterprise account is 50. If the customer has a large number of external users with different permissions, then it needs to apply to Huawei Cloud in advance to expand the number of delegations under the enterprise account.
