Are you managing your server users in Chef and Puppet? It’s reasonably easy to do, and when you are considering most of the existing alternatives to user management, it seems like the easy way out. Pop in the users into a script and boom, they are on all of your servers. You can drop in their public keys and those are distributed out to all of your servers as well. Especially if you are leveraging Infrastructure-as-a-Service like AWS, Rackspace and others, this seems like a decent route.

Unfortunately, like anything in life, the easy way out usually has some catches to it…and so it goes with managing server users with Chef, Puppet, and other tools of that ilk. Don’t get us wrong, configuration management tools are excellent for a lot of things. In fact, if you are using them to automate the process of setting up your servers en masse, these tools are incredible. They save large amounts of time, build consistency and repeatability, and drive automation throughout the IT organization.

The challenge, however, comes in managing users as a distinct object in your enterprise. There are a number of issues to consider:

Central directory

Chef and Puppet are expressly outside a central user directory. Users are created, managed, and deprovisioned via scripts. There isn’t a single place where users are managed. This creates significant risk at any reasonably sized organization. Changes in personnel can lead to incorrect (and potentially dangerous) access configurations. That means that terminated employees could still have access to servers. With critical infrastructure often being placed in the cloud and easily accessible, this could be a significant risk to any organization. IT organizations have longed for one central, secure directory. Chef and Puppet unfortunately are a mechanism that takes organizations further from this desired state.

Least privileged access

One of the best practice in security and compliance that IT admins should follow is to grant users the least amount of privilege that they need to accomplish their jobs. While this is theoretically possible with configuration management tools, that isn’t the way that most organizations utilize them. The fastest, most efficient way that Chef and Puppet are utilized is to just grant all server users the same access, across all servers. For smaller organizations, this can work because there is a significant trust factor involved. As organizations grow, however, this is just poor IT practice. Additionally, to grant access at such a fine-grained level ends up being significant amounts of code.

Exposure of passwords and public keys

Users are created through scripts and each script requires the user’s username and password or public SSH key. In either case, these are provided and placed within the configuration automation infrastructure. These are potentially risk areas for an organization. But it’s another file with passwords and keys that isn’t necessarily securely stored or encrypted. Even having passwords hashed isn’t a sufficient solution — better not to expose them at all.

Admin intervention

If a user has a problem with their password or keys then the developer managing Chef or Puppet have to get involved. If the user forgets their password, the developer needs to rectify that. As new users are created, the Chef/Puppet managers need to pass those along – generally via email. All of this is insecure and time consuming. Best-in-class systems don’t have admin involvement when it comes to managing user accounts. It’s just bad practice and inefficient.

With all of these issues (and more), why do developers and ops folks still manage their server users via Chef or Puppet? Many of them already know these risks and issues but still choose to leverage the config management tools as it’s ‘in flow’ for them and is invariably the quickest reaction due to intimacy with the process of running scripts for virtually anything.

The problem is that there hasn’t been a better way. Most of the folks that are leveraging Chef and Puppet are also in the cloud at AWS or SoftLayer or Digital Ocean. How are they going to connect their users with their existing directory (if they have one)? Cloud server users aren’t easily managed by on-prem Active Directory or LDAP. They certainly are not managed from Google Apps’ user store. The next option on the pick list is spinning up an LDAP system in the cloud. That’s quickly discarded because of the time and effort required to setup, network, and then subsequently maintain it. So, it defaults back to just do it manually – or in this case, a variant of that – I’ll generate them manually with scripts inside of Chef and Puppet. It turns out to be the best option out of a bad set.

Ideally, developers, ops, and IT folks would all like to take the issue of managing users on servers off the table. They all agree that it should be controlled, secure, and efficient. If you talk to folks that use Chef and Puppet extensively, they would much rather have a central user management system – they know the risks involved. They would also like to have more fine-grained control over user access and take the issue off of their plate with an automated system.

As extensive users of configuration automation solutions, we have been looking deeply at this problem for over a year. JumpCloud’s hosted LDAP solution is an ideal solution to this vexing problem – how to be efficient and secure managing users on cloud servers. Users can be either created and managed in JumpCloud’s directory or the organization’s existing Active Directory, LDAP, or Google Apps user store can be extended to JumpCloud and subsequently their cloud server users managed. JumpCloud’s Directory-as-a-Service™ offering solves for the issues that IT organizations have with configuration automation solutions:

–          One central, secure directory

–          Fine-grained access

–          Security of passwords and keys

–          Self-service portal for users

In short, JumpCloud’s cloud-based LDAP ends up being more efficient than Chef or Puppet, more secure, and less work for IT admins. If you are using Chef or Puppet (or one of the other config automation tools to manage your server users, don’t! Give us a call – we can help and you’ll feel much better by leveraging our managed, hosted LDAP offering.

Greg is JumpCloud’s Chief Product Officer, overseeing the product management team, product vision and go-to-market execution for the company’s Directory-as-a-Service offering. The SaaS-based platform re-imagines Active Directory and LDAP for the cloud era, securely connecting and managing employees, their devices and IT applications.