Resource and Permission System
Keystone's resource and permission system is defined by three types of resources: projects, roles, and permissions. Projects are the ownership of resources. To use resources, users must join corresponding projects with specific roles. Roles are associated with policies, defining user permissions.
Projects
Projects are resource owners. All virtual resources must belong to a project. After users or user groups join a project, they can be authorized to access resources after obtaining permissions.
Projects are generally referred to as Project, but for compatibility with Keystone v2 API, they are occasionally referred to as Tenant.
Attributes
| Field | Description |
|---|---|
| id | Project ID |
| name | Project name |
| domain_id | Domain ID to which the project belongs |
| project_domain | Name of the domain to which the project belongs |
Restrictions
Before v3.7, users or groups could only join projects under the same domain or projects under the default domain. Projects under the default domain can join users or groups from any domain. Projects under non-default domains can only join users or groups from the same domain. After v3.7, this restriction was removed. Users or groups from any domain can join projects under any domain.
Projects with external resources in other services cannot be deleted. Resources from other services are pulled every 15 minutes by default, configured through the parameter: fetch_project_resource_count_interval_seconds.
Projects containing users and groups cannot be deleted
The system project cannot be deleted or modified
Project Namespace
The project namespace is global, meaning project names are globally unique
Preset Projects
When the system is initialized, a system project is preset as the project for sysadmin
Roles
Roles are the roles users have when joining projects. User roles determine user permissions.
Attributes
Role attributes are as follows:
| Field | Description |
|---|---|
| id | ID, cannot be modified |
| name | Name, can be modified |
| public_scope | Sharing scope, optional values are system (global sharing), domain (domain sharing) |
| policies | List of permission names at various levels corresponding to this role |
| match_policies | List of all permission names corresponding to this role |
Restrictions
Users under a domain can only use roles from the project's domain or shared roles to join projects
A role used by users or groups cannot be deleted
Shared roles cannot be deleted
The admin role cannot be deleted
Role Namespace
The role namespace is global, meaning role names are globally unique
Preset Roles
When the system is initialized, an admin role is preset as the default role for system user sysadmin to join the system project
At the same time, after system initialization is complete, the installer will automatically create the following shared projects for user convenience:
| Role Name | Shared | Meaning | Use Case |
|---|---|---|---|
| admin | Yes | Global Administrator | System administrator role, highest permission role |
| sa | Yes | Operations Administrator | Generally assigned to operations personnel |
| fa | Yes | Finance Administrator | Generally assigned to finance personnel |
| domainfa | Yes | Domain Finance Administrator | Generally assigned to finance personnel within the domain |
| projectfa | Yes | Project Finance Administrator | Generally assigned to finance personnel within the project |
| project_owner | Yes | Project Manager | Generally assigned to project administrators |
| project_editor | Yes | Project Operator | Generally assigned to administrators within the project, but lacks permissions to create and delete resources |
| project_viwer | Yes | Project Read-Only Personnel | Generally assigned to ordinary members of the project, can only view, cannot operate, create, or delete resources |
| domainadmin | Yes | Domain Administrator | Generally assigned to domain administrators |
| domaineditor | Yes | Domain Administrator | Generally assigned to domain administrators |
| domainviewer | Yes | Domain Administrator | Generally assigned to domain administrators |
Permission Policies
Permissions define permission matching rules, permission scope, and permission definitions
Attributes
Permission policy attributes are as follows:
| Attribute | Type | Description |
|---|---|---|
| id | String | ID |
| name | String | Name |
| policy | JSONObject | Policy definition, stored in JSON format, can be presented in yaml or json format |
| scope | String | Permission definition scope of the policy, project (project scope permissions), domain (domain scope permissions), or system (system/global permissions) |
| public_scope | String | Sharing scope of the policy, none (not shared), domain (shared to specified domain), system (globally shared) |
| Domain_id | String | Domain ID to which it belongs |
| Project_Domain | String | Name of the domain to which it belongs |
| Is_System | boolean | Whether it is a system-defined permission policy |
| enabled | boolean | Whether this policy is enabled |
Permission Policy Definition
The Policy field of permission policies stores the definition. Each permission policy contains the following fields:
| Permission Definition | Type | Specific permission definition, i.e., whether there is permission for specific operations on specific resources of specific services |
|---|---|---|
| Service | string | Applicable service, for example: compute, identity |
| Resource | string | Applicable resource type, for example: servers |
| Operation | string | Applicable operation. Supported operations are |
| Result | string | Policy result, only two values: Allow and Deny |
Supported operations for Operation are as follows:
| Operation | Description |
|---|---|
| list | List all resources |
| get | Get details of specified resource |
| create | Create new resource |
| update | Update |
| delete | Delete |
| perform | Perform operation, for example, power on/off operations on hosts |
Permission Policy Examples
- Administrator permissions
scope: system
policy:
'*': allow
- Read-only for compute service within project
scope: project
policy:
compute:
get: allow
list: allow
'*': deny
- Compute service operator within domain (cannot create and delete resources)
scope: domain
policy:
compute:
'*':
create: deny
delete: deny
'*': allow
System Preset Policies
For convenience, the system has preset more than 150 permission policies, such as system administrator sysadmin, domain administrator domainadmin, project owner: projectadmin, etc.
Among them, to use the web console, users need to have some special permissions, which are predefined in these preset permission policies: sys-dashboard, domain-doshboard, project-dashboard, corresponding to system view, domain view, and project view web console permissions respectively. If a role needs to access the web console, the corresponding permission policy needs to be added to that role.
The following are commonly used preset permissions:
| Permission Name | Permission Scope | Permission Content |
|---|---|---|
| sysadmin | Global | Global Administrator |
| syseditor | Global | Global Operator, has all permissions of sysadmin except for permissions to create and delete resources |
| sysviewer | Global | Global Read-Only Administrator, has permissions to list and get resource information globally |
| domain-admin | Domain | Administrator permissions for the domain where the user joins the project |
| domain-editor | Domain | All operation permissions for the domain where the user joins the project, does not have permissions to create and delete resources |
| domain-viewer | Domain | All read-only permissions for the domain where the user joins the project |
| project-admin | Project | Administrator permissions for the project the user joins |
| project-editor | Project | Operator permissions for the project the user joins, does not have permissions to create and delete resources |
| project-viewer | Project | All read-only permissions for the project the user joins |
Roles and Permissions
Roles need to be associated with permissions. The association relationship is defined in the role_policy association table. This association relationship has the following attributes, defining the conditions for role and permission association:
| Attribute | Type | Required Field | Description |
|---|---|---|---|
| role_id | string | Yes | Role ID |
| policy_id | string | Yes | Permission policy ID |
| project_id | string | No | If a project is set, the user only has the corresponding permissions when joining that project with the specified role |
| ips | string | No | IP whitelist where permissions take effect. If IPS is set, users only have corresponding permissions when logging in through matching IPs |
| valid_since | time | No | Start time when permissions take effect. If set, permissions only take effect after this time point |
| valid_until | time | No | End time when permissions take effect. If set, permissions are valid before this time point and invalid after |
For example, if sysadmin permissions are associated with the admin role, and project_id is the ID of the system project, then users must join the system project with the admin role to have sysadmin permissions.