Limit action-alias to chat channels/users.

[pixelrebel]

A simple way to provide access control to chat commands would be to allow channel and/or user limits in the alias script.

[Kami]

Thanks for the report / feature request.

RBAC for ChatOps is indeed on our roadmap for this year, but we don't have an ETA for it yet.

Only listening for commands on a single channel could be a good short-term workaround since it should be easy to implement. I will discuss it with others and see how this fits into our roadmap, maybe we can do that first and deprecate this functionality once full blown RBAC for ChatOps is available.

[pixelrebel]

I thought I'd get the ball rolling on this feature.

pixelrebel@1a557a5

I have it working in Slack at the moment. Now you can enter an optional action alias property:

channels: 
  - "channelname1"
  - "mychannel2"

Please let me know what you think. :)

[pixelrebel]

Fixed an oopsie:

pixelrebel@b8f0a47

[emedvedev]

The PR is solid, but I'm -1 on merging it, and there are two main reasons behind the decision:

1. Ideally, you need to provide a way for people to see which commands are available for them and where. Hubot's !help is a standard plugin which doesn't allow for channel/user separation, so we also need to fork and rewrite it before this change is good from the UX standpoint.
2. We're likely launching the development process for ChatOps RBAC in 4–5 weeks (that's a plan, not a promise 😛). Since I'm not sure that's how the limitation will be implemented, and not sure that's what the property will be named, we may have to deprecate this change later, and deprecating something ~two months after it's been introduced isn't a good thing.

There's also a debate about aliases ideally being more generic than that, but we'll set it aside for now.

To summarize, I really appreciate the work, and I'll gladly point people asking about this feature towards your branch, but we won't merge until we're sure that's how we want to tackle this and until we have a better !help story.

[pixelrebel]

@emedvedev I certainly can respect your opinion. And I understand how this could potentially conflict with RBAC. As for issues with !help dialogues, it is possible to just concat the allowed channels to the action alias description. I know it's a cheap fix, but in my opinion, hubot's help is pretty broken and useless anyway. I find myself having to implement man pages (even for simple commands) in chat so users can see some examples. People learn best from examples. Hubot's one-line help dialogue just doesn't cut it.

Implementing RBAC for chatops is going to be very tricky, first thing that comes to mind, is how do you resolve st2 users with chat users? My guess is that each role will need a token placed into a hubot config somewhere. Secondly, this implementation will also have to contend with the !help issue.

Personally, I'm at a point where convincing my team to manage infrastructure through chat requires some sort of rudimentary access control just to sell a proof of concept. I couldn't move forward with st2 without adding the feature. We currently have access control with our hubot scripts, so moving our command through st2 removes this functionality and makes it a deal-killer.

I'm actually surprised more folks haven't asked for this. For me, it seems like channel limitation is a feature that elegantly complements more complex RBAC. I'm personally hoping that st2 embraces some of the concepts @michaelansel evangelizes. For example, allowing a subordinate to issue a command, but requiring in-chat approval from a superior before the command is accepted and executed. That's some complex enterprise-level features, but the community version also needs a basic lock on the door.

I understand your trepidation, but please consider a way to provide rudimentary segregation of chatops commands for the community version of st2. I didn't make a formal PR because I figured RBAC implementation may require an update to the action alias model. It's worth waiting to see in which direction that goes before hacking this into the model, but I think st2 is going to need both RBAC and also a 'free' implementation. Without access control, chatops is just a fun novelty that can't be embraced by operations teams.

[emedvedev]

@pixelrebel I agree with you. Help, auth implementation, confirmation and access tuning are all valid concerns, and while RBAC is an Enterprise-only feature, we won't leave Community users without means to control their ChatOps executions, of course. People are asking for this quite regularly, and we're doing our best to deliver the access control features as soon as possible. It will still take time, but it's very high on our priority list (and in our roadmap as well).

As far as in-chat approval goes, I remember @emptywee making some interesting developments using workflows and the KV store, and I also played with it a bit in st2-release: https://github.com/emedvedev/st2-release/tree/master/actions/workflows (although my requirement was getting approval from any other team member). That's not ideal, but if no approval is a deal breaker and you have an immediate need, you can look into it.

[jjm]

I'm also interested in this feature, being able to limit some commands to certain channels (and have additional user control) would be really useful. For instance we don't want sales spinning up lab VM's....

I'll look forward to what you guys produce :-D Shout if you want someone to help test it out.

[emedvedev]

@jjm: we definitely will!

Honestly, if you want to dig into the source code a little and need this feature yesterday, the easiest solution in terms of both time and complexity (although certainly not elegance) would be to insert a whitelist/blacklist of aliases/channels/users in hubot-stackstorm. Unfortunately, that would only give access control to people who have access to the bot files or the docker container (also it's just plain ugly), but it's probably the fastest way to achieve what you want without a lot of hacking into StackStorm source code.

[jjm]

If I need to do per user limiting before you deliver sometime before you get there. I'll follow some of the examples and create an has_user_privs action in our pack against and drop it into the required workflows.

[emedvedev]

That would be a cleaner option, yes. :)

[pixelrebel]

@jjm Your welcome to try out my solution which allows you to add a channels parameter in your action alias (see above usage example). You just need to replace 3 files in 2 python modules (st2common, st2api).