Introduction
Previous versions of API7 Enterprise provided a simple, user-friendly, and comprehensive RBAC (Role-Based Access Control) management mechanism. This mechanism ensured system security while granting users flexible role permission configuration. As the types of resources and features of API7 Enterprise have increased, the traditional RBAC management gradually revealed its limitations in fine-grained control of permissions. Moreover, more enterprises are seeking more refined permission management strategies to meet their complex and changing business needs.
To further enhance the permission management features of API7 Enterprise, we have comprehensively upgraded the existing role permission system by introducing a more flexible and powerful IAM (Identity and Access Management) policy model. This model provides users with finer-grained permission control and greater flexibility, better meeting the complex and variable permission management needs of modern enterprises.
What Is IAM Policy Model?
The IAM (Identity and Access Management) policy model represents a more detailed and efficient method of permission management. It allows administrators to define specific policies, each containing a set of rules (Statements). These rules specify in detail which users or roles can perform which actions on which resources. Compared to the traditional RBAC mechanism, this model offers greater flexibility and granularity.
Advantages of IAM over RBAC:
Granular Control: IAM can control permissions at the resource level and even for specific attributes or operations within resources, whereas RBAC often assigns permissions based on roles, with relatively coarse granularity.
Flexibility: IAM allows administrators to manage policies and permissions directly without needing to create and manage numerous roles for indirect permission assignment, making the configuration more straightforward and flexible.
Scalability: As system functionalities increase and resource types diversify, IAM can more easily adapt to changes by adding new policies to meet new permission needs, while RBAC may require the adjustment or addition of numerous roles to accommodate changes.
How to Use IAM Policies in API7 Enterprise?
1. Create Permission Policies
After logging into API7 Enterprise, click the "Organization" button at the top right, and select the "Permission Policies" menu item from the dropdown menu.
In the Permission Policies section, you can manage all policies. By default, there is a super-admin-permission-policy for the initial administrator.
Click the "Add Policy" button at the top right to enter the policy creation form. Here, you need to fill in the basic information of the Policies and configure the permissions in the Policy Editor, referred to as Statements.
Statements are the core components of a policy, consisting of one or more statements. Each statement defines a specific access permission rule.
Effect: Specifies the effect of the statement, usually
"Allow"or"Deny". A resource can be affected by multiple policies, and the IAM system determines the final access permissions based on the order and logic of the statements.Action: Defines a series of allowed or denied actions, such as
"gateway:DeleteGatewayGroup"or"iam:GetUser". These actions must be used in conjunction with resources (Resource) to be meaningful.Resource: Specifies the resources to which the statement applies, such as a specific gateway group or service. Wildcards (e.g.,
<.*>) can be used to match multiple resources.Condition (optional): Defines the conditions under which the statement will be effective. For example,
"conditions": {
"gateway_group_label": {
"type": "MatchLabel",
"options": {
"key": "type",
"operator": "exact_match",
"value": "production"
}
}
},
This represents that the operations defined in the statement are allowed to be effective only when the gateway group label is set to "production".
For example, to create a policy that restricts a user to only editing all published services within a specific gateway group, you can write it as follows:
{
"statement": [
{
"resources": [
"arn:api7:gateway:gatewaygroup/{gateway group id}"
],
"actions": [
"<.*>Get<.*>" // Allow executing all operations starting with 'Get', which represent the 'read' permission for the specified gateway group
],
"effect": "allow" // Allow executing the operations defined above
// Note: This policy statement allows performing all 'Get' operations on the specified gateway group, such as retrieving gateway group information, listing services within the gateway group, etc.
},
{
"resources": [
"arn:api7:gateway:gatewaygroup/{gateway group id}/publishedservice/<.*>",
],
"actions": [
"<.*>" // Allow executing all operations
],
"effect": "allow" // Allow executing the operations defined above
// This policy statement allows performing all operations (create, read, update, delete, etc.) on the published services within the specified gateway group.
}
]
}
In this example, we defined two sets of resources (gateway group and published services within the gateway group) and set the allowed actions for each. Some common policy configuration examples can be found in the doc Permission Policy Examples. For the available values of resources and actions and the corresponding APIs, refer to the doc Permission Policy Actions and Resources.
After creating a policy, it cannot be directly assigned to users; we need to assign the policy to specific roles first.
2. Create Roles and Attach Policies
After logging into API7 Enterprise, click the "Organization" button at the top right, and select the "Roles" menu item from the dropdown menu.
In the Roles section, you can manage all roles. By default, there is a Super Admin role as the built-in administrator role.
Click the "Add Custom Role" button at the top right to enter the role creation form. Here, you need to fill in the basic information of the role. After creation, we will enter the role details page.
In the role details page, click the "Attach Policy" button to assign the previously created permission policies to the role.
The created policies can be reused across multiple roles. When a role is associated with multiple policies, these policies are combined by default. That is, the permissions of a role are the sum of the permissions declared in all associated policies. After creating a role and attaching policies, we can assign the role to specific users.
3. Assign Roles to Users
After logging into API7 Enterprise, click the "Organization" button at the top right, and select the "Users" menu item from the dropdown menu.
In the Users section, you can manage all users. By default, there is an admin role as the built-in administrator.
In the right-side action column of the role list, click "Update Roles" to open the form drawer for updating the role of a specific user.
A user can have multiple roles. When a user is granted multiple roles, the permissions are combined. That is, the user has the sum of the permissions of all roles.
Simplified Role Mapping
With the optimization and upgrade of the user role model, the SSO role mapping process has been simplified. Now, when configuring the role mapping for login options, there is no need to set resource-level matching rules for each role individually. The resource and operation permissions are directly inherited from the selected built-in roles, making the permission configuration more intuitive and simplifying the complexity of permission management.
Summary
The introduction of IAM policies has enabled more flexible permission configuration and management. This adjustment not only enhances system security but also provides users with a greater possibility for customization.
In the future, we will continue to expand the types of resources supported by IAM policies, ensuring that all system resources can be included in fine-grained permission management, and continuously optimizing the policy editing and management interface, bringing users a more comprehensive and efficient permission management experience.
Top comments (0)