New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limit action-alias to chat channels/users. #2481
Comments
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. |
I thought I'd get the ball rolling on this feature. I have it working in Slack at the moment. Now you can enter an optional action alias property:
Please let me know what you think. :) |
Fixed an oopsie: |
The PR is solid, but I'm -1 on merging it, and there are two main reasons behind the decision:
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 |
@emedvedev I certainly can respect your opinion. And I understand how this could potentially conflict with RBAC. As for issues with 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 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. |
@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 |
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. |
@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 |
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. |
That would be a cleaner option, yes. :) |
@jjm Your welcome to try out my solution which allows you to add a |
Hi I test solution with st2 2.9.2 and works for me. I add channel inside alias file and can limit run action-alias for channels. |
A simple way to provide access control to chat commands would be to allow channel and/or user limits in the alias script.
The text was updated successfully, but these errors were encountered: