Manage projects, users, and roles

Services
Manage project security

As a cloud administrator, you manage projects, users, and roles. 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 assign roles to user-project pairs.

You can define actions for OpenStack service roles in the /etc/PROJECT/policy.json files. For example, define actions for Compute service roles in the /etc/nova/policy.json file.

You can manage projects, users, and roles independently from each other.

During cloud set up, the operator defines at least one project, user, and role.

Learn how to add, update, and delete projects and users, assign users to one or more projects, and change or remove the assignment. To enable or temporarily disable a project or user, you update that project or user. You can also change quotas at the project level.

Before you can delete a user account, you must remove the user account from its primary project.

Before you can run keystone client commands, you must download and source an OpenStack RC file. See Download and source the OpenStack RC file.

Services

service-create
service-list
service-get
service-delete
Create a tenant (project)
Update a project
Delete a project
Create a user
Update a user
Delete a user
Create and assign a role

To look at your service catalog, use these keystone client commands.

`service-create`

Keyword arguments:

Name
Type
Description

Example:

$ keystone service create \
--name=nova \
--type=compute \
--description="Nova Compute Service"

`service-list`

Arguments

service_id

Example:

$ keystone service-list

`service-get`

Arguments

service_id

Example:

$ keystone service-get 08741d8ed88242ca88d1f61484a0fe3b

`service-delete`

Arguments

service_id

Example:

$ keystone service-delete 08741d8ed88242ca88d1f61484a0fe3b

Create a tenant (project)

A tenant is a group of zero or more users. In nova, a tenant owns virtual machines. In swift, a tenant owns containers. In the Dashboard, tenants are represented as projects. Users can be associated with more than one tenant. Each tenant and user pairing can have a role associated with it.

To list all projects with their ID, name, and whether they are enabled or disabled:

$ keystone tenant-list

+----------------------------------+--------------------+---------+
|                id                |        name        | enabled |
+----------------------------------+--------------------+---------+
| f7ac731cc11f40efbc03a9f9e1d1d21f |       admin        |   True  |
| c150ab41f0d9443f8874e32e725a4cc8 |      alt_demo      |   True  |
| a9debfe41a6d4d09a677da737b907d5e |        demo        |   True  |
| 9208739195a34c628c58c95d157917d7 | invisible_to_admin |   True  |
| 3943a53dc92a49b2827fae94363851e1 |      service       |   True  |
| 80cab5e1f02045abad92a2864cfd76cb |    test_project    |   True  |
+----------------------------------+--------------------+---------+

Create a project named new-project:

$ keystone tenant-create --name new-project --description 'my new project'

By default, the project is enabled.

+-------------+----------------------------------+
|   Property  |              Value               |
+-------------+----------------------------------+
| description |          my new project          |
|   enabled   |               True               |
|      id     | 1a4a0618b306462c9830f876b0bd6af2 |
|     name    |           new-project            |
+-------------+----------------------------------+

Note the ID for the project so you can update it in the next procedure.

Update a project

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

To temporarily disable a project:

$ keystone tenant-update PROJECT_ID --enabled false

To enable a disabled project:

$ keystone tenant-update PROJECT_ID --enabled true

To update the name of a project:

$ keystone tenant-update PROJECT_ID --name project-new

To verify your changes, show information for the updated project:

$ keystone tenant-get PROJECT_ID

+-------------+----------------------------------+
|   Property  |              Value               |
+-------------+----------------------------------+
| description |          my new project          |
|   enabled   |               True               |
|      id     | 1a4a0618b306462c9830f876b0bd6af2 |
|     name    |           project-new            |
+-------------+----------------------------------+

Delete a project

To delete a project:
```
$ keystone tenant-delete PROJECT_ID
```

Create a user

To list all users:

$ keystone user-list

The output shows the ID, name, enabled status, and e-mail address for each user:

+----------------------------------+----------+---------+----------------------+
|                id                |   name   | enabled |        email         |
+----------------------------------+----------+---------+----------------------+
| 352b37f5c89144d4ad0534139266d51f |  admin   |   True  |  [email protected]   |
| 86c0de739bcb4802b8dc786921355813 |   demo   |   True  |   [email protected]   |
| 32ec34aae8ea432e8af560a1cec0e881 |  glance  |   True  |  [email protected]  |
| 7047fcb7908e420cb36e13bbd72c972c |   nova   |   True  |   [email protected]   |
+----------------------------------+----------+---------+----------------------+

To create a user, you must specify a name. Optionally, you can specify a tenant ID, password, and email address. It is recommended that you include the tenant ID and password because the user cannot log in to the dashboard without this information.

To create the new-user user:

$ keystone user-create --name new-user --tenant_id 1a4a0618b306462c9830f876b0bd6af2 --pass PASSWORD

+----------+----------------------------------+
| Property |              Value               |
+----------+----------------------------------+
|  email   |                                  |
| enabled  |               True               |
|    id    | 6e5140962b424cb9814fb172889d3be2 |
|   name   |             new-user             |
| tenantId | 1a4a0618b306462c9830f876b0bd6af2 |
+----------+----------------------------------+

Update a user

You can update the name, email address, and enabled status for a user.

To temporarily disable a user account:
```
$ keystone user-update USER_ID --enabled false
```
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.

To enable a disabled user account:

$ keystone user-update USER_ID --enabled true

To change the name and description for a user account:

$ keystone user-update USER_ID --name user-new --email [email protected]

User has been updated.

Delete a user

To delete a specified user account:
```
$ keystone user-delete USER_ID
```

Create and assign a role

Users can be members of multiple projects. To assign users to multiple projects, define a role and assign that role to a user-project pair.

To list the available roles:

$ keystone role-list

+----------------------------------+---------------+
|                id                |      name     |
+----------------------------------+---------------+
| 71ccc37d41c8491c975ae72676db687f |     Member    |
| 149f50a1fe684bfa88dae76a48d26ef7 | ResellerAdmin |
| 9fe2ff9ee4384b1894a90878d3e92bab |    _member_   |
| 6ecf391421604da985db2f141e46a7c8 |     admin     |
| deb4fffd123c4d02a907c2c74559dccf |  anotherrole  |
+----------------------------------+---------------+

To create the new-role role:

$ keystone role-create --name new-role

+----------+----------------------------------+
| Property |              Value               |
+----------+----------------------------------+
|    id    | bef1f95537914b1295da6aa038ef4de6 |
|   name   |             new-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.

To list users:

$ keystone user-list

+----------------------------------+----------+---------+----------------------+
|                id                |   name   | enabled |        email         |
+----------------------------------+----------+---------+----------------------+
| 352b37f5c89144d4ad0534139266d51f |  admin   |   True  |  [email protected]   |
| 981422ec906d4842b2fc2a8658a5b534 | alt_demo |   True  | [email protected] |
| 036e22a764ae497992f5fb8e9fd79896 |  cinder  |   True  |  [email protected]  |
| 86c0de739bcb4802b8dc786921355813 |   demo   |   True  |   [email protected]   |
| 32ec34aae8ea432e8af560a1cec0e881 |  glance  |   True  |  [email protected]  |
| 7047fcb7908e420cb36e13bbd72c972c |   nova   |   True  |   [email protected]   |
+----------------------------------+----------+---------+----------------------+

Note the ID of the user to which you want to assign the role.

To list role IDs:

$ keystone role-list

+----------------------------------+---------------+
|                id                |      name     |
+----------------------------------+---------------+
| 71ccc37d41c8491c975ae72676db687f |     Member    |
| 149f50a1fe684bfa88dae76a48d26ef7 | ResellerAdmin |
| 9fe2ff9ee4384b1894a90878d3e92bab |    _member_   |
| 6ecf391421604da985db2f141e46a7c8 |     admin     |
| deb4fffd123c4d02a907c2c74559dccf |  anotherrole  |
| bef1f95537914b1295da6aa038ef4de6 |    new-role   |
+----------------------------------+---------------+

Note the ID of the role that you want to assign.

To list projects:

$ keystone tenant-list

+----------------------------------+--------------------+---------+
|                id                |        name        | enabled |
+----------------------------------+--------------------+---------+
| f7ac731cc11f40efbc03a9f9e1d1d21f |       admin        |   True  |
| c150ab41f0d9443f8874e32e725a4cc8 |      alt_demo      |   True  |
| a9debfe41a6d4d09a677da737b907d5e |        demo        |   True  |
| 9208739195a34c628c58c95d157917d7 | invisible_to_admin |   True  |
| caa9b4ce7d5c4225aa25d6ff8b35c31f |      new-user      |   True  |
| 1a4a0618b306462c9830f876b0bd6af2 |    project-new     |   True  |
| 3943a53dc92a49b2827fae94363851e1 |      service       |   True  |
| 80cab5e1f02045abad92a2864cfd76cb |    test_project    |   True  |
+----------------------------------+--------------------+---------+

Note the ID of the project to which you want to assign the role.

Assign a role to a user-project pair. In this example, you assign the new-role role to the demo and test-project pair:
```
$ keystone user-role-add --user USER_ID --role ROLE_ID --tenant TENANT_ID
```

To verify the role assignment:

$ keystone user-role-list --user USER_ID --tenant TENANT_ID

+----------------------------------+----------+----------------------------------+----------------------------------+
|                id                |   name   |             user_id              |            tenant_id             |
+----------------------------------+----------+----------------------------------+----------------------------------+
| bef1f95537914b1295da6aa038ef4de6 | new-role | 86c0de739bcb4802b8dc786921355813 | 80cab5e1f02045abad92a2864cfd76cb |
+----------------------------------+----------+----------------------------------+----------------------------------+

To get details for a specified role:

$ keystone role-get ROLE_ID

+----------+----------------------------------+
| Property |              Value               |
+----------+----------------------------------+
|    id    | bef1f95537914b1295da6aa038ef4de6 |
|   name   |             new-role             |
+----------+----------------------------------+

To remove a role from a user-project pair:

$ keystone user-role-remove --user USER_ID --role ROLE_ID --tenant TENANT_ID

To verify the role removal, run the following command:
```
$ keystone user-role-list --user USER_ID --tenant TENANT_ID
```
If the role was removed, the command output omits the removed role.

Manage project security

Security groups are sets of IP filter rules that are applied to all project instances, which define networking access to the instance. Group rules are project specific; project members can edit the default rules for their group and add new rule sets.

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

	Note
	For information about updating rules using the dashboard, see the section called “Manage project security”.

You can use the allow_same_net_traffic option in the /etc/nova/nova.conf file to globally control whether the rules apply to hosts which share a network.

If set to:

True (default), hosts on the same subnet are not filtered and are allowed to pass all types of traffic between them. On a flat network, this allows all instances from all projects unfiltered communication. With VLAN networking, this allows access between instances within the same project. You can also simulate this setting by configuring the default security group to allow all traffic from the subnet.
False, security groups are enforced for all connections.

Additionally, the number of maximum rules per security group is controlled by the security_group_rules and the number of allowed security groups per project is controlled by the security_groups quota (see the section called “Manage quotas”).

List and view current security groups

From the command line you can get a list of security groups for the project, using the nova command:

Ensure your system variables are set for the user and tenant for which you are checking security group rules for. For example:
```
export OS_USERNAME=demo00
export OS_TENANT_NAME=tenant01
```

Output security groups, as follows:

$ nova secgroup-list
+---------+-------------+
| Name    | Description |
+---------+-------------+
| default | default     |
| open    | all ports   |
+---------+-------------+

View the details of a group, as follows:

$ nova secgroup-list-rules groupName

For example:

$ nova secgroup-list-rules open
+-------------+-----------+---------+-----------+--------------+
 | IP Protocol | From Port | To Port | IP Range  | Source Group |
 +-------------+-----------+---------+-----------+--------------+
 | icmp        | -1        | 255     | 0.0.0.0/0 |              |
 | tcp         | 1         | 65535   | 0.0.0.0/0 |              |
 | udp         | 1         | 65535   | 0.0.0.0/0 |              |
 +-------------+-----------+---------+-----------+--------------+

These rules are allow type rules as the default is deny. The first column is the IP protocol (one of icmp, tcp, or udp). The second and third columns specify the affected port range. The third column specifies the IP range in CIDR format. This example shows the full port range for all protocols allowed from all IPs.

Create a security group

When adding a new security group, you should pick a descriptive but brief name. This name shows up in brief descriptions of the instances that use it where the longer description field often does not. For example, seeing that an instance is using security group "http" is much easier to understand than "bobs_group" or "secgrp1".

Ensure your system variables are set for the user and tenant for which you are checking security group rules for.

Add the new security group, as follows:

$ nova secgroup-create Group Name Description

For example:

$ nova secgroup-create global_http "Allows Web traffic anywhere on the Internet."
+--------------------------------------+-------------+----------------------------------------------+
| Id                                   | Name        | Description                                  |
+--------------------------------------+-------------+----------------------------------------------+
| 1578a08c-5139-4f3e-9012-86bd9dd9f23b | global_http | Allows Web traffic anywhere on the Internet. |
+--------------------------------------+-------------+----------------------------------------------+

Add a new group rule, as follows:

$ nova secgroup-add-rule secGroupName ip-protocol from-port to-port CIDR

The arguments are positional, and the "from-port" and "to-port" arguments specify the local port range connections are allowed to access, not the source and destination ports of the connection. For example:

$ nova secgroup-add-rule global_http tcp 80 80 0.0.0.0/0
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range  | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp         | 80        | 80      | 0.0.0.0/0 |              |
+-------------+-----------+---------+-----------+--------------+

You can create complex rule sets by creating additional rules. For example, if you want to pass both http and https traffic, run:

$ nova secgroup-add-rule global_http tcp 443 443 0.0.0.0/0
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range  | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp         | 443       | 443     | 0.0.0.0/0 |              |
+-------------+-----------+---------+-----------+--------------+

Despite only outputting the newly added rule, this operation is additive (both rules are created and enforced).

View all rules for the new security group, as follows:

$ nova secgroup-list-rules global_http
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range  | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp         | 80        | 80      | 0.0.0.0/0 |              |
| tcp         | 443       | 443     | 0.0.0.0/0 |              |
+-------------+-----------+---------+-----------+--------------+

Delete a security group

Ensure your system variables are set for the user and tenant for which you are deleting a security group for.

Delete the new security group, as follows:

$ nova secgroup-delete GroupName

For example:

$ nova secgroup-delete global_http

Create security group rules for a cluster of instances

Source Groups are a special, dynamic way of defining the CIDR of allowed sources. The user specifies a Source Group (Security Group name), and all the users' other Instances using the specified Source Group are selected dynamically. This alleviates the need for individual rules to allow each new member of the cluster.

Make sure to set the system variables for the user and tenant for which you are deleting a security group for.

Add a source group, as follows:

$ nova secgroup-add-group-rule secGroupName source-group ip-protocol from-port to-port

For example:

$ nova secgroup-add-group-rule cluster global_http tcp 22 22

The cluster rule allows ssh access from any other instance that uses the global_http group.

Questions? Discuss on ask.openstack.org
Found an error? Report a bug against this page

Legal notices

Prev	Up	Next
	Home