Ossipee started off as OS-IPA. As it morphed into a tool for building development clusters,I realized it was more useful to split the building of the cluster from the Install and configuration of the application on that cluster. To install IPA and OpenStack, and integrate them together, we now use an ansible-playbook called Rippowam.
I’ve got a packstack install, and a Kerberos-capable Keystone. Time to call it from Horizon. Time to set up S4U2Proxy.
In a recent post, I described how I configured a web server to user mod_lookup_identity. Now, I use that configuration to provide a test for the recent Federation work in Keystone. This is a really rough proof of concept; do not expect to be able to use this in your production environments yet.
“Don’t repeat yourself.” This rule is such a core principal in programming it has been reduced to the acronym DRY. Yet, somehow, every web application framework out there ends up with a custom authorization framework; LDAP, SQL, and usually a Flat File authorization list.
Apache HTTPD can and should perform a cryptographic based authentication for your users. Even better, it should be able to return to you the user attributes necessary to perform accurate authorization. REMOTE_USER has been the standard ever since CGI first appeared for the web. Now we can extend that approach to a generic set of user attributes for authorization. mod_lookup_identity.
I’m starting on a proof-of-concept setup where, instead of using the LDAP backend for Keystone, I use mod_identity_lookup to fetch the data at the HTTPD layer. Here are the steps I went to configure the system.
While Packstack makes it easy to get OpenStack up and running, it does not (yet) support joining to an existing Directory (LDAP) server. I went through this recently and here are the steps I followed.
Once you have a Directory server installed, you are going to want to query against it from throughout the Network. For many reasons, you will want traffic to the server encrypted. Here are the steps to quest against a server using LDAPS from a remote machine.
The next interim release of Openstack Keystone will once again have LDAP support. I am developing against OpenLDAP to start, as that is what the LDAP support has been based on in the past. However, the directory server that backs FreeIPA works perfectly well, and provides a backend that allows for Keystone support.
A recent change in the structure of the Openstack Keystone architecture resulted in the loss of support for an LDAP Backend. I’ve been working to rectify that. Here’s my set up and the design decisions I’ve made so far. Since this code is not yet submitted for code review, there is a good chance that it will change prior to deployment.
The documentation on the OpenLDAP site discusses modifying the ldif files used to start up the server. If you try to do this on a Fedora or Debian based install, you will find that the server does not start up. The HASH of the files is stored and compared with the contents at start up time. There is a better way.
The Domain Name System (DNS) is an essential part of systems management. If you need to manage multiple physical hosts you’d really benefit by a degree of control of some subset of DNS. With Virtual machines, the sheer number of hosts created demand a responsive DNS. Kerberos, X509 and other security mechanisms require a proper DNS configuration. Yet, for many organizations, DNS is locked down by IT to a very static set of records. Earlier articles discussed User Groups, Host Groups, and Netgroups. The final installment in this series discsusses how to delegate DNS Zone management in FreeIPA.