Securing BuildConfig webhook secrets

[gregswift]

The OpenShift documentation around Github Webhooks states the following:

GitHub webhooks handle the call made by GitHub when a repository is updated. When defining the
trigger, you must specify a secret, which will be part of the URL you supply to GitHub when
configuring the webhook. The secret ensures the uniqueness of the URL, preventing others from
triggering the build. The following example is a trigger definition YAML within the BuildConfig:

This secret, which I'll henceforth call url_secret, is used to ensure uniqueness of the OpenShift URL, which Github POSTs to when events happen on a repository (pushes, merges, deploys, pull_requests, etc.)

Unfortunately, it's not a great idea to use url_secret as a true secret. Anyone with the necessary permissions on the GitHub repository can view the Hooks and Services page of the repository and see the full URL (including the url_secret) as plain text.

With that URL, arbitrary web hooks could be sent to OpenShift, and OpenShift will think that it's GitHub sending the webhook.

GitHub does have a mechanism to prevent this. When creating/configuring a new webhook in the GitHub UI, GitHub allows you to provide its own optional "secret" field, which I'll call github_secret. This is a true secret value, and once entered into the GitHub UI, it is never again viewable in the UI.

If a github_secret is configured for a webhook, then when Github POSTs events to OpenShift, an additional X-Hub-Signature header will be included with the POST. GitLab uses X-GitLab-Token and Gogs uses X-Gogs-Signature

This header will contain a hash of the POST body, computed using an HMAX hexdigest, using the github_secret. (See https://developer.github.com/webhooks/securing/ for details).

If OpenShift were aware of the X-Hub-Signature header, then on receipt of a webhook, OpenShift could calculate the HMAC hexdigest on its own, to verify that it was in fact GitHub that sent the message. Only someone who knew the github_secret would be able to craft the correct HMAC hexdigest.

Many web hooks are possible from GitHub. Some might eventually cause OpenShift to do things like automatically kicking off a deploy to production. We want to ensure that it is in fact GitHub sending the message, and not a malicious party. To do this, OpenShift must be modified to make it aware of the these headers.

OpenShift would need to modify its verifyRequest function to check for the presence of the respective headers, and it would also need a way to specify the secret somewhere in a project's config.

Until then, the url_secret really is a kind of secret, but it's a secret that's visible any time in the GitHub UI or in the stored BuildConfig, and thus not very secret at all. Permissions on GitHub repositories will have to be such that only necessary people are allowed to see the Settings page, and also that only necessary people are able to see the url_secret value in the OpenShift project config, and BuildConfigs have to be encrypted or not stored in code.

Version

$ oc version
oc v1.5.0
kubernetes v1.5.2+43a9be4
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://rsi.rackspace.net:443
openshift v1.5.0+031cbe4
kubernetes v1.5.2+43a9be4

[bparees]

yup, adding support for the github secret payload is being tracked on our feature backlog:
https://trello.com/c/ez141U00

closing this issue in deference to the existing card.

[sbose78]

Has the support for this been added?

[bparees]

yes.
https://docs.okd.io/latest/dev_guide/builds/triggering_builds.html#webhook-triggers

[sbose78]

@bparees This is not payload validation by comparing the hash[1], right? This is more about having obscure unique URLs.

For all webhooks, you must define a Secret with a key named WebHookSecretKey and the value being the value to be supplied when invoking the webhook. The webhook definition must then reference the secret. The secret ensures the uniqueness of the URL, preventing others from triggering the build. The value of the key will be compared to the secret provided during the webhook invocation.

[1] https://developer.github.com/webhooks/securing/#setting-your-secret-token

[bparees]

sorry I mixed this up w/ something else. No it has not been implemented.

[costa-simulatedreality]

Does Openshift support github webhooks to trigger new build or is it still an issue?

[bparees]

Does Openshift support github webhooks to trigger new build or is it still an issue?

it has always supported using github webhooks to trigger a new build, but the items raised in this issue have not, to my knowledge, been addressed/added as functionality in terms of validating the webhook request.

[mpspm]

Do interceptors support validating webhook requests with the X-Gogs-Signature header set? I have a Gogs repo where I'm trying to validate with an interceptor but I don't see one for Gogs. In the docs I see Github, Gitlab, Bitbucket and Slack, but not for Gogs. When I use the Github interceptor anyway, I receive this log message for the event listener:

{"severity":"info","timestamp":"2023-09-03T23:36:00.695Z","logger":"eventlistener","caller":"sink/sink.go:420","message":"interceptor stopped trigger processing: rpc error: code = FailedPrecondition desc = Must set X-Hub-Signature-256 or X-Hub-Signature header",...}