How to secure webhooks?


#1

As far as I know, there’s no way to configure authentication for webhooks in general.

It seems to be possible for anyone who knows the artifact names, to trigger a webhook and override the artifact locations in the payload.

We save the pipeline json in the source repository, so anyone who can see the pipeline with a webhook, can potentially deploy anything in the project’s staging namespace (many projects in our company deploy automatically to staging but not to production)

Anyone got good tips or ideas how to secure webhooks?


#2

We are also using webhooks in our deployments, everywhere - and have of course the same issue. For us - we’d probably just add a payload into the trigger - and verify this payload in pipeline-configuration. As your pipeline configs are also in Git - these secrets are also there then - but still it’s better than having the webhooks open to everyone without protection.

My 1 cent :slight_smile:


#3

Is there a way to refer to kubernetes secrets in some way with pipeline expressions or something?

We could put a parameter in the pipeline to verify that a certain secret value is passed but we’ve got our pipelines saved as code so we’d need a way of using kubernetes secrets or something. Perhaps even put a secret in a GCS bucket but that sounds more complicated anyway


#4

Not that I know of… Not sure if anyone’s really addressed this ever…


#5

I assume you’re talking about incoming webhooks? The only secure way (I know of) is using webhooks from Github with a shared secret. Github includes an integrity hash in the call, we compute our own hash and compare them for equality. See https://github.com/spinnaker/echo/blob/924a74aae3bcb81182645ec8e7ce43581f3e7be6/echo-pipelinetriggers/src/main/java/com/netflix/spinnaker/echo/pipelinetriggers/eventhandlers/GitEventHandler.java#L137

There should be a “secret” field that appears when configuring a GitHub webhook trigger. Please let us know if that doesn’t show up for you.


#6

I think you’re referring to a git trigger, right? This wouldn’t really work for us because the webhook should be triggered when a gitlab CI build has run. Not when something is pushed to the git repository.

Using curl is fine for calling the spinnaker’s webhook but our security department doesn’t like it unless there’s some kind of authentication used.

At the moment anyone in the network could trigger a webhook. But not only that, they could also pass in any artifact in the webhook’s payload and pass an artifact.