@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_username
and 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 config values:
url: ...
username: ...
password: ...
But this runs into issues where a ST2 user may want to override username and
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 url value.
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 host and
port options above. This method would allow users to override username and
password and let the ST2 admins specify the host and 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 username and 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 username and password values
would need to be overridden as well, but poll_interval, project, and verify
would not need to be explicitly overridden.
Here’s an example config schema:
---
url:
description: "URL of the JIRA instance (e.g. ``https://myproject.atlassian.net``)"
type: "string"
secret: false
required: true
username:
description: "Username if using the basic auth_method"
type: "string"
secret: false
required: false
override-with: url
password:
description: "Password if using the basic auth_method"
type: "string"
secret: true
required: false
override-with: url
poll_interval:
description: "Polling interval - default 30s"
type: "integer"
secret: false
required: false
default: 30
project:
description: "Project to be used as default for actions that don't require or allow a project"
type: "string"
secret: false
required: true
That config schema would allow child configs to specify their own username and password
parameters without needing to override url, but it would force them to specify their own
username and password parameters if they specified their own url
parameter.
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.
