Access Control Policies Supported by IAM
An IAM principal can perform operations and access APIs in an account. Principals include IAM users, agencies, and trust agencies. IAM provides multiple access control policies for these principals, which can be classified into discretionary access control (DAC) and mandatory access control (MAC).
- DAC: allows the account administrator to authorize IAM principals. For details, see DAC.
- MAC: enforces mandatory control policies on IAM principals for guardrails. For details, see Mandatory Access Control (MAC).
DAC and MAC contain multiple types of permission policies, which can be used together.
|
Category |
Item |
|---|---|
|
DAC |
Role/Policy-based permission control |
|
Identity policy-based permission control |
|
|
Resource sharing-based permission control |
|
|
Trust policy-based permission control |
|
|
MAC |
Session-based permission control |
|
SCP-based permission control |
|
|
VPC endpoint policy-based permission control |
DAC
The owner of a resource is an account, and each resource has only one owner. By default, only the resource owner has full permissions on the resource. Essentially, DAC helps the account administrator solve the problem of granting which permissions on which resources to whom. As shown in the following figure, IAM divides resources into the resources of your account and the resources authorized by other accounts to your account.
Based on DAC, IAM supports intra-account authorization and cross-account authorization.
- Intra-account authorization: An account grants resource operation permissions to IAM identity under the account using roles/policies, identity policies, and trust policies.
- Cross-account authorization: An account grants resource operation permissions to another account using resource sharing policies and trust policies.
Trust policies can be used in both intra-account authorization and cross-account authorization.
Role/Policy-based Access Control
System-defined roles, system-defined policies, and custom policies are used in role/policy-based permission control. System-defined roles are a coarse-grained authorization strategy provided by IAM to assign permissions based on users' job responsibilities. They are not ideal for fine-grained authorization and secure access control. System-defined policies are a set of permissions preset by Huawei Cloud IAM for common scenarios. Custom policies are user-defined policies for more refined permission control.
For details about how to use roles/policies, see Permissions Management.
Identity Policy-based Access Control
Roles are no longer used in identity policy-based permission control. Instead, system-defined identity policies and custom identity policies are used. Identity policies support version control. IAM can save the versions of recent system-defined identity policies and custom identity policies and allows you to switch the versions of custom identity policies. Specifically, when you modify a custom identity policy or Huawei Cloud modifies a system-defined identity policy, the modification will not overwrite the existing identity policy. Instead, a new identity policy version will be created. A maximum of five versions can be created for a custom identity policy. If you need to create a sixth policy version, delete a historical version first.
For more information about how to use identity policies to manage permissions, see Overview of Identity Policies.
Trust Policy-based Access Control
Generally, permissions are attached to IAM identities for authorization. In resource-based authorization, permissions are attached to a resource to define which principals can perform what operations on the resource. Trust policies in trust agencies are a type of resource-based policies. When a trust agency is used as an IAM identity, you can attach roles, policies, and identity policies to the trust agency for permission control. When a trust agency is used as a resource, you can grant the trust agency permissions to an account or a cloud service. A cloud service can be regarded as a special principal.
In an agency, you specify an account or a cloud service to establish a trust relationship. In a trust agency, you use policy statements to describe the trust relationship between accounts or between an account and a cloud service. In a trust policy, you can specify either an account or a cloud service as the trust principal. When you specify your account as the trust principal, authorization is performed within the account. When you specify another account or a cloud service as the trust principal, authorization is performed across accounts. You can use global condition keys such as g:SourceAccount to avoid confused deputy issues. When a trust agency is used as a resource, it must have trust policies attached so that you can obtain the temporary security credential of the trust agency.
For details about how to use trust agencies and trust policies, see Overview.
Resource Sharing-based Access Control
Resource sharing is provided by Resource Access Manager (RAM) to help you securely share resources across accounts. Its permissions are defined by the system. A resource owner can create a resource share to grant permissions for associated resources and related APIs to accounts, organization units (OUs), or the entire organization. If you have multiple Huawei Cloud accounts, you can create resources once in one of your Huawei Cloud accounts and use RAM to share those resources with the other accounts. If your account joins an organization in the Organizations service, you can use RAM to share resources with all the other accounts in your organization, or with only accounts in one or more specified OUs of the organization. You can also share resources with a specific Huawei Cloud account by account ID, regardless of whether the account is part of the organization.
For details about how to use RAM to share resources, see Resource Access Manager User Guide.
Mandatory Access Control (MAC)
When an organization is migrated to the cloud, different services or environments (such as the testing environment and production environment) have different security isolation requirements. For service security isolation and R&D agility, an organization usually creates multiple accounts for different services and different environments. Each account administrator has full, independent permissions on resources under the account. In this case, any misoperations of the administrator or the credential leakage may cause organization-level security risks. To meet unified IT security and privacy requirements and provide organization-wide secure access control, you can use MAC (also known as guardrails).
MAC policies use the same policy language as DAC policies but they do not grant permissions to IAM identities. They only control the permission boundaries for IAM principals. MAC includes session policy-based permission control, SCP-based permission control, and VPC endpoint policy-based permission control.
SCP-based Access Control
Organizations helps you govern multiple Huawei Cloud accounts within your organization. Service Control Policies (SCPs) are guardrail policies provided by Organizations. SCP policies define the maximum permissions for member accounts of an organization or OU. The account administrator permissions and permissions granted to IAM users are restricted by SCPs. The administrator can use Organizations SCPs to control the maximum available permissions for all accounts in your organization. This helps you better meet the service security and compliance requirements of your business.
For details about SCPs, see Organizations User Guide.
VPC Endpoint Policy-based Access Control
Virtual Private Cloud (VPC) is used to control the network border security. If the API access point of a resource is within the VPC of your account, the access is within the VPC and the security is controllable (the VPC can be considered as a network security domain). If the API access point is in a public network, the network attack surface is large and security is hard to control.
VPC Endpoint (VPCEP) provides secure and private channels for applications in a VPC to access open cloud service APIs. Applications in a VPC can connect to cloud services through VPC endpoints instead of using EIPs. The VPC administrator can set VPC endpoint policies for a specific VPC endpoint for permissions control. VPC endpoint policies are guardrail policies that only allow API requests meeting the policy requirements to access cloud service APIs through the endpoint, but do not grant permissions.
For details about VPCEP policies, see the VPC Endpoint User Guide.
Session-based Access Control
An agency or trust agency can be granted permissions like a user by the security administrator. When an API is called for obtaining the temporary security credential, the generated temporary security credential has an assumed-agency/trust agency session. This temporary security credential does not inherit the permissions of the API caller. Instead, it inherits the permissions of the specified agency or trust agency. During the API calling, the caller can set a session policy to limit the maximum access permissions of the temporary security credential. The permissions of the temporary security credential are the intersection of the permissions granted to the agency or trust agency and the session policy, not beyond the scope of the specified session policy.
For details about how to use session policies, see Obtaining a Temporary Security Credential Through an Agency or Trust Agency.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot