Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
OpenStack Cloud Computing Cookbook, Third Edition

You're reading from   OpenStack Cloud Computing Cookbook, Third Edition Over 110 effective recipes to help you build and operate OpenStack cloud computing, storage, networking, and automation

Arrow left icon
Product type Paperback
Published in Aug 2015
Publisher
ISBN-13 9781782174783
Length 436 pages
Edition 1st Edition
Arrow right icon
Author (1):
Arrow left icon
Cody Bunch Cody Bunch
Author Profile Icon Cody Bunch
Cody Bunch
Arrow right icon
View More author details
Toc

Table of Contents (13) Chapters Close

Preface 1. Keystone – OpenStack Identity Service 2. Glance – OpenStack Image Service FREE CHAPTER 3. Neutron – OpenStack Networking 4. Nova – OpenStack Compute 5. Swift – OpenStack Object Storage 6. Using OpenStack Object Storage 7. Administering OpenStack Object Storage 8. Cinder – OpenStack Block Storage 9. More OpenStack 10. Using the OpenStack Dashboard 11. Production OpenStack Index

Creating the service tenant and service users

Now that the service endpoints are created, we can configure them so that our other OpenStack services can utilize them. To do this, each service is configured with a username and password within a special service tenant. Configuring each service to have its own username and password allows for greater security, troubleshooting, and auditing within our environment. When setting up a service to use the OpenStack Identity service for authentication and authorization, we specify these details in their relevant configuration file. Each service itself has to authenticate with keystone in order for it to be available within OpenStack. Configuration of that service is then done using these credentials. For example, for glance, we specify the following lines in /etc/glance/glance-registry.conf, when used with OpenStack Identity service, which matches what we created previously:

[keystone_authtoken]
identity_uri = https://192.168.100.200:35357
admin_tenant_name = service
admin_user = glance
admin_password = glance
insecure = True

Tip

The use of insecure = True here is only required as self-signed certificates are used throughout this book. In production, we would use issued certificates and omit this option in our configs.

Getting ready

We will be using the keystone client to operate Keystone. If the python-keystoneclient tool isn't available, follow the steps described at http://bit.ly/OpenStackCookbookClientInstall.

Ensure that we have our environment set correctly to access our OpenStack environment for administrative purposes:

export OS_TENANT_NAME=cookbook
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/
export OS_NO_CACHE=1
export OS_KEY=/vagrant/cakey.pem
export OS_CACERT=/vagrant/ca.pem

Tip

You can use the controller node if no other machines are available on your network, as this has the python-keystoneclient and the relevant access to the OpenStack environment. If you are using the Vagrant environment, issue the following command to get access to the Controller:

vagrant ssh controller

How to do it...

To configure an appropriate service tenant, carry out the following steps:

  1. Create the service tenant as follows:
    keystone tenant-create \
        --name service \
        --description "Service Tenant" \
        --enabled true
    

    This produces output similar to what is shown as follows:

    +-------------+----------------------------------+
    |   Property  |              Value               |
    +-------------+----------------------------------+
    | description |          Service Tenant          |
    |   enabled   |               True               |
    |      id     | 8e77d9c13e884bf4809077722003bba0 |
    |     name    |             service              |
    +-------------+----------------------------------+
    
  2. Record the ID of the service tenant so that we can assign service users to this ID:
    SERVICE_TENANT_ID=$(keystone tenant-list \
        | awk '/\ service\ / {print $2}')
    
  3. For each of the services in this section, we will create the user accounts to be named the same as the services and set the password to be the same as the service name too. For example, we will add a user called nova with a password nova in the service tenant by using the user-create option:
    keystone user-create \
        --name nova \
        --pass nova \
        --tenant_id $SERVICE_TENANT_ID \
        --email nova@localhost \
        --enabled true
    

    The preceding code will produce an output similar to what is shown here:

    +----------+----------------------------------+
    | Property |              Value               |
    +----------+----------------------------------+
    |  email   |          nova@localhost          |
    | enabled  |               True               |
    |    id    | 50ea356a4b6f4cb7a9fa22c1fb08549b |
    |   name   |               nova               |
    | tenantId | 42e5c284de244e3190e12cc44fbbbe62 |
    | username |               nova               |
    +----------+----------------------------------+
    
  4. We then repeat this for each of our other services that will use OpenStack Identity service:
    keystone user-create \
        --name glance \
        --pass glance \
        --tenant_id $SERVICE_TENANT_ID \
        --email glance@localhost \
        --enabled true
    
    keystone user-create \
        --name keystone \
        --pass keystone \
        --tenant_id $SERVICE_TENANT_ID \
        --email keystone@localhost \
        --enabled true
    
    keystone user-create \
        --name neutron \
        --pass neutron \
        --tenant_id $SERVICE_TENANT_ID \
        --email neutron@localhost \
        --enabled true
    
    keystone user-create \
        --name cinder \
        --pass cinder \
        --tenant_id $SERVICE_TENANT_ID \
        --email cinder@localhost \
        --enabled true
    
  5. We can now assign these users the admin role in the service tenant. To do this, we use the user-role-add option after retrieving the user ID of the nova user. For example, to add the admin role to the nova user in the service tenant, we use the following code:
    # Get the nova user id
    NOVA_USER_ID=$(keystone user-list \
        | awk '/\ nova\ / {print $2}')
    
    # Get the admin role id
    ADMIN_ROLE_ID=$(keystone role-list \
        | awk '/\ admin\ / {print $2}')
    
    # Assign the nova user the admin role in service tenant
    keystone user-role-add \
        --user $NOVA_USER_ID \
        --role $ADMIN_ROLE_ID \
        --tenant_id $SERVICE_TENANT_ID
  6. We then repeat this for our other service users, glance, keystone, neutron, and cinder:
    # Get the glance user id
    GLANCE_USER_ID=$(keystone user-list \
        | awk '/\ glance\ / {print $2}')
    
    # Assign the glance user the admin role in service tenant
    keystone user-role-add \
        --user $GLANCE_USER_ID \
        --role $ADMIN_ROLE_ID \
        --tenant_id $SERVICE_TENANT_ID
    # Get the keystone user id
    KEYSTONE_USER_ID=$(keystone user-list \
        | awk '/\ keystone\ / {print $2}')
    
    # Assign the keystone user the admin role in service tenant
    keystone user-role-add \
        --user $KEYSTONE_USER_ID \
        --role $ADMIN_ROLE_ID \
        --tenant_id $SERVICE_TENANT_ID
    
    # Get the cinder user id
    NEUTRON_USER_ID=$(keystone user-list \
        | awk '/\ neutron \ / {print $2}')
    
    # Assign the neutron user the admin role in service tenant
    keystone user-role-add \
        --user $NEUTRON_USER_ID \
        --role $ADMIN_ROLE_ID \
        --tenant_id $SERVICE_TENANT_ID
    
    # Get the cinder user id
    CINDER_USER_ID=$(keystone user-list \
        | awk '/\ cinder \ / {print $2}')
    
    # Assign the cinder user the admin role in service tenant
    keystone user-role-add \
        --user $CINDER_USER_ID \
        --role $ADMIN_ROLE_ID \
        --tenant_id $SERVICE_TENANT_ID

How it works...

Creation of the service tenant, which is populated with the services required to run OpenStack, is no different from creating any other users on our system that require the admin role. We create the usernames and passwords and ensure that they exist in the service tenant with the admin role assigned to each user. We then use these credentials when configuring the services to authenticate with the OpenStack Identity service.

Tip

Downloading the example code

You can download the example code files for this book at https://github.com/OpenStackCookbook/OpenStackCookbook. All the support files are available here.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image