Considered Hazardous – StarCluster “Create Users” Plugin


January 15, 2014 | DevOps | Kevin Gilpin


We recently got a customer question about the StarCluster “Create Users” plugin. The customer asked “Why do I need Conjur, since StarCluster can create users for me?” After reviewing the question, this seems like a great case study.

According to the Create Users plug in documentation:

This plugin creates one or more cluster users and configures passwordless SSH access between cluster nodes for each user.

The administrator is supposed to distribute the private keys to the users, and the users log in to the cluster node using the private key.

On the face of it this seems like a reasonable approach. But is it really much better than simply sharing a private key issued by EC2 (which is a security and compliance disaster)? Consider the following.

It’s Not a Real Identity

I am going to present a lot of detail below on why the Create Users plug in is a bad solution for terminal login. But it all ties back to one key concept: Create Users does not create real identities. Therefore, you can’t tell who is coming and going from the system, you can’t add and revoke access, and you can’t be sure that any log of a particular user’s access really corresponds to any specific human being (or robot). So from a compliance point of view, you are frankly next to nowhere.

Some further details on that:

It Makes More Shared Credentials

Create Users does not use the private keys of the users themselves. Instead, it is generating new private keys, and instructing the StarCluster admin to distribute these private keys to team members. Just because there are many _place_holder;shared credentials instead of one _place_holder; does not mean the situation is much better. It is still a shared credential.


It’s a Weak Form of Public Key Authentication

The private keys generated by CreateUsers are passwordless. The private key password provides an important security advantage of public key login, namely that the key you have and the password you know constitute a form of multi- factor authentication. Create Users doesn’t take advantage of this capability at all.

The Administrator Can Act As Any User

Private keys are supposed to be private. But with Create Users, the administrator has all the private keys, and hands them out to users. The private keys are not private at all;the administrator can impersonate any user. This has several bad implications, including:

  1. You can’t revoke the administrator’s access without revoking all the private keys (and locking out all your users).
  2. You can’t be sure that a system authentication log is reliable, since activity associated to any user could actually be performed by the administrator.
  3. You can’t distinguish between your administrators.

You Can’t De-provision a User

A very odd wrinkle of Create Users is that it will generate usernames; like user001, user002, user003. This is certainly an indication that the “users” don’t represent users at all, but rather shared passwords which don’t really have any rigorous meaning from an identity standpoint.

So given that “users” don’t represent real users, how can you revoke a user’s access? Sure, I guess you can turn off “user001,” but who is that, anyway?

Even if you do use “real” user names, how do you change the user list? It’s not clear from the documentation that it’s even possible. So once you create “linus, tux, and larry,” and hand out their private keys, they are valid forever unless you nuke your config and start over. That is not a very admin- friendly situation.

Generated Usernames Make the Audit Trail Useless

Suppose you do a thorough job of collecting authentication logs and storing them for audit or forensic purposes. What good does that do you? You can see user001 performing a bunch of actions, touching customer data and modifying it. Again, user001 is not an identity; it’s a shared credential. It doesn’t really mean anything.

How Do I Fix It?

The answer is pretty simple: require a real user identity for login. But in a cloud-based environment, where machines are constantly popping in and out of existence, there’s no obvious solution to this problem.

And in fact, it is a rather challenging problem to solve. Lucky for you, we have spent the better part of two years dedicating ourselves to solving it, creating the Conjur Terminal Login solution for cloud. We want real cloud security solutions to be easy, and available to everyone, and we want everyone to have the freedom and power to build innovative solutions in the cloud, using sensitive data, andpowerful software like StarCluster.

Conjur Terminal Login is built from the ground up to “bake in” industry best practices for cloud security:

  1. Fully supports dynamic and automated infrastructure such as StarCluster.
  2. Provides admins with simple tools to manage end-user access to hosts using their own identity.
  3. Installs automatically on each host.
  4. Requires no update scripts to be run in order to add a new user or revoke a user.
  5. Is 100% accessible via API and command-line, for the ultimate experience in programmability and scripting friendliness.
  6. Provides a complete and comprehensive audit record of all changes to terminal login policies.

It’s not magic, but it’s as close as we can make it. That’s why it’s called Conjur.





Keep up-to-date on security best practices, events and webinars.

Share This