Managing Projects, Users, and Roles

As an administrator, you manage projects, users, and roles using either the command-line interface (CLI) or the Dashboard. Projects are organizational units in the cloud to which you can assign users. Projects are also known as tenants or accounts. Users can be members of one or more projects. Roles define which actions users can perform. You can manage projects, users, and roles independently from each other.

Note
If you get an HTTP 401 error (The request you have made requires authentication) for CLI commands, make sure you are using admin credentials and that you have indicated the domain context for command using either the --domain or --user-domain parameters. When using the Identity v3 API on Metacloud 4.0 and later versions, you must indicate the domain context for the user.

During setup, the Metacloud Service Delivery team defines default projects, users, and roles, and sends credentials to the cloud administrator. As the administrator, you can then add, update, and delete projects and users, assign users to one or more projects, and change or remove the assignment. You can also change quotas at the project level. See Viewing and Managing Quotas for more information about quotas.

Note
The ability to assign roles to user-project pairs, and indicate the domain when assigning roles are supported in Metacloud 4.0 and later.

You can enable or temporarily disable a project or user by updating that project or user account. To delete a user, you must remove the user account from its primary project.

Managing Projects

A project is a group of users. In the Compute service, a project owns virtual machines. Users can be associated with more than one project. Each project and user pairing must have a role associated with it; otherwise, the user does not have a primary project. See Creating and Managing Roles for more information.

To list projects:

$ openstack project list
+-------------------+--------------------+
| ID                | Name               |
+-------------------+--------------------+
| <project_id>      | admin              |
| <project_id>      | default            |
| <project_id>      | demo               |
| <project_id>      | service            |
| <project_id>      | test_project       |
+-------------------+--------------------+

To create a project:

$ openstack project create --description <DESCRIPTION> <PROJECT_NAME> --domain <DOMAIN_NAME>
+-------------+-------------------------------+
| Field       | Value                         |
+-------------+-------------------------------+
| description | Development sandbox           |
| domain_id   | <domain_id>                   |
| enabled     | True                          |
| id          | <project_id>                  |
| is_domain   | False                         |
| name        | Dev Test Project              |
| parent_id   | None                          |
+-------------+-------------------------------+

Managing Domains

A domain is a high-level container made up of projects, users, and groups that define administrative boundaries for managing Identity entities. Domains can represent an individual, company, or operator-owned space. They expose administrative activities directly to system users. Users can be granted the administrator role for a domain. A domain administrator can create projects, users, and groups in a domain and assign roles to users and groups in a domain. A domain is a high-level container made up of projects, users, and groups, where users can have roles at the project and domain level. Using domains enables you to group resouces into projects. You can also assign an admin user for a domain to manage resources.

To create a domain:

Action Command
Create a domain $ openstack domain create <DOMAIN_NAME>
Disable a domain $ openstack domain set <DOMAIN_NAME> --disable
Delete a domain $ openstack domain delete <DOMAIN_NAME>

Updating a Project

Specify the project ID to update a project. You can update the name, description, and enabled status of a project.

Action Command
Disable a project $ openstack project set <PROJECT_ID> --disable
Enable a disabled project $ openstack project set <PROJECT_ID> --enable
Update the name of a project $ openstack project set <PROJECT_ID> --name <PROJECT_NAME>
Delete a project $ openstack project delete <PROJECT_ID>

To verify information for the updated project:

$ openstack project show <PROJECT_ID>
+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description | Department new project           |
| domain_id   | <domain_id>                      |
| enabled     | False                            |
| id          | <project_id>                     |
| is_domain   | False                            |
| name        | <project_name>                   |
| parent_id   | None                             |
+-------------+----------------------------------+

Managing Users

Defining user accounts gives people the ability to log into the Dashboard. Assigning users to projects allocates the resources the user can access and the quotas defined per-project. Multiple users can be managed within a domain and assigned roles that vary for each project.

Your cloud may have been configured with LDAP. If so, then the user login information is based on LDAP, but the end-user must enter the credentials in the Dashboard twice to automatically create their Metacloud user account. See Logging into the Dashboard for more information.

To list users:

You must specify a domain or a project to list users.

$ openstack user list --domain <DOMAIN_NAME>
+-----------------------+---------------+
| ID                    | Name          |
+-----------------------+---------------+
| <user_id>             | DOMAIN-admin  |
| <user_id>             | demo          |
| <user_id>             | interop       |
| <user_id>             | mc-user       |
+-----------------------+---------------+

Creating a User

To create a user with the CLI tool, you must specify a name. You can also specify a project ID, password, and email address. To enable logins, you must include the project ID and password because the user cannot log in to the Dashboard without this information. When using the Identity v3 API on Metacloud 4.0 and later versions, users must also enter their Domain information when logging in.

To create a new user:

$ openstack user create new-user \
   --domain <DOMAIN_NAME> \
   --project <PROJECT_NAME> \
   --password <PASSWORD> \

+--------------------+-----------------+
| Field              | Value           |
+--------------------+-----------------+
| default_project_id | <project_id>    |
| domain_id          | <domain_id>     |
| enabled            | True            |
| id                 | <user_id>       |
| name               | new-user        |
+--------------------+-----------------+

Note
When using the Identity v3 API on Metacloud 4.0 and later versions, you must indicate the domain context for the new user with the --domain parameter.

Updating a User (Identity v2.0 API only)

Note
When using Metacloud version 4.0 and later, use the Dashboard to update user accounts. A bug in the openstack client prevents you from setting the necessary domain context to run these commands.

You can update the name, email address, and enabled status for a user. If you disable a user account, the user cannot log in to the Dashboard. However, data for the user account is maintained, so you can enable the user at any time.

Action Command
Disable a user $ openstack user set <USER_NAME> --disable --domain <DOMAIN_NAME>
Enable a user $ openstack user set <USER_NAME> --enable --domain <DOMAIN_NAME>
Change the user name and email $ openstack user set <USER_NAME> --name <USER_NAME> --email <USER_EMAIL> --domain <DOMAIN_NAME>
Delete a user $ openstack user delete <USER_NAME> --domain <DOMAIN_NAME>

Managing Roles and Role Assignments

Metacloud is configured with two roles by default: Admin and Member (which appears as _member_ in the CLI). An Orchestration role named heat_stack_user is also configured for running Orchestration commands with the CLI.

To list available roles:

$ openstack role list
+-------------------+-----------------+
| ID                | Name            |
+-------------------+-----------------+
| <user_id>         | heat_stack_user |
| <user_id>         | admin           |
| <user_id>         | member_         |
+-------------------+-----------------+

Assigning a Role

To assign a user to a project, you must assign the role to a user-project pair. To do this, you need the user, role, and project IDs. When using the Identity v3 API on Metacloud 4.0 and later versions, you must also indicate the --domain context.

  1. List users and note the user ID you want to assign to the role.

    $ openstack user list --domain <DOMAIN_NAME>
    +----------------+---------------+
    | ID             | Name          |
    +----------------+---------------+
    | <user_id>      | DOMAIN-admin  |
    | <user_id>      | demo          |
    | <user_id>      | interop       |
    | <user_id>      | mc-user       |
    +----------------+---------------+
    
  2. List role IDs and note the role ID you want to assign:

    $ openstack role list
    +-----------------+-----------------+
    | ID              | Name            |
    +-----------------+-----------------+
    | <user_id>       | heat_stack_user |
    | <user_id>       | admin           |
    | <user_id>       | _member_        |
    +-----------------+-----------------+
    
  3. List projects and note the project ID you want to assign to the role.

    $ openstack project list
    +----------------+---------------+
    | ID             | Name          |
    +----------------+---------------+
    | <project_id>   | service       |
    | <project_id>   | demo          |
    +----------------+---------------+
    

    Note
    Use the --long parameter to show more fields than ID and Name.

  4. Assign a role to a user-project pair, including the user’s domain when using Identity v3.

    $ openstack role add --user <USER_NAME> --project <PROJECT_ID> --user-domain <DOMAIN_NAME> <ROLE_NAME>
    
  5. Verify the role assignment.

    $ openstack role assignment list --user <USER_NAME> --user-domain <DOMAIN_NAME>
    +--------+-----------+-------+------------------------+--------+-----------+
    | Role   | User      | Group | Project                | Domain | Inherited |
    +--------+-----------+-------+------------------------+--------+-----------+
    | <role> | <user_id> |       | <project_id>           |        | False     |
    | <role> | <user_id> |       | <project_id>           |        |           |
    +--------+-----------+-------+------------------------+--------+-----------+
    

To view role details:

$ openstack role show <ROLE_NAME>
+-------+-------------+
| Field | Value       |
+-------+-------------+
| id    | <role_id>   |
| name  | _member_    |
+-------+-------------+

To remove a role from a user-project pair:

  1. Remove the role from a user. Indicate the project and domain when using Identity v3.

    $ openstack role remove --user <USER_NAME> --project <PROJECT_ID> --user-domain <DOMAIN_NAME> <ROLE_NAME>
    
  2. Verify the role removal.

    $ openstack role assignment list --user <USER_NAME> --user-domain <DOMAIN_NAME>
    

    If the user has no assigned roles, the command output returns a single line.

Using Groups

A group is a collection of users in a domain. Administrators can create groups and add users to them. A role can then be assigned to the group, rather than individual users. Groups are included in Identity API v3.

Identity API V3 provides the following group-related operations:

  • Create a group

  • Delete a group

  • Update a group (change its name or description)

  • Add a user to a group

  • Remove a user from a group

  • List group members

  • List groups for a user

  • Assign a role on a project to a group

  • Assign a role on a domain to a group

  • Query role assignments to groups

For example:

  • Group A is granted Role A on Project A. If User A is a member of Group A, when User A gets a token scoped to Project A, the token also includes Role A.

  • Group B is granted Role B on Domain B. If User B is a member of Group B, when User B gets a token scoped to Domain B, the token also includes Role B.

Note
The server that houses the Identity service might not allow all operations. For example, if you use the Identity server with the LDAP Identity back end and group updates are disabled, a request to create, delete, or update a group fails.