Permissions Management Based on ABAC

In IAM, authorization is the key to ensuring that principals have the correct access permissions. There are two types of models to implement access control: attribute-based access control (ABAC) and role-based access control (RBAC). Understanding the differences between the two models helps you design more secure and efficient access control solutions.

Definition

ABAC: ABAC is an authorization strategy that is attached to IAM identities (such as IAM users) and defines permissions based on attributes. It uses policies to determine access authorization in real time based on a combination of attributes such as subjects, resources, operations, and environments. For example, you can specify that only users with the Project=Alpha tag can access resources with the Project=Alpha tag.
RBAC: RBAC is a strategy that defines permissions based on a user's function or role in an organization. In IAM, you implement RBAC by creating different policies or using predefined roles on Huawei Cloud for different job functions. You then attach the policies to IAM identities (such as IAM users) and restrict their access (such as within a project). For example, you can assign the Huawei Cloud predefined CCE Administrator role to a container administrator and restrict its permissions to project Alpha.

In the following example, employees need to work on three projects (Alpha, Beta, and Gamma) and access ECS resources, you can assign the ECS Administrator role to them and restrict their permissions to these projects respectively. Then, they can access cloud service resources only within the authorized scope. If an employee's job changes and the employee needs to access the containers provided by CCI, or user C needs to access resources in project Beta, you must create a new role authorization relationship and update the authorization scope.

With ABAC, you can create identity policies to allow specific identities to access cloud service resources with specific tags (for example, Project=Beta or Project=Gamma). You can manage access control for identities or resources based on tags, without repeatedly adjusting policies or authorization relationships.

Figure 1 An example
Click to enlarge

Core Differences

**Table 1** Core differences
Feature	RBAC	ABAC
Authorization relationship	Identities - Roles - Permission Scope	Identities - Policies
Authorization basis	Predefined roles and functions	Dynamic attributes of identities, resources, environments, etc.
Number of policies	More policies are often needed as functions and resources increase.	Fewer policies are usually required because policies are based on attributes rather than a specific principal.
Scalability	You may need to update existing policies manually when adding new resources or functions.	Permissions can be automatically extended with new resources. You do not need to modify existing policies.
Permission granularity	Access permissions to specific resources are usually granted.	Access is authorized based on diverse condition control attributes.
Management complexity	It may become complex in large or rapidly changing environments.	It is easier to manage permissions of new projects or personnel changes.

IAM policies implement policy-based roles. The authorization is based on the identity-role-authorization scope relationship. Identity policies, however, are based on the identity-policy relationship.
IAM identity policies support complete ABAC access control conditions, including dynamic attributes based on identities, resources, and environments. Compared with policies, identity policies support more access control condition keys. For details, see Global Condition Key. In addition, identity policies support richer policy syntax. For details, see JSON Element Reference.

Advantages of ABAC over RBAC

Dynamic response to changes and growth: Permissions for new resources are automatically granted as long as the attributes match. You do not need to manually assign policies to identities. This greatly simplifies permissions management when new projects start or team members change.
More fine-grained access control: ABAC allows you to use attributes based on principals, resources, actions, and environment contexts.
Fewer policies and easier management: ABAC usually requires fewer policies. You do not need to create separate policies for each job function, so you can easily manage and maintain policies.
Integration with enterprise identity providers: ABAC allows you to map employee attributes on an external identity provider (IdP) to IAM identity tags (via IAM Identity Center) and control access based on these tags. For details, see ABAC Overview and Configuration Process.