Propose a way to secure webhook trigger

[hurngchunlee]

Since we have a working directory for each webhook under user's home directory, I think we could make use it to allow creating webhook-specific secret using an approach similar to the .htpasswd file.

For example, after a user creates a webhook,

$ hpcutil webhook create {qsubScript}

The user can optionally secure it by using the client:

$ hpcutil webhook secure {webhookID} --secret {webhookSecret}

or these two steps can be combined in one command:

$ hpcutil webhook create {subscript} --secret {webhookSecret}

Under the hood, the client tool writes the (oneway-hashed) secret in a file (e.g. secret) in the webhook's working directory.

When there is a trigger to the webhook, the server checks whether there is such secret file available in its working directory, if so, it tries to match the secret received from the HTTP request header to the secret in the file. The following qsub command is only performed if there is a match.

If the webhook folder doesn't have the secret file in it, the trigger is then accepted without the check. This allows the user to remove (and reset) the secret easily by just remove the secret file.

[hurngchunlee]

Hashing password: https://godoc.org/golang.org/x/crypto/bcrypt

[hurngchunlee]

An example code for handling github webhook secret: https://gist.github.com/rjz/b51dc03061dbcff1c521

Detail about how the secret is used when sending payload: https://developer.github.com/webhooks/securing/

It seems to be a Github specific way.

[robertoostenveld]

is there still anything to be done for this issue? If not, please close it.

[aardkronkel]

The proposed security comes at a price: the generic and simple approach that we have now might break down.

Each service has its own security approach (e.g. github requires certain HEADER fields to be set). It is nearly impossible to come up with a generic approach that works for all.

@hurngchunlee : Is it acceptable for you to shelve the suggestion with the secrets for now?