Project hierarchies

You can nest projects by using hierarchical multitenancy (HMT) in the Identity service (keystone), so that sub-projects inherit role assignments from a parent project and you can manage access at scale.

Note
You must manage quotas individually against projects and sub-projects because nested quotas are not supported.

Create hierarchical projects and sub-projects
Copy link

Create hierarchical projects and sub-projects to organize cloud resources into a multitiered structure, so that you can delegate administration and manage access through inherited role assignments.

About this task
Copy link

To implement hierarchical multitenancy (HMT), first create a new Identity service (keystone) domain and then create a project within that domain. You can then add sub-projects to that project. You can also promote a user to administrator of a sub-project by adding the user to the admin role for that sub-project.

Note
The HMT structure used by the Identity service is not currently represented in the dashboard.

Procedure
Copy link

  1. Create a new Identity service domain called corp: 
    $ openstack domain create corp

    For example:

    +-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description |                                  |
| enabled     | True                             |
| id          | 6059b0b93b8d4ddb9d31ea47de93f0ab |
| name        | corp                             |
| options     | {}                               |
| tags        | []                               |
+-------------+----------------------------------+
  2. Create the parent project (private-cloud) within the corp domain: 
    $ openstack project create private-cloud --domain corp

    For example:

    +-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description |                                  |
| domain_id   | 6059b0b93b8d4ddb9d31ea47de93f0ab |
| enabled     | True                             |
| id          | e86f182e16e24441b71c7296585c2e21 |
| is_domain   | False                            |
| name        | private-cloud                    |
| options     | {}                               |
| parent_id   | 6059b0b93b8d4ddb9d31ea47de93f0ab |
| tags        | []                               |
+-------------+----------------------------------+
  3. Create a sub-project (dev) within the private-cloud parent project, while also specifying the corp domain: 
    $ openstack project create dev --parent private-cloud --domain corp

    For example:

    +-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description |                                  |
| domain_id   | 6059b0b93b8d4ddb9d31ea47de93f0ab |
| enabled     | True                             |
| id          | 71f05cdd5b8a45d4b1a928bfe7c2e20d |
| is_domain   | False                            |
| name        | dev                              |
| options     | {}                               |
| parent_id   | e86f182e16e24441b71c7296585c2e21 |
| tags        | []                               |
+-------------+----------------------------------+
  4. Create another sub-project called qa: 
    $ openstack project create qa --parent private-cloud --domain corp

    For example:

    +-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description |                                  |
| domain_id   | 6059b0b93b8d4ddb9d31ea47de93f0ab |
| enabled     | True                             |
| id          | 03801ad929b84c8fb091bf3248e6db68 |
| is_domain   | False                            |
| name        | qa                               |
| options     | {}                               |
| parent_id   | e86f182e16e24441b71c7296585c2e21 |
| tags        | []                               |
+-------------+----------------------------------+
    Note
    You can use the Identity API to view the project hierarchy. For more information, see https://developer.openstack.org/api-ref/identity/v3/index.html?expanded=show-project-details-detail

Configure access to hierarchical projects
Copy link

Configure access to hierarchical projects by using inherited role assignments, so that you can grant consistent permissions across parent and child projects without managing each sub-project individually.

About this task
Copy link

By default, a newly-created project has no assigned roles. When you assign role permissions to the parent project, you can include the --inherited flag to instruct the sub-projects to inherit the assigned permissions from the parent project. For example, a user with admin role access to the parent project also has admin access to the sub-projects.

Procedure
Copy link

  1. View the existing permissions assigned to a project: 
    $ openstack role assignment list --project private-cloud
  2. View the existing roles: 
    $ openstack role list

    For example:

    +----------------------------------+-----------------+
| ID                               | Name            |
+----------------------------------+-----------------+
| 01d92614cd224a589bdf3b171afc5488 | admin           |
| 034e4620ed3d45969dfe8992af001514 | member          |
| 0aa377a807df4149b0a8c69b9560b106 | ResellerAdmin   |
| cfea5760d9c948e7b362abc1d06e557f | reader          |
| d5cb454559e44b47aaa8821df4e11af1 | swiftoperator   |
| ef3d3f510a474d6c860b4098ad658a29 | service         |
+----------------------------------+-----------------+
  3. Grant the user account user1 access to the private-cloud project: 
    $ openstack role add --user user1 --user-domain corp --project private-cloud member

    Re-run this command by using the --inherited flag. As a result, user1 also has access to the private-cloud sub-projects, which have inherited the role assignment:

    $ openstack role add --user user1 --user-domain corp --project private-cloud member --inherited
  4. Review the result of the permissions update: 
    $ openstack role assignment list --effective --user user1 --user-domain corp

    For example:

    +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
| Role                             | User                             | Group | Project                          | Domain | Inherited |
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
| 034e4620ed3d45969dfe8992af001514 | 10b5b34df21d485ca044433818d134be |       | c50d5cf4fe2e4929b98af5abdec3fd64 |        | False     |
| 034e4620ed3d45969dfe8992af001514 | 10b5b34df21d485ca044433818d134be |       | 11fccd8369824baa9fc87cf01023fd87 |        | True      |
| 034e4620ed3d45969dfe8992af001514 | 10b5b34df21d485ca044433818d134be |       | b4f1d6f59ddf413fa040f062a0234871 |        | True      |
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+

    The user1 user has inherited access to the qa and dev projects. In addition, because the --inherited flag was applied to the parent project, user1 also receives access to any sub-projects that are created later.

Revoke user access from a project
Copy link

Remove user access from projects to enforce least-privilege security, so that former or reassigned users can no longer view project data or consume system resources.

About this task
Copy link

Note
Explicit and inherited permissions must be separately removed.

Procedure
Copy link

  1. Remove a user from an explicitly assigned role: 
    $ openstack role remove --user user1 --project private-cloud member
  2. Review the result of the change. Notice that the inherited permissions are still present: 
    $ openstack role assignment list --effective --user user1 --user-domain corp

    For example:

    +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
| Role                             | User                             | Group | Project                          | Domain | Inherited |
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
| 034e4620ed3d45969dfe8992af001514 | 10b5b34df21d485ca044433818d134be |       | 11fccd8369824baa9fc87cf01023fd87 |        | True      |
| 034e4620ed3d45969dfe8992af001514 | 10b5b34df21d485ca044433818d134be |       | b4f1d6f59ddf413fa040f062a0234871 |        | True      |
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
  3. Remove the inherited permissions: 
    $ openstack role remove --user user1 --project private-cloud member --inherited
  4. Review the result of the change. The inherited permissions have been removed, and the resulting output is now empty: 
    $ openstack role assignment list --effective --user user1 --user-domain corp