Fixing syntax mistake, clarifying why pillar don’t work

[renoirb]

I’ve spent time trying it out, its great! Except I found a small syntax error :)

While thinking how to use it, I thought we’d like to parametrize the secretkey and realized too late that reactors can’t get access to it. I adjusted the readme to give a solution path on how to parametrize it.

[madflojo]

Hey @renoirb,

Were you using grains in the {{ grains['something'] }} format or salt['grains.get']('something')? I believe the salt['grains.get'] method will allow grains that are set on the master itself to be accessible in the reactor. Or at least I think it should be. I did some testing with this but didn't have enough time to get it to work with the secretkey value.

Either way your solution also works but I was hoping to get this to a grain value at least.

For the postdata.service vs postdata.args thanks for catching that but we should probably fix the example (in the README.md) so that folks who have already integrated this wouldn't be impacted by a change later. Plus in most of the other items we used .args vs a unique item.

Once we get this hashed out and merged I will push it down to the official salt-formulas repository.

[renoirb]

Thanks for the feedback. I tried many ways but I disagree with using grains to store a secret. I might get convinced if we have no choice at all though.

But instead of making a simple test payload.secretkey == grain['saltapi_secretkey'] I’d rather review which use case we really want to cover.

My use-case, for example, is to use a GitHub hook and run a state.sls only if a payload signature is valid with the same secret key. That might be out of the scope of your recipe then. But, there again, if I have no choice to use grains, so be it.

I started a strawman runner in this gist.

I’ll keep you updated on the findings and feedback I get.

[madflojo]

Actually, you're right we shouldn't use grains.

Pillars are the right answer because they are salt's method for storing sensitive data. With grains they are either stored within the state file_roots directory, which is copied to every host or in /etc/salt/grains. Which is generally readable by non-privileged users. I think the end goal should probably be to use pillars, so the method you wrote up is a great solution until salt itself would allow pillars to be read from reactor. I know that it currently does not work.

As far as use cases go I am totally open to add in use cases. The only things I want to make sure is that they are generic enough for anyone to use. The github webhook is an awesome idea and we should probably look at adding additional external pre-defined webhooks as well like TravisCI, Logentries, Paptertrail, Slack and so on. The trick is tieing the authentication logic with the logic to run the actions.

We may want to relook at the structure a bit and create reactors.sls files that handle the authentication piece, populate data then include .sls files that actually perform the action.

Something like having requests that go to /hook/github/something/something be mapped to a github_auth.sls which basically does the following.

<validate github authentication>
{% included_action = <something that pulls the endpoint from the request> %}
include:
  - {{ included_action }}.sls

Something like that, let me think about this for a second.

[renoirb]

Hey, thanks for the merge. I haven’t spent more time on that, did you work something out?

[madflojo]

I haven't had much time to work on it so I merged the description you put
and fixed the example.

On May 23, 2015 11:07 AM, "Renoir Boulanger" notifications@github.com
wrote:

Hey, thanks for the merge. I haven’t spent more time on that, did you work
something out?

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

[renoirb]

Hey, by the way.

I'm back working onto something that uses salt-api to run deploys. If you've been searching a way to validate a GitHub hook through salt-api, I just found the ideal solution.

I thought you'd enjoy!