Permissions¶
If you need to control resource access for your personnel, Identity and Access Management (IAM) is a good choice for fine-grained permissions management. IAM provides identity authentication, permissions management, and access control, helping you securely access your cloud resources.
With IAM, you can create IAM users for your employees, and assign permissions to the users to control their access to specific resource types. For example, if you need to grant some users the permissions to view TMS resources, but do not want these users to delete predefined tags, you can create users using IAM and assign TMS ReadOnlyAccess permissions to these users.
If your account does not require IAM for permissions management, you can skip this section.
IAM can be used free of charge. You pay only for the resources in your account. For more information about IAM, see IAM Service Overview.
TMS Permissions¶
New IAM users do not have any permissions assigned by default. You need to first add them to one or more groups and attach policies or roles to these groups. The users then inherit permissions from the groups and can perform specified operations on cloud services based on the permissions they have been assigned.
TMS is a global service deployed for all regions. When you set the authorization scope to Global services, users have permission to access TMS resources in all regions.
You can grant permissions by using roles and policies.
Roles: A coarse-grained authorization strategy provided by IAM to assign permissions based on users' job responsibilities Only a limited number of service-level roles are available for authorization. When using roles to grant permissions, you must also assign other roles which the permissions depend on to take effect. Roles are not ideal for fine-grained authorization and least privilege access.
Policies: A fine-grained authorization strategy that defines permissions required to perform operations on specific cloud resources under certain conditions. This type of authorization is more flexible and is ideal for least privilege access. The administrator can restrict a user to only specified operations on TMS using IAM policies. For example, if the user is granted a fine-grained permission to only view predefined tags, the user cannot perform other operations on predefined tags (such as creating or deleting predefined tags) with this permission. A majority of fine-grained policies contain permissions for specific APIs. For the API actions supported by TMS, see the section "Permissions Policies and Supported Actions" in the Tag Management Service API Reference.
Table 1 lists all TMS system-defined policies and roles. Some TMS policies depend on the policies of other services to take effect. When you assign TMS permissions to users, you also assign dependent policies for the TMS permissions to take effect.
Role/Policy Name | Description | Type | Dependencies |
---|---|---|---|
TMS FullAccess | Full permissions for TMS. | System-defined policy |
|
TMS ReadOnlyAccess | Read-only permissions for TMS. | System-defined policy |
|
TMS Administrator | Full permissions for TMS. Users with these permissions can query, create, delete, import, or export predefined tags, and create, delete, modify, or query resource tags. | System-defined role | Dependent on the following policies:
|
Table 2 lists the common operations supported by TMS system-defined permissions.
Operation | TMS FullAccess | TMS ReadOnlyAccess | TMS Administrator |
---|---|---|---|
Querying the cloud resource list | Supported (permissions of corresponding services for querying resources required) | Supported (permissions of corresponding services for querying resources required) | Supported (Tenant Guest required) |
Creating a key | Supported | Not supported | Supported (Tenant Guest required) |
Viewing resource tags | Supported | Supported | Supported (Tenant Guest required) |
Creating resource tags | Supported (permissions of corresponding services for creating tags required) | Not supported | Supported (Tenant Guest and corresponding project policies of cloud resources required. For example, if you need to manage VPC tags, select Tenant Guest in the same project.) |
Modifying resource tags | Supported (permissions of corresponding services for creating, deleting, and viewing tags required) | Not supported | Supported (Tenant Guest and corresponding project policies of cloud resources required. For example, if you need to manage VPC tags, select Tenant Guest in the same project.) |
Deleting resource tags | Supported (permissions of corresponding services for deleting tags required) | Not supported | Supported (Tenant Guest and corresponding project policies of cloud resources required. For example, if you need to manage VPC tags, select Tenant Guest in the same project.) |
Querying predefined tags | Supported | Supported | Supported |
Creating predefined tags | Supported | Not supported | Supported |
Deleting predefined tags | Supported | Not supported | Supported |
Exporting predefined tags | Supported | Supported | Supported |
Importing predefined tags | Supported | Not supported | Supported |
If predefined permissions cannot meet your requirements, you can create custom policies. Custom policies allow you to perform fine-grained access control flexibly. For details about how to create a custom policy, see Creating a Custom Policy. For details about TMS example custom policies, see Custom Policies.
The following table lists fine-grained actions and dependencies for TMS.
Action Name | Description | Dependencies | Scenario |
---|---|---|---|
tms:predefineTags:list | Grants permissions to view predefined tags | None | Viewing or querying predefined tags |
tms:predefineTags:create | Grants permissions to create predefined tags. | tms:predefineTags:list | Creating predefined tags |
tms:predefineTags:delete | Grants permissions to delete predefined tags. | tms:predefineTags:list | Deleting predefined tags |
tms:predefineTags:update | Grants permissions to update predefined tags | tms:predefineTags:list | Modifying predefined tags (Currently, this action can only be called through the API. This action is not required for any feature on TMS console.) |
tms:resourceTags:create | Grants permissions to tag resources. |
| Adding tags to resources |
tms:resourceTags:delete | Grant permissions to remove tags from resources |
| Removing resource tags |
tms:tagKeys:list | Grants permissions to query tag keys | None | Viewing tag keys (Currently, this action can only be called through the API. This action is not required for any feature on TMS console.) |
tms:tagValues:list | Grants permissions to query tag values | None | Viewing tag values (Currently, this action can only be called through the API. This action is not required for any feature on TMS console.) |
tms:resourceTags:list | Grants permissions to query tags | None (permissions of corresponding services for querying tags required) | Viewing tags and the number of tags |
tms:resources:list | Grants the permissions to view resources | None (permissions of corresponding services for querying resources required) | Searching for cloud resources |
Note
If you need to perform operations on tags of cloud resources on TMS console, you must have related permissions for viewing, creating, and deleting resource tags and required permissions for the services to which the resources belong. Modify a resource tag involves a process of deleting the old tag and then creating a new tag (with the same tag key but different tag values). So, to modify a cloud resource tag, you must have both related TMS permissions and service permissions to delete and create tags.
For system-defined permissions: If you need to add or delete tags for ECS resources on TMS console, both TMS FullAccess permissions and ECS FullAccess permissions are required.
For custom permissions: If you need to view ECS resources and tags on the TMS console, not only tms:resourceTags:list permissions, but ecs:servers:getTags and ecs:servers:get permissions are required.
For details about all system-defined permissions of services supported by IAM, see Permissions. For more information about fine-grained permissions of each service, see corresponding documentations of each service.