
OpenStack Cloud Computing Cookbook, Third Edition
By :

The OpenStack Identity service that we have built so far provides you with a functional, but isolated, set up for your OpenStack environment. This is a useful setup for Proof of Concept and lab environments. However, it is likely that you will need to integrate OpenStack with your existing authentication system. OpenStack Identity provides a pluggable authentication back end for this, with LDAP being the most widely used.
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
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
Additionally, to connect to an external LDAP service, you will need to possess the hostname or IP address of the LDAP server and have appropriate access to the server. You will also need to have the LDAP path information for an admin
user, and for the Organizational Units that contain the Users, Roles, and Tenants.
We have provided a sample OpenLDAP server that is prepopulated with the required values as part of this book's supplementary materials, and instructions on how to use it located on our book blog at http://bit.ly/OpenStackCookbookLDAP
To configure OpenStack Identity to communicate with LDAP, perform the following steps:
keystone.conf
file:[identity] driver=keystone.identity.backends.ldap.Identity
ldap
section and add the URL to your existing LDAP server:[ldap] url = ldap://openldap
admin
user you will use, along with its password and the suffix, or where you would like Keystone to begin searching LDAP:user = cn=admin,dc=cook,dc=book password = openstack suffix = cn=cook,cn=book
[ldap]
section, we tell Keystone four pieces of information about how to find users. user_tree_dn
specifies which OU within the LDAP tree to search for users. user_objectclass
specifies how a user is represented within LDAP. user_id_attribute
tells Keystone which property of the user to use as a username. Similarly, user_mail_attribute
tells Keystone where to find the user's e-mail address. The code is as follows:user_tree_dn = ou=Users,dc=cook,dc=book user_objectclass = inetOrgPerson user_id_attribute = cn user_mail_attribute = mail
tenant_tree_dn = ou=Projects,dc=cook,dc=book tenant_objectclass = groupOfNames tenant_id_attribute = cn tenant_desc_attribute = description role_tree_dn = ou=Roles,dc=cook,dc=book role_objectclass = organizationalRole role_id_attribute = cn role_member_attribute = roleOccupant
keystone
:sudo stop keystone sudo start keystone
The OpenStack Identity service, like other OpenStack services, is based on plugins. In its default state, Keystone will store and access all user identity and authentication data from a SQL database. However, when integrating OpenStack into an existing environment, this is not always the most desirable or secure method. To accommodate this, we changed the identity back end to LDAP. This allows for integration with OpenLDAP, Active Directory, and many others. However, when configuring the backend, you need to pay special attention to the LDAP paths.
Where are the entries for the services catalog? These are still stored in Keystone's SQL database, as they aren't specifically related to user identity or authentication.
Change the font size
Change margin width
Change background colour