官术网_书友最值得收藏!

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.

主站蜘蛛池模板: 新建县| 竹溪县| 雷波县| 中阳县| 呼伦贝尔市| 江口县| 清新县| 山西省| 灵川县| 文水县| 松溪县| 杂多县| 宜黄县| 云林县| 西华县| 台中县| 盐城市| 揭西县| 广汉市| 华池县| 武川县| 公主岭市| 铜川市| 元氏县| 交城县| 盐源县| 东莞市| 景德镇市| 南丰县| 潢川县| 电白县| 措勤县| 桂平市| 长沙县| 松滋市| 怀来县| 桑日县| 十堰市| 房山区| 蒲城县| 寻甸|