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:
Using your favorite editor, enable LDAP authentication in the
Next, create the
ldapsection and add the URL to your existing LDAP server:
[ldap] url = ldap://openldap
On the following lines, specify the LDAP path for the
adminuser 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
In the same
[ldap]section, we tell Keystone four pieces of information about how to find users.
user_tree_dnspecifies which OU within the LDAP tree to search for users.
user_objectclassspecifies how a user is represented within LDAP
. user_id_attributetells Keystone which property of the user to use as a username. Similarly,
user_mail_attributetells 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
Next, add the same details for Tenants and Roles:
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
Save the file and restart
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.