We talk to DevOps folks every day that settle for using Chef™ and Puppet as their directory service. It can be an expedient method when you are getting going early in a company’s life or even later when you are spinning up a new project, but it is always a mistake in the long-term.
Chef and Puppet’s Rise to Popularity
Chef and Puppet have taken the IT world by storm over the last several years. They have been riding the DevOps wave, which has been so powerful that it’s more like a tsunami. The movement to DevOps has been pervasive.
Equally pervasive has been the belief that everything should be codified. For portions of the development pipeline and infrastructure, focusing on making everything code is the right strategy. But when it comes to managing user access, the configuration management tools leave a lot to be desired.
Limitations of Chef and Puppet
User management isn’t just about creating access for a user to a server or a set of servers. It’s also about controlling that user’s identity throughout the organization.
That’s an easy thing for developers and ops personnel to miss. They are focused on the project at hand and ensuring that the right engineers have access to the right infrastructure. After all, it is relatively easy to throw in a recipe or manifest to create users, stick SSH keys on servers, and to control permissions.
But the challenge comes when organizations start to think about how to manage levels of access. Not every person on a team will need the same levels of access over time. In fact, you’ll want to expressly prohibit access to certain infrastructure by groups of people. If you are subject to compliance regulations, then you’ll have the pleasure of proving that to the auditors.
As soon as you hit this level, the code that you need to write in Chef and Puppet expands enormously. Changes start to get harder and there are more chances for error.
While an organization is building a directory inside of their configuration management system, they either already have a separate directory or they have simply neglected to create a central directory that manages access to all IT resources.
This is the true problem with creating a separate directory in Chef and Puppet. It is disconnected from the core of the company. Missing are identities connecting to laptops/desktops and all of the SaaS-based applications that companies are using. By taking the quick path you’ve now created at minimum of two different user stores and that’s a recipe for disaster.
Directory-as-a-Service® is a Long-Term Solution
There’s a better way to do this and unify your user access to server infrastructure, desktops/laptops, and to SaaS-based applications: a central, cloud-based directory service. Called JumpCloud® Directory-as-a-Service®, this approach to user access centralizes control while easily providing access to devices, applications, and networks. Users are created inside of the DaaS console and then granted access to whatever IT resources the user needs. REST-based APIs can be leveraged and embedded into applications and servers to automatically populate users, authenticate, and group users or devices.
Chef, Puppet, and the other tools of their ilk are an incredible step forward for DevOps organizations. Unfortunately, too many developers and ops personnel are leveraging them for some of the wrong areas. User management is an area where a central, cloud-based directory service will benefit the organization more than configuration automation solutions.
If you would like to learn more about how JumpCloud’s Directory-as-a-Service can help, drop us a note.