improve granularity of the ssh jobrunner, make recommendations to the community about proper use of sudoers, restricted ssh accounts.

I've been getting ready to spin up a little evaluation of stackstorm, as a tool I might like to use to enhance integration between other tools I already use - hubot, jenkins, chef - and I understand that there are things people are already thinking about and working on with regard to the ssh-runner.

My intent here is to outline a bunch of points where I think things could get significantly better; keep in mind that I'm not looking at or running the bleeding-edge code, yet, so some of these may have already been addressed. (My vagrant box seems to have 0.12.1 in it, installed with the chef-stackstorm cookbook.. just so you know what I'm starting from. I'm also looking over documentation online to try to figure out what issues may arise.

The "SUDO Access" and "Configure SSH" parts of the page at http://docs.stackstorm.com/install/config.html elicit a very, very unpleasant reaction from me, and from others in informal discussions I have already had.... things that should get fixed, in my opinion.

• Keys should have granular, auditable actions associated with them.
  Do-everything keys are flexible and make it simple but also... can do far too much. Even in the modern, flexible world of short-lifespan containers, this sort of thing is extremely dangerous.
• Users (e.g., 'stanley') should have a limited scope of rights, defined by policy.
  I strongly recommend refactoring all of the examples to NOT assume an all-powerful stanley - this would do a tremendous amount to make security personnel more comfortable with the product. If TAPS (the all powerful Stanley) needs to be given as an exceptional case, because people want that, it should be explained last, with many caveats.
• unrestricted sudoers for ANY account is Very Bad in security terms.
  Where possible, setting things up so that you have a single-tasked or restricted account with sudo access is much better. Principle of Least Privilege - you want to scope things so that many things are possible out of the box, and with effort even more become available.
• ssh keys in an authorized_keys file that are for noninteractive users should always have a restricted-command ("command=") associated with the key.
  Noninteractive use of ssh is different. When there are keys that can do "everything" - like an interactive shell user can - one really should make sure that those credentials are tightly, tightly controlled - preferably with two-factor auth. This is difficult with non-interactive sessions, so limiting the scope of what can be executed is important.
• key rotation
  For noninteractive sessions, it would be pretty slick if stackstorm had some sort of a key expiry mechanism, so that privileged keys don't just sit around forever. :) Maybe it could be taught to re-key itself - not sure. Thinking out loud, here. That'd require giving a user privs to update its own authorized_keys, which... is probably counter to the intent of locking such things down.
• It would be awesome to leverage the output of 'sudo -l' so that stackstorm 'knows' what commands are going to be available and not, from a job-runner's perspective.
  From my perspective as a chef user, one of the things we've done right is to put some of this in chef- so that we're generating users, locking them down, and we can have a rather simple jenkins job that just fires off the chef-client with an argument telling it which cookbook recipes to run.
• Key storage
  It would be good to figure out a way to make it much more difficult to access keys that you might want stackstorm to be able to use; storing private keys of individual users on the filesystem seems like a very bad idea to me. Have you looked at setting things up so that users can hook ssh-agent up to stackstorm somehow? Even having the keys stored as mode-700 somewhere, just for stanley, is a serious issue - because the StackStorm host that has the keys becomes a huge target for someone who wants to invade a customer's infrastructure - it's the magical bastion host that can 'own' all of the other infrastructure that it has been allowed to connect to.

I'll repeat myself again -- I don't mean for anyone to take any of this personally, but these are some speedbumps that I can already anticipate are going to come up the first time that an auditor looks carefully at this software, and which will just plain make deployment difficult.

I'm still an outsider - it is possible that there are things here that I'm overreacting about, in the extreme - but I find the ssh-runner bits being able to run a sudo session as stanley that can do anything quite bothersome. I'm willing to dig in and help figure out how to fix, though my python is a bit weak - I like the scope of the tool's capabilities and want to be able to use it. ;-)

best,

--e

Start with the SUDO Access and Configure SSH sections of the install configuration documentation and review the ssh-runner entry points they describe. First separate the proposed jobrunner, sudoers, restricted-account, key-rotation, and key-storage concerns into scoped work; done requires an agreed scope and corresponding security guidance or implementation plan.