IAM Sub-user Overview

You can create a sub-user with your own AccessKey by IAM under your Baidu Cloud account,. Your Baidu Cloud account is called the master account, and the created account is called the sub-user. The AccessKey of the sub-user can only realize the access of the operations and resources authorized by the master account. BOS has been connected to the IAM sub-user system, and you can create the IAM sub-user by the multi-user access control of the console. It can be realized as follows: 1.Authorization of the same account: You can authorize the sub-user under your account to manage Cloud resources (Buckets and Objects) which are under your account. 2.Cross-account authorization: You can authorize the sub-user under your account to manage Cloud resources Buckets and Objects) which are under other accounts.

IAM Sub-user Application Scenarios

• Enterprise sub-account management and decentralization

  Enterprise A uses Baidu AI Cloud account to purchase a variety of cloud resources (such as BCC instance/RDS instance/BLB instance/BOS storage/...). Employees of Enterprise A need to operate these cloud resources, including purchase, operation and maintenance, online application, etc. The job duties of employees in different positions are different, and the required privileges are different. For security, A does not want to publish the key of the primary account directly to employees, but wants to create corresponding user sub-accounts for employees of different positions. The sub-account of the user can only operate resources under the premise of privilege without independent measurement and billing, and all resource fees belong to the master account. Master account of Enterprise A can revoke the privilege of sub-account at any time, or delete the created sub account at any time.

• Resource operation and privilege management between enterprises

  A and B represent different enterprises. Enterprise A purchases a variety of cloud resources (such as BCC instance/RDS instance/BLB instance/BOS storage/...) to carry out business. Enterprise A hopes to focus on business system and entrust or authorize tasks such as cloud resource operation and maintenance monitoring management to Enterprise B. Enterprise B can further assign the operation and maintenance task to employees of Enterprise B, that is, B creates corresponding user sub-accounts for the employees to use. Enterprise B can exactly control the operation privilege of Enterprise A cloud resource by employees of Enterprise B In case of termination of such agent operation and maintenance contract between Enterprise A and Enterprise B, Enterprise A may revoke the authorization to Enterprise B at any time.

Policy File Description

The master user of IAM gives privilege to the sub-user by the associated policy. The policy file is essentially a JSON file, in which privilege and resource are used to define privileges and resources. The blank template corresponding to the policy file is as follows:

{ 
    "accessControlList": [ 
        { 
            "service": "bce:bos", 
            "region": "*", 
            "effect": "Allow", 
            "permission": [], 
            "resource": [], 
        } 
    ] 
} 

The meaning of each field in the policy file is as follows:

The BOS API corresponding to each privilege is as follows:

System Policy Configuration Description

For the convenience of users, Baidu AI Cloud has internally installed two common policies as system policies: BosFullAccess and BosListAndReadAccess.

• BosFullAccess: The privilege to manage the Baidu AI Cloud object storage service (BOS).
• BosListAndReadAccess: The privilege of read-only access to Baidu object storage service (BOS).

Note:

• System policy cannot be modified and deleted.

On the "Policy Management" page, it is needed to click the "View" button in the operation column corresponding to the policy name to view the JSON files corresponding to the two system policies.

Custom Policy Configuration Description

In case you need to customize more detailed privilege control, you can create a custom policy. The custom policy means that the user defines the resources and privileges of the sub-account by the policy file, and the user can control the privileges and resources more precisely by the custom policy. Policies are JSON files in nature. You can refer to [Policy File Description](#Policy File Description) or the following typical scenario examples. In the example, the bucket name is assumed to be mybucket.

Grant of the Full Management privilege of a Bucket to a Sub-user (to Manage by Console)

{
    "accessControlList": [
        {
            "service": "bce:bos",
            "region": "*",
            "effect": "Allow",
            "permission": [
                "FULL_CONTROL"
            ],
            "resource": [
                "mybucket",
                "mybucket/*"
            ]
        },
        {
            "service": "bce:bos",
            "region": "*",
            "effect": "Allow",
            "permission": [
                "ListBuckets"
            ],
            "resource": [
                "*"
            ]
        }
    ]
}

Note:

• Mybucket and mybucket/* are both needed to written in the resource field.
• In case you want to manage a bucket by the console, you need to have the privilege of ListBuckets. Otherwise, the bucket list cannot be opened.
• Sub-user supports cross-account resource privilege. For example, mybucket here can be a resource under other accounts. It is assumed that there are two accounts, mybucket under Account A and sub-user under Account B. Account a can first authorize mybucket to account B by updating bucket privilege. Then account B can create a custom policy to further grant the privilege to manage mybucket to sub-users.

Grant of the Full Management privilege of a Bucket to a Sub-user (without Console Management and BOS Desktop)

{ 
    "accessControlList": [ 
        { 
            "service": "bce:bos", 
            "region": "*", 
            "effect": "Allow", 
            "permission": [ 
                "FULL_CONTROL"
            ], 
            "resource": [ 
                "mybucket", 
                "mybucket/*" 
            ] 
        } 
    ] 
} 

Note:

• Mybucket and mybucket/* are both needed to written in the resource field.
• In case you do not manage buckets with the console, you do not need to open the ListBuckets privilege. You can use BOS services directly by BOS Peripheral Tools and SDKs.

Grant of the Read-only privilege of a Prefix (directory) to a Sub-user

It is assumed that a bucket is used to store photos. Photos are stored according to the shooting location. Each shooting location has an annual sub-directory. Now you need to grant read-only privilege to the sub-user to read the mybucket/shanghai/2013/directory. The directory structure is as follows:

mybucket //bucket 
	 | -- beijing 
	 | 	 | --2010 
	 | 	 | --2011 
	 | -- shanghai 
	 | 	 | --2012 
	 | 	 | --2013 //Grant of read-only privilege to this directory 
	 | --shenzhen 
	 	 | --2014 
	 	 | --2015 

It is assumed that the sub-user already knows the path of all files and does not need to list the privileges of the files:

{ 
    "accessControlList": [ 
        { 
            "service": "bce:bos", 
            "region": "*", 
            "effect": "Allow", 
            "permission": [ 
                "READ" 
            ], 
            "resource": [ 
                "mybucket/shanghai/2013/*"
            ] 
        } 
    ] 
}