Managing Shell Access In A Cloud Environment – Part II

by Ali Tayarani in


We previously discussed why Tapjoy selected OpenLDAP for authentication, so this time we’ll discuss how we implemented it.

Redundant Servers

We set up the servers using syncrepl with a bidirectional sync.  This allows an active-active failover despite the fact that each server initially writes to an mdb instance locally.  We stuck with mdb as the database as it is highly recommended by OpenLDAP to write to a local nosql database.

To protect the directory synchronization, we created a role account that exists only for that purpose.  The way we configured replication was with the following ERB code block:

Scaling

Since redundancy is only one piece of a good disaster recovery plan, we leveraged fog to look for other LDAP servers in the local network and add them to the list of replication targets.  By doing this, along with code blocks designed to seed the directory with the base set of objects, we are able to autoscale the LDAP servers.

Of course, we can’t scale the servers if the LDAP clients can’t find them, so we leveraged HAProxy.  In the HAProxy configuration, each LDAP client points to localhost and HAProxy maintains a list of LDAP servers using a mechanism similar to how to list replication targets.

Centralization

In the last post, we stated the need for a central authority.  While LDAP can handle users and groups out of the box, we needed a little more functionality to make LDAP more authoritative.  This took the form of the LDAP schemas available in openssh-lpk (https://code.google.com/p/openssh-lpk/).  The actual openssh fork may prove to be useful; however, we felt it would add unneeded overhead to have to maintain the fork internally.

In our implementation, we leveraged the schema to store users’ SSH public keys with their user profile.

The schema is provided here for reference:

SSH and Home Directories

Not forking SSH led to an interesting problem: how do we manage the public keys without adding significant bloat to the servers?

We modified the sshd_config to search home directories first, then search a common path for authorized_keys.  By using ‘%u’ in the configuration, we are able to give each user a directory for their authorized_keys without having to create their home directory in advance.

The following Chef 10 code adds the necessary lines to sshd_config without affecting the rest of the file:

Using the concepts mentioned here, you can set up a user management system that easily scales and is highly flexible.  If you find that there is more that you need, remember that LDAP is extensible and there are many resources available to help.

 

Think this is interesting? We're hiring! See our current openings here.