Cloud Admin Actions with the Command Line | User Guide

documentation.suse.com › Documentation › User Guide › Cloud Admin User Guide › Cloud Admin Actions with the Command Line

Applies to HPE Helion OpenStack 8

4 Cloud Admin Actions with the Command Line

4.1 Creating Additional Cloud Admins
4.2 Command Line Examples
4.3 Assigning the default service admin roles
4.4 Customize policy.json on the Cloud Lifecycle Manager
4.5 Roles

Cloud admins can use the command line tools to perform domain admin tasks such as user and project administration.

4.1 Creating Additional Cloud Admins #

You can create additional Cloud Admins to help with the administration of your cloud.

Keystone identity service query and administration tasks can be performed using the OpenStack command line utility. The utility is installed by the Cloud Lifecycle Manager onto the Cloud Lifecycle Manager.

Note

Keystone administration tasks should be performed by an admin user with a token scoped to the default domain via the Keystone v3 identity API. These settings are preconfigured in the file ~/keystone.osrc. By default, keystone.osrc is configured with the admin endpoint of Keystone. If the admin endpoint is not accessible from your network, change OS_AUTH_URL to point to the public endpoint.

4.2 Command Line Examples #

For a full list of OpenStackClient commands, see OpenStackClient Command List.

Sourcing the Keystone Administration Credentials

You can set the environment variables needed for identity administration by sourcing the keystone.osrc file created by the lifecycle manager:

source ~/keystone.osrc

List users in the default domain

These users are created by the Cloud Lifecycle Manager in the MySQL back end:

openstack user list

Example output:

$ openstack user list
+----------------------------------+------------------+
| ID                               | Name             |
+----------------------------------+------------------+
| 155b68eda9634725a1d32c5025b91919 | heat             |
| 303375d5e44d48f298685db7e6a4efce | octavia          |
| 40099e245a394e7f8bb2aa91243168ee | logging          |
| 452596adbf4d49a28cb3768d20a56e38 | admin            |
| 76971c3ad2274820ad5347d46d7560ec | designate        |
| 7b2dc0b5bb8e4ffb92fc338f3fa02bf3 | hlm_backup       |
| 86d345c960e34c9189519548fe13a594 | barbican         |
| 8e7027ab438c4920b5853d52f1e08a22 | nova_monasca     |
| 9c57dfff57e2400190ab04955e7d82a0 | barbican_service |
| a3f99bcc71b242a1bf79dbc9024eec77 | nova             |
| aeeb56fc4c4f40e0a6a938761f7b154a | glance-check     |
| af1ef292a8bb46d9a1167db4da48ac65 | cinder           |
| af3000158c6d4d3d9257462c9cc68dda | demo             |
| b41a7d0cb1264d949614dc66f6449870 | swift            |
| b78a2b17336b43368fb15fea5ed089e9 | cinderinternal   |
| bae1718dee2d47e6a75cd6196fb940bd | monasca          |
| d4b9b32f660943668c9f5963f1ff43f9 | ceilometer       |
| d7bef811fb7e4d8282f19fb3ee5089e9 | swift-monitor    |
| df58b381ca8a4c9bb42e371f2a78ef4f | freezer          |
| e22bbb2be91342fd9afa20baad4cd490 | neutron          |
| ec0ad2418a644e6b995d8af3eb5ff195 | glance           |
| ef16c37ec7a648338eaf53c029d6e904 | swift-dispersion |
| ef1a6daccb6f4694a27a1c41cc5e7a31 | glance-swift     |
| fed3a599b0864f5b80420c9e387b4901 | monasca-agent    |
+----------------------------------+------------------+

List domains created by the installation process:

openstack domain list

Example output:

$ openstack domain list
+----------------------------------+---------+---------+----------------------------------------------------------------------+
| ID                               | Name    | Enabled | Description                                                          |
+----------------------------------+---------+---------+----------------------------------------------------------------------+
| 6740dbf7465a4108a36d6476fc967dbd | heat    | True    | Owns users and projects created by heat                              |
| default                          | Default | True    | Owns users and tenants (i.e. projects) available on Identity API v2. |
+----------------------------------+---------+---------+----------------------------------------------------------------------+

List the roles:

openstack role list

Example output:

$ openstack role list
+----------------------------------+---------------------------+
| ID                               | Name                      |
+----------------------------------+---------------------------+
| 0be3da26cd3f4cd38d490b4f1a8b0c03 | designate_admin           |
| 13ce16e4e714473285824df8188ee7c0 | monasca-agent             |
| 160f25204add485890bc95a6065b9954 | key-manager:service-admin |
| 27755430b38c411c9ef07f1b78b5ebd7 | monitor                   |
| 2b8eb0a261344fbb8b6b3d5934745fe1 | key-manager:observer      |
| 345f1ec5ab3b4206a7bffdeb5318bd32 | admin                     |
| 49ba3b42696841cea5da8398d0a5d68e | nova_admin                |
| 5129400d4f934d4fbfc2c3dd608b41d9 | ResellerAdmin             |
| 60bc2c44f8c7460a9786232a444b56a5 | neutron_admin             |
| 654bf409c3c94aab8f929e9e82048612 | cinder_admin              |
| 854e542baa144240bfc761cdb5fe0c07 | monitoring-delegate       |
| 8946dbdfa3d346b2aa36fa5941b43643 | key-manager:auditor       |
| 901453d9a4934610ad0d56434d9276b4 | key-manager:admin         |
| 9bc90d1121544e60a39adbfe624a46bc | monasca-user              |
| 9fe2a84a3e7443ae868d1009d6ab4521 | service                   |
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_                  |
| a24d4e0a5de14bffbe166bfd68b36e6a | swiftoperator             |
| ae088fcbf579425580ee4593bfa680e5 | heat_stack_user           |
| bfba56b2562942e5a2e09b7ed939f01b | KeystoneAdmin             |
| c05f54cf4bb34c7cb3a4b2b46c2a448b | glance_admin              |
| cd61735400ca4fa19e80cebe9970d9a7 | Member                    |
| fe010be5c57240db8f559e0114a380c1 | key-manager:creator       |
+----------------------------------+---------------------------+

List admin user role assignment within default domain:

openstack role assignment list --user admin --domain default

Example output:

# This indicates that the admin user is assigned the admin role within the default domain
ardana >  openstack role assignment list --user admin --domain default
+----------------------------------+----------------------------------+-------+---------+---------+
| Role                             | User                             | Group | Project | Domain  |
+----------------------------------+----------------------------------+-------+---------+---------+
| b398322103504546a070d607d02618ad | fed1c038d9e64392890b6b44c38f5bbb |       |         | default |
+----------------------------------+----------------------------------+-------+---------+---------+

Create a new user in default domain:

openstack user create --domain default --password-prompt --email <email_address> --description <description> --enable <username>

Example output showing the creation of a user named testuser with email address test@example.com and a description of Test User:

ardana >  openstack user create --domain default --password-prompt --email test@example.com --description "Test User" --enable testuser
User Password:
Repeat User Password:
+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description | Test User                        |
| domain_id   | default                          |
| email       | test@example.com                 |
| enabled     | True                             |
| id          | 8aad69acacf0457e9690abf8c557754b |
| name        | testuser                         |
+-------------+----------------------------------+

Assign admin role for testuser within the default domain:

openstack role add admin --user <username> --domain default
openstack role assignment list --user <username> --domain default

Example output:

# Just for demonstration purposes - do not do this in a production environment!
ardana >  openstack role add admin --user testuser --domain default
ardana >  openstack role assignment list --user testuser --domain default
+----------------------------------+----------------------------------+-------+---------+---------+
| Role                             | User                             | Group | Project | Domain  |
+----------------------------------+----------------------------------+-------+---------+---------+
| b398322103504546a070d607d02618ad | 8aad69acacf0457e9690abf8c557754b |       |         | default |
+----------------------------------+----------------------------------+-------+---------+---------+

4.3 Assigning the default service admin roles #

The following examples illustrate how you can assign each of the new service admin roles to a user.

Assigning the glance_admin role

A user must have the role of admin in order to assign the glance_admin role. To assign the role, you will set the environment variables needed for the identity service administrator.

First, source the identity service credentials:
```
source ~/keystone.osrc
```
You can add the glance_admin role to a user on a project with this command:
```
openstack role add --user <username> --project <project_name> glance_admin
```
Example, showing a user named testuser being granted the glance_admin role in the test_project project:
```
openstack role add --user testuser --project test_project glance_admin
```

You can confirm the role assignment by listing out the roles:

openstack role assignment list --user <username>

Example output:

ardana >  openstack role assignment list --user testuser
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
| Role                             | User                             | Group | Project                          | Domain | Inherited |
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
| 46ba80078bc64853b051c964db918816 | 8bcfe10101964e0c8ebc4de391f3e345 |       | 0ebbf7640d7948d2a17ac08bbbf0ca5b |        | False     |
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+

Note that only the role ID is displayed. To get the role name, execute the following:

openstack role show <role_id>

Example output:

ardana >  openstack role show 46ba80078bc64853b051c964db918816
+-------+----------------------------------+
| Field | Value                            |
+-------+----------------------------------+
| id    | 46ba80078bc64853b051c964db918816 |
| name  | glance_admin                     |
+-------+----------------------------------+

To demonstrate that the user has Glance admin privileges, authenticate with those user creds and then upload and publish an image. Only a user with an admin role or glance_admin can publish an image.

The easiest way to do this will be to make a copy of the service.osrc file and edit it with your user credentials. You can do that with this command:
```
cp ~/service.osrc ~/user.osrc
```
Using your preferred editor, edit the user.osrc file and replace the values for the following entries to match your user credentials:
```
export OS_USERNAME=<username>
export OS_PASSWORD=<password>
```

You will also need to edit the following lines for your environment:

## Change these values from 'unset' to 'export'
export OS_PROJECT_NAME=<project_name>
export OS_PROJECT_DOMAIN_NAME=Default

Here is an example output:

unset OS_DOMAIN_NAME
export OS_IDENTITY_API_VERSION=3
export OS_AUTH_VERSION=3
export OS_PROJECT_NAME=test_project
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USERNAME=testuser
export OS_USER_DOMAIN_NAME=Default
export OS_PASSWORD=testuser
export OS_AUTH_URL=http://192.168.245.9:35357/v3
export OS_ENDPOINT_TYPE=internalURL
# OpenstackClient uses OS_INTERFACE instead of OS_ENDPOINT
export OS_INTERFACE=internal
export OS_CACERT=/etc/ssl/certs/ca-certificates.crt

Source the environment variables for your user:
```
source ~/user.osrc
```

Upload an image and publicize it:

glance image-create --name "upload me" --visibility public --container-format bare --disk-format qcow2 --file uploadme.txt

Example output:

+------------------+--------------------------------------+
| Property         | Value                                |
+------------------+--------------------------------------+
| checksum         | dd75c3b840a16570088ef12f6415dd15     |
| container_format | bare                                 |
| created_at       | 2016-01-06T23:31:27Z                 |
| disk_format      | qcow2                                |
| id               | cf1490f4-1eb1-477c-92e8-15ebbe91da03 |
| min_disk         | 0                                    |
| min_ram          | 0                                    |
| name             | upload me                            |
| owner            | bd24897932074780a20b780c4dde34c7     |
| protected        | False                                |
| size             | 10                                   |
| status           | active                               |
| tags             | []                                   |
| updated_at       | 2016-01-06T23:31:31Z                 |
| virtual_size     | None                                 |
| visibility       | public                               |
+------------------+--------------------------------------+

Note

You can use the command glance help image-create to get the full syntax for this command.

Assigning the nova_admin role

A user must have the role of admin in order to assign the nova_admin role. To assign the role, you will set the environment variables needed for the identity service administrator.

First, source the identity service credentials:
```
source ~/keystone.osrc
```
You can add the glance_admin role to a user on a project with this command:
```
openstack role add --user <username> --project <project_name> nova_admin
```
Example, showing a user named testuser being granted the glance_admin role in the test_project project:
```
openstack role add --user testuser --project test_project nova_admin
```

You can confirm the role assignment by listing out the roles:

openstack role assignment list --user <username>

Example output:

ardana >  openstack role assignment list --user testuser
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
| Role                             | User                             | Group | Project                          | Domain | Inherited |
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
| 8cdb02bab38347f3b65753099f3ab73c | 8bcfe10101964e0c8ebc4de391f3e345 |       | 0ebbf7640d7948d2a17ac08bbbf0ca5b |        | False     |
+----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+

Note that only the role ID is displayed. To get the role name, execute the following:

openstack role show <role_id>

Example output:

ardana >  openstack role show 8cdb02bab38347f3b65753099f3ab73c
+-------+----------------------------------+
| Field | Value                            |
+-------+----------------------------------+
| id    | 8cdb02bab38347f3b65753099f3ab73c |
| name  | nova_admin                       |
+-------+----------------------------------+

To demonstrate that the user has Nova admin privileges, authenticate with those user creds and then upload and publish an image. Only a user with an admin role or glance_admin can publish an image.

The easiest way to do this will be to make a copy of the service.osrc file and edit it with your user credentials. You can do that with this command:
```
cp ~/service.osrc ~/user.osrc
```
Using your preferred editor, edit the user.osrc file and replace the values for the following entries to match your user credentials:
```
export OS_USERNAME=<username>
export OS_PASSWORD=<password>
```

You will also need to edit the following lines for your environment:

## Change these values from 'unset' to 'export'
export OS_PROJECT_NAME=<project_name>
export OS_PROJECT_DOMAIN_NAME=Default

Here is an example output:

unset OS_DOMAIN_NAME
export OS_IDENTITY_API_VERSION=3
export OS_AUTH_VERSION=3
export OS_PROJECT_NAME=test_project
export OS_PROJECT_DOMAIN_NAME=Default
export OS_USERNAME=testuser
export OS_USER_DOMAIN_NAME=Default
export OS_PASSWORD=testuser
export OS_AUTH_URL=http://192.168.245.9:35357/v3
export OS_ENDPOINT_TYPE=internalURL
# OpenstackClient uses OS_INTERFACE instead of OS_ENDPOINT
export OS_INTERFACE=internal
export OS_CACERT=/etc/ssl/certs/ca-certificates.crt

Source the environment variables for your user:
```
source ~/user.osrc
```

List all of the virtual machines in the project specified in user.osrc:

openstack server list

Example output showing no virtual machines, because there are no virtual machines created on the project specified in the user.osrc file:

+--------------------------------------+-------------------------------------------------------+--------+-----------------------------------------------------------------+
| ID                                   | Name                                                  | Status | Networks                                                        |
+--------------------------------------+-------------------------------------------------------+--------+-----------------------------------------------------------------+
+--------------------------------------+-------------------------------------------------------+--------+-----------------------------------------------------------------+

For this demonstration, we do have a virtual machine associated with a different project and because your user has nova_admin permissions, you can view those virtual machines using a slightly different command:

openstack server list --all-projects

Example output, now showing a virtual machine:

ardana >  openstack server list --all-projects
+--------------------------------------+-------------------------------------------------------+--------+-----------------------------------------------------------------+
| ID                                   | Name                                                  | Status | Networks                                                        |
+--------------------------------------+-------------------------------------------------------+--------+-----------------------------------------------------------------+
| da4f46e2-4432-411b-82f7-71ab546f91f3 | testvml                                               | ACTIVE |                                                                 |
+--------------------------------------+-------------------------------------------------------+--------+-----------------------------------------------------------------+

You can also now delete virtual machines in other projects by using the --all-tenants switch:
```
openstack server delete --all-projects <instance_id>
```
Example, showing us deleting the instance in the previous step:
```
openstack server delete --all-projects da4f46e2-4432-411b-82f7-71ab546f91f3
```
You can get a full list of available commands by using this:
```
openstack -h
```

You can perform the same steps as above for the Neutron and Cinder service admin roles:

neutron_admin
cinder_admin

4.4 Customize policy.json on the Cloud Lifecycle Manager #

One way to deploy policy.json for a service is by going to each of the target nodes and making changes there. This is not necessary anymore. This process has been streamlined and policy.json files can be edited on the Cloud Lifecycle Manager and then deployed to nodes. Please exercise caution when modifying policy.json files. It is best to validate the changes in a non-production environment before rolling out policy.json changes into production. It is not recommended that you make policy.json changes without a way to validate the desired policy behavior. Updated policy.json files can be deployed using the appropriate <service_name>-reconfigure.yml playbook.

4.5 Roles #

Service roles represent the functionality used to implement the OpenStack role based access control (RBAC) model. This is used to manage access to each OpenStack service. Roles are named and assigned per user or group for each project by the identity service. Role definition and policy enforcement are defined outside of the identity service independently by each OpenStack service.

The token generated by the identity service for each user authentication contains the role(s) assigned to that user for a particular project. When a user attempts to access a specific OpenStack service, the role is parsed by the service, compared to the service-specific policy file, and then granted the resource access defined for that role by the service policy file.

Each service has its own service policy file with the /etc/[SERVICE_CODENAME]/policy.json file name format where [SERVICE_CODENAME] represents a specific OpenStack service name. For example, the OpenStack Nova service would have a policy file called /etc/nova/policy.json.

Service policy files can be modified and deployed to control nodes from the Cloud Lifecycle Manager. Administrators are advised to validate policy changes before checking in the changes to the site branch of the local git repository before rolling the changes into production. Do not make changes to policy files without having a way to validate them.

The policy files are located at the following site branch directory on the Cloud Lifecycle Manager.

~/openstack/ardana/ansible/roles/

For test and validation, policy files can be modified in a non-production environment from the ~/scratch/ directory. For a specific policy file, run a search for policy.json. To deploy policy changes for a service, run the service specific reconfiguration playbook (for example, nova-reconfigure.yml). For a complete list of reconfiguration playbooks, change directories to ~/scratch/ansible/next/ardana/ansible and run this command:

ls –l | grep reconfigure

Note

Comments added to any *.j2 files (including templates) must follow proper comment syntax. Otherwise you may see errors when running the config-processor or any of the service playbooks.

Print this page