For PnP experience, we should be probably delivering individual plugins like foreman_awx_hooks or foreman_rundeck_hooks. But I think the GH target audience is a fair point, admins will be more likely comfortable with some kind of executable.
What if we build a webhook service that would exec those scripts? Users who want more plug and play experience could simply deploy this service. By default we could install it on Foreman, if this was a socket-activated Ruby HTTPS service, it would consume zero resources on default installations.
Wer have already briefly talked about ServiceNow in this context. I personally donât have a need for that, but I guess it would be a nice use case. A user story could be: As a Foreman user, I want to automatically document all Foreman managed systems in my ServiceNow CMDB.
I believe the service could be similar to our prprocessor, ideally we would ship a small skeleton app ready to run in a container. It would just listen to the host create / update / delete events and call the matching ServiceNow API endpoints.
@sean797 makes a good point that the current hooks have a very simple security model: theyâre executed as a user known in advance. By adding networking into the mix, the security model is weaker.
You can use SSL client certificates to authenticate two-way. Github only signs webhooks and is therefor vulnerable to domain take overs to get more information. I donât know if this is relevant for the Foreman context. If created hosts are POSTed including parameters there can be passwords or other secrets.
Pushing messages to a local Redis might be more secure. Currently we do install one thatâs listening to localhost but thereâs no authentication which is an attack vector thatâs much harder to exploit. We could look into making it only listen on unix sockets and set permissions on that to further reduce it. It shouldnât be hard to write a reference Redis to exec() implementation.
The API is designed with this in mind, the payload is unusually just a database ID and NAME. Having said that, not an excuse for not using HTTPS of course.
We are getting mixed opinions about this, which is good actually - it confirms that our decision to create a core plugin API around hooks was a good one. I think in the worst case we can ship both plugins. Webhooks as a more consistent âDYIâ solution and Redis as âquick and dirtyâ script solution with some example scripts.
