Red Hat OpenStack Administration I: Core Operations for Domain Operators

After completing this section, you should be able to manage users and groups accessed from an enterprise identity management directory, and assign users with selected roles and privileges to projects.

Domains are used to organize users and resources for an autonomous organization. The size of an organization is not usually relevant, but what matters is that the organization has practical ownership or management control of the employees and physical resources that are used in the domain. Multiple departments or divisions with separate budgets, policies, and personnel in larger organizations would typically be configured with separate domains.

In the real world, organizations would not create users directly in the OpenStack identity service database. Risk management policies dictate that user management and resource management are handled by separate autonomous groups. Users are managed by the organization's security group, in external LDAP or similar identity management databases. Each OpenStack domain is configured with a unique identity management back end, or possibly with separate realms within a single identity management back end.

For cloud service providers (such as a telco or any other cloud reseller), each paying customer can be assigned their own domain, and be integrated directly with that customer organization's identity management implementation. This allows access to all of the customer organization's personnel without creating new user accounts in OpenStack.

When using external identity back ends, users do not need to be created and stored in the internal Keystone database. However, the first time an account is used, OpenStack does have to generate a unique GUID for it before it can be assigned a default role and project to allow it to work. Therefore, user recognition and role information is stored in the Identity service database, even though the actual user account exists only in the back end.

Domain operators are responsible for ensuring that cloud users have access to the applications they develop, manage, and deploy. They assign users appropriate roles in the projects that contain those specific applications. To do so, domain operators must understand the three types of roles, the scope of assigned roles, the distinction of the default:admin:admin user, and behavioral characteristics of inherited roles. Domain operators know they can share users with other domain operators (assign users from another domain to projects in this domain), but cannot similarly share resources. Domain operators regularly delegate project management privileges to project owners or senior cloud users, allowing them, for example, to create their own subprojects, and assign subproject users and quotas.

In all software, system users can be either real people or accounts configured for automated application access. OpenStack end users are those that use the self-service interface to create and consume instances, volumes, networks, and images, and perform other tasks at the project user level. The service accounts in the service project are also normal user accounts, but are only used by the services themselves for some specific interservice authentication. Users can access the resources belonging to the project to which they are assigned. OpenStack users have a limited set of privileges defined by the roles assigned to the user.

Authentication is the process of confirming the user's identity. Typically, a user name and password is initially needed to log in to the authentication interface. The Red Hat OpenStack Platform identity service supports multiple methods of authentication, including user name and password, LDAP, and other external authentication methods. Upon successful authentication, users are provided with an authorization token to access OpenStack services.

[user@demo ~(admin)]$ openstack group create --domain demo-org demo-group

When you successfully authenticate to the Identity service, you are given a token that proves your identity, and includes your authorization, as a role, within a specific scope. The scope of a token limits where the token can be used, and cannot be changed. There are several scopes possible:

OpenStack provides three default roles: admin, member, and reader:

The admin role implies that a user also has member permissions, and the member role implies that a user also has reader permissions.

Use the openstack role assignment list command to view all current role assignments.

[user@demo ~(admin)]$ openstack role assignment list \
> --names -f json
...output omitted...
  {
    "Role": "admin",
    "User": "",
    "Group": "finance-admins@Example",
    "Project": "finance@Example",
    "Domain": "",
    "System": "",
    "Inherited": false
  },
...output omitted...

The output above shows that the finance-admins group from the Example domain has been assigned the admin role for the finance project. The default output displays UIDs, which are usually not helpful, so use the --names option to display the names of the objects instead.

Use the openstack role add command to assign a role to a user.

This example assigns the admin role at the system scope to the demo user from the Example domain.

[user@demo ~(admin)]$ openstack role add \
> --user-domain Example --user demo --system all admin

This example assigns the member role in the consulting project to the demo user from the CorpAD domain.

[user@demo ~(admin)]$ openstack role add \
> --user-domain CorpAD --user demo --project consulting member

When projects are arranged hierarchically, that is, projects are nested inside other projects, you can assign a role to the parent project and have it also apply to the child projects. Use the --inherited option to have a role assignment apply to nested projects.

[user@demo ~(admin)]$ openstack role add \
> --user-domain Corp --user demo --project umbrella --inherited  member

The following diagram illustrates the relationship between users and roles, and how they are applied to projects. Note that the arrows indicate one-to-many or many-to-many relationships.

Figure 2.2: User and role relationship to projects

Using the openstack token issue command, a user is issued an authorization token by the Identity service after validating the user's authentication parameters. The authorization token is valid for a limited period as defined in the expires field. With the authorized token, the user can request service tasks, such as creating and managing instances, volumes, networks, images, and other tasks. An application can use an authorization token to perform service tasks using the service REST APIs. Compromised tokens can be revoked. To revoke a token before it expires, use the openstack token revoke command.

[user@demo ~(admin)]$ openstack token issue
+------------+----------------------------------+
| Field      | Value                            |
+------------+----------------------------------+
| expires    | 2018-05-31T12:10:15+0000         |
| id         | 90a3349d3e81413e2be1f3745b54     |
| project_id | 5745b52a6c45440ea693ce075c8ee757 |
| user_id    | f95d249a757f47879503c51a305f9534 |
+------------+----------------------------------+

Use the generated token to retrieve information about the project on which the authorized user has a role assigned. The following example shows the curl command using the OpenStack identity API and the token ID to list all projects to which the user has a role assigned. The final pipe uses python to format the JSON output.

[user@demo ~(admin)]$ curl -s \
> -H "X-Auth-Token: 90a3349d3e81413e2be1f3745b54" \
> http://172.25.250.50:5000/v3/projects | python -m json.tool
{
...output omitted...
    "projects": [
        {
            "description": "Demo Project",
            "domain_id": "897a31bedfcc449ebb10f6e2c3568513",
            "enabled": true,
            "id": "52dfb66385344f14b7ed3e837163a484",
            "is_domain": false,
            "links": {
                "self": "http://172.25.250.50:5000/v3/projects/52df...a484"
            },
            "name": "demoproject",
            "parent_id": "897a31bedfcc449ebb10f6e2c3568513",
            "tags": []
        }
...output omitted...
    ],
}

Red Hat OpenStack Platform provides a default user named admin with the system-scope admin role who can create new domains. If a domain is not mapped to an external identity store, then a user with the domain-scope admin role can create or edit users in that domain, and add or remove them from projects or groups in the current domain. These user accounts are stored in the Identity service database. The Dashboard has multiple domain support disabled by default and uses a single domain called default. A user can be a member of multiple groups in a single domain, and can be assigned roles in projects in any domain.

[user@demo ~(admin)]$ openstack user create --project demoproject \
> --password-prompt demouser
User Password: password
Repeat User Password: password
+---------------------+----------------------------------+
| Field               | Value                            |
+---------------------+----------------------------------+
| default_project_id  | 52dfb66385344f14b7ed3e837163a484 |
| domain_id           | default                          |
| enabled             | True                             |
| id                  | 3a1ab09c9d384f3a99b9aa4bf4dd59b9 |
| name                | demouser                         |
| options             | {}                               |
| password_expires_at | None                             |
+---------------------+----------------------------------+

[user@demo ~(admin)]$ openstack user create --project demo-project \
> --password-prompt --or-show demouser
User Password: password
Repeat User Password: password
+---------------------+----------------------------------+
| Field               | Value                            |
+---------------------+----------------------------------+
| default_project_id  | 52dfb66385344f14b7ed3e837163a484 |
| domain_id           | default                          |
| enabled             | True                             |
| id                  | 3a1ab09c9d384f3a99b9aa4bf4dd59b9 |
| name                | demouser                         |
| options             | {}                               |
| password_expires_at | None                             |
+---------------------+----------------------------------+

[user@demo ~(admin)]$ openstack user set --disable demouser

[user@demo ~(admin)]$ openstack user set --enable demouser

Adding a User to a Project

You can add users and groups to a project while it is being created or later, using the Dashboard or the OpenStack CLI.

In the OpenStack CLI, use the openstack user set --project command to change the primary project of a user. To add a user to an additional project, use the openstack role add command. Use this command to assign the member role for the user in a project. The following shows a user named demouser being assigned the member role in the demoproject project.

[user@demo ~(admin)]$ openstack role add \
> --project demoproject --user demouser member

Roles are explained in more detail in the following section.

To add a user to a project from the Dashboard, click Identity → Projects and then select the Manage Members action for the relevant project.

Figure 2.3: Adding users to a project from the Dashboard