@pdenning To answer your question directly: this is something that has to be designed into the pack actions themselves. And this does fundamentally shift the security model of StackStorm configs (more on this at the end). It is also not as easy or straightforward to implement securely as it might appear.
However, as Nick noted, the vast majority of packs would benefit greatly from this, it’s just that nobody has bothered to implement it. As I’m sure you’ve seen, there are quite a few packs in our official Exchange.
I can think of at least two different ways to implement this.
Method #1: Add specific, optional parameters to actions that override the values specified in the central pack config. You would have to do this for every action in every pack you want to use this way, and it would be difficult to force a consistent implementation across different packs (although we might be able to help you update packs in the Exchange, depending on our availability). This would allow pack authors to limit what options can be overridden (more on this later). For instance, actions in the Jira pack could allow ST2 users to specify their own
jira_password options that would override the default StackStorm config values. This basically would change the way the central pack config is treated, and would treat it as a collection of “default” values for each organization that is using StackStorm.
Method #2: Add a single
config dictionary parameter to actions that overrides the entire central pack configuration. This could be implemented in fewer places than every action in every pack, but it would be slightly clunky for action users to use because they would need to know - a priori - what values to use for all values in the config dictionary. For example, actions in the Jira pack could rely on the following
But this runs into issues where a ST2 user may want to override
password, but not override
url. They would need to know what the “default” value is for
url are in the central pack config, and if that value ever changed, each action execution would need to be updated to use the new
Method #3: Allow users to override some central pack config values without having to override all config values. This sounds like a great solution, but it requires a lot more refactoring in ST2 itself than it might first appear. Consider the Jira
port options above. This method would allow users to override
password and let the ST2 admins specify the
port values (which would be pulled from the central pack config).
However, this could extremely easily lead to security issues. A malicious user could override only the
host parameter and point it to a server that they control. When they run that action, StackStorm would use the
password values from the central pack config, and attempt to login to the malicious
host. All they have to do is capture the credentials from the login attempt and they have the default values from the central pack config. And usually you would want those values to be for a Jira account that has a lot of permissions on Jira (eg: a Jira admin account). So any user could fairly painlessly capture admin credentials using this method.
The “proper” way to address this is to implement configuration inheritance in StackStorm itself, which, as the name would imply, could get very messy very quickly. Essentially, this would require support in configuration schemas for specifying configuration value dependencies. For example, if the
url config value is overridden, the
password values would need to be overridden as well, but
verify would not need to be explicitly overridden.
Here’s an example config schema:
description: "URL of the JIRA instance (e.g. ``https://myproject.atlassian.net``)"
description: "Username if using the basic auth_method"
description: "Password if using the basic auth_method"
description: "Polling interval - default 30s"
description: "Project to be used as default for actions that don't require or allow a project"
That config schema would allow child configs to specify their own
password parameters without needing to override
url, but it would force them to specify their own
password parameters if they specified their own
This is definitely an advanced feature, and (as far as I know) would only be used by a small minority of StackStorm users/installations. Furthermore, because it requires a high degree of understanding, it would be easy for pack authors to incorrectly specify dependencies, or specify them in reverse order.
I’m not saying the third method would be rejected, I’m just trying to explain why this isn’t as simple as it may appear on the surface.
If you have PRs to add override parameters (a la method #1), I think we’d be happy to have them (just be judicious in what parameters you allow to be overridden).
PRs for method #2 would probably be the best payoff in terms of your investment, but I would recommend creating a PR for one pack and then getting the StackStorm team to review it, since it would be a little clunky from a StackStorm user perspective.
Implementing method #3 should be done with buy-in/coordination with the StackStorm team.
Note: The term “central pack config” is a phrase I made up in this post simply to differentiate it from an overridden config specified by a user when running an action. It does not appear in StackStorm documentation, and people outside of this discussion will not know what it means.