SupportConsoleDevelopersStart a trialContact

Chapter 7. Managing projects

Create and manage projects in Red Hat OpenStack Services on OpenShift (RHOSO). A project is a pool of shared virtual resources, to which you can associate OpenStack users and groups. Each user and group can be associated with more than one project and must have an assigned role for each project.

You can configure the quota of shared virtual resources in each project. You can create multiple projects that will not interfere with each other’s permissions and resources.

7.1. Creating a project
Copy link

As an OpenStack administrator, you can create a project, which is a pool of shared virtual resources, to which you can assign members or OpenStack users and groups. You can also configure the quota or resource limits of the shared virtual resources in this project.

Procedure

  1. Log in to the Dashboard as a user with administrative privileges.
  2. Select Identity > Projects.
  3. Click Create Project.
  4. On the Project Information tab, enter a name and description for the project. The Enabled checkbox is selected by default.
  5. On the Project Members tab, add members to the project from the All Users list.
  6. On the Quotas tab, specify resource limits for the project.
  7. Click Create Project.

7.2. Editing a project
Copy link

As an OpenStack administrator, you can edit a project in Red Hat OpenStack Services on OpenShift (RHOSO) to change its name or description, enable or temporarily disable it, or update its members or OpenStack users and groups.

Note

The Enabled checkbox is selected by default. To temporarily disable the project, clear the Enabled checkbox. To enable a disabled project, select the Enabled checkbox.

Procedure

  1. Log in to the Dashboard as a user with administrative privileges.
  2. Select Identity > Projects.
  3. In the project Actions column, click the arrow, and click Edit Project.
  4. In the Edit Project window, you can update a project to change its name or description, and enable or temporarily disable the project.
  5. On the Project Members tab, add members to the project, or remove them as needed.
  6. Click Save.

7.3. Deleting a project
Copy link

As an OpenStack administrator, you can delete a project in Red Hat OpenStack Services on OpenShift (RHOSO) to clean up your environment. This removes the project and ensures that users can no longer access its resources. Any user pairing is disassociated to prevent unauthorized access to unused workloads.

Note

You cannot undo this delete action.

Procedure

  1. Log in to the Dashboard as a user with administrative privileges.
  2. Select Identity > Projects.
  3. Select the project that you want to delete.
  4. Click Delete Projects. The Confirm Delete Projects window is displayed.
  5. Click Delete Projects to confirm the action.

7.4. Updating project quotas
Copy link

Quotas are operational limits that you set for each Red Hat OpenStack Services on OpenShift (RHOSO) project to optimize cloud resources. As an OpenStack administrator, you can set quotas to prevent project resources from being exhausted without notification. You can enforce quotas at both the project and the project-user level.

Note

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

Procedure

  1. Log in to the Dashboard as a user with administrative privileges.
  2. Select Identity > Projects.
  3. In the project Actions column, click the arrow, and click Modify Quotas.
  4. In the Quota tab, modify project quotas as needed.
  5. Click Save.

7.5. Changing the active project
Copy link

As a member of more than one project, including this Red Hat OpenStack Services on OpenShift (RHOSO) project, you can set this project as the active project, so that you can use the dashboard to interact with objects in the project.

Note

You cannot set a disabled project as active, unless it is re-enabled.

Procedure

  1. Log in to the Dashboard as a user with administrative privileges.
  2. Select Identity > Projects.
  3. In the project Actions column, click the arrow, and click Set as Active Project.
  4. Alternatively, as a non-admin user, in the project Actions column, click Set as Active Project which becomes the default action in the column.

7.6. Project hierarchies
Copy link

You can nest projects by using hierarchical multitenancy (HMT) in the Identity service (keystone). Hierarchical multitenancy allows sub-projects to inherit role assignments from a parent project.

Note

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

Create hierarchical projects in Red Hat OpenStack Services on OpenShift (RHOSO) to organize cloud resources. As an OpenStack administrator you can implement hierarchical multitenancy (HMT) by using Identity service (keystone) domains and RHOSO projects.

First create a new 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

  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

7.6.2. Configuring access to hierarchical projects
Copy link

Configure access to hierarchical projects in Red Hat OpenStack Services on OpenShift (RHOSO) to streamline permission management. By organizing projects into a hierarchy, you can enable child projects to inherit permission settings from parents, ensuring consistent access controls across the environment.

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

  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.

7.6.3. Removing access from users
Copy link

Remove access from users in Red Hat OpenStack Services on OpenShift (RHOSO) projects to enforce least privilege. Revoking role assignments ensures that unauthorized users cannot view project data or consume system resources.

Note

Explicit and inherited permissions must be separately removed.

Procedure

  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

7.6.4. Reseller project overview
Copy link

With the Reseller Red Hat OpenStack Services on OpenShift (RHOSO) project, the goal is to have a hierarchy of domains; these domains will eventually allow you to consider reselling portions of the cloud, with a subdomain representing a fully-enabled cloud. This work has been split into phases, with phase 1 described below:

Reseller (phase 1) is an extension of hierarchical multitenancy (HMT), described in the Additional resources section below. Previously, Identity service (keystone) domains were originally intended to be containers that stored users and projects, with their own table in the database back-end. As a result, domains are now no longer stored in their own table, and have been merged into the project table:

  • A domain is now a type of project, distinguished by the is_domain flag.
  • A domain represents a top-level project in the project hierarchy: domains are roots in the project hierarchy

  • APIs have been updated to create and retrieve domains using the projects subpath:

    • Create a new domain by creating a project with the is_domain flag set to true
    • List projects that are domains: get projects including the is_domain query parameter.

7.7. Project security management
Copy link

Security groups isolate tenant workloads by using IP filter rules that define instance networking access. Project members can edit default rules and add new rule sets for their project-specific security groups.

All projects have a default security group that is applied to any instance that has no other defined security group. Unless you change the default values, this security group denies all incoming traffic and allows only outgoing traffic from your instance.

You can apply a security group directly to an instance during instance creation, or to a port on the running instance.

Note

You cannot apply a role-based access control (RBAC)-shared security group directly to an instance during instance creation. To apply an RBAC-shared security group to an instance you must first create the port, apply the shared security group to that port, and then assign that port to the instance. For more information, see the Additional resources section below.

Do not delete the default security group without creating groups that allow required egress. For example, if your instances use DHCP and metadata, your instance requires security group rules that allow egress to the DHCP server and metadata agent.

7.7.2. Creating a security group
Copy link

Create a security group in Red Hat OpenStack Services on OpenShift (RHOSO) to filter network traffic. This virtual firewall defines access rules for your instances, ensuring only authorized connections reach your workloads. For example, you can enable ICMP traffic, or disable HTTP requests.

Procedure

  1. In the dashboard, select Project > Compute > Access & Security.
  2. On the Security Groups tab, click Create Security Group.
  3. Enter a name and description for the group, and click Create Security Group.

7.7.3. Adding a security group rule
Copy link

Add a rule to a security group in Red Hat OpenStack Services on OpenShift (RHOSO) to permit specific network traffic. This configuration opens necessary ports and protocols, ensuring that your instances can communicate securely with authorized external resources.

By default, rules for a new group only provide outgoing access. You must add new rules to provide additional access.

Procedure

  1. In the dashboard, select Project > Compute > Access & Security.
  2. On the Security Groups tab, click Manage Rules for the security group that you want to edit.
  3. Click Add Rule to add a new rule.

  4. Specify the rule values, and click Add.

    The following rule fields are required:

    Rule

    Rule type. If you specify a rule template (for example, SSH), its fields are automatically filled in:

    • TCP: Typically used to exchange data between systems, and for end-user communication.
    • UDP: Typically used to exchange data between systems, particularly at the application level.
    • ICMP: Typically used by network devices, such as routers, to send error or monitoring messages.
    Direction
    Ingress (inbound) or Egress (outbound).
    Open Port

    For TCP or UDP rules, the Port or Port Range (single port or range of ports) to open:

    • For a range of ports, enter port values in the From Port and To Port fields.
    • For a single port, enter the port value in the Port field.
    Type
    The type for ICMP rules; must be in the range -1:255.
    Code
    The code for ICMP rules; must be in the range -1:255.
    Remote

    The traffic source for this rule:

    • CIDR (Classless Inter-Domain Routing): IP address block, which limits access to IPs within the block. Enter the CIDR in the Source field.
    • Security Group: Source group that enables any instance in the group to access any other group instance.

7.7.4. Deleting a security group rule
Copy link

Delete a security group rule in Red Hat OpenStack Services on OpenShift (RHOSO) to revoke specific network access. Removing unused rules closes open ports, which reduces security risks by blocking unwanted traffic to your instances.

Note

You cannot undo the delete action.

Procedure

  1. In the dashboard, select Project > Compute > Access & Security.
  2. On the Security Groups tab, click Manage Rules for the security group.
  3. Select the security group rule, and click Delete Rule.
  4. Click Delete Rule again.

7.7.5. Deleting a security group
Copy link

Delete a security group in Red Hat OpenStack Services on OpenShift (RHOSO) to retire unused firewall policies. Removing obsolete groups creates a cleaner view for users and prevents the accidental application of incorrect network access rules to workloads.

Note

You cannot undo the delete action.

Procedure

  1. In the dashboard, select Project > Compute > Access & Security.
  2. On the Security Groups tab, select the group, and click Delete Security Groups.
  3. Click Delete Security Groups.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Legal Notice

Theme

© 2026 Red HatBack to top