Enable Webhooks to sent client key/cert
Problem to solve
Customer's Jenkins system requires an SSL client key and certificate in order to authenticate. Prior to upgrading to GitLab EE they used a source installation and patched the web hook model to allow this.
Specifically, the patch they applied was in the WebHook#make_request method:
if Gitlab.config['pem_cert'] and Gitlab.config['ssl_ca_file']
pem File.read(Gitlab.config['pem_cert']), Gitlab.config['pem_cert_passphrase']
ssl_ca_file Gitlab.config['ssl_ca_file']
endIf we have this as a proper feature in GitLab there's probably a question about whether it should be a global configuration or where a user uploads the key and cert specific to a given web hook. An initial concern about a global hook could be that the private key and cert would be sent with all web hooks even those that don't require it. This could be a potential security issue, I'm not sure.
Original description
When a webhook gets triggered in our environment, our server (GL) needs to presented to the receiving server (for example Jenkins). We have some code inside that adds it to the model for webhooks:
if Gitlab.config['pem_cert'] and Gitlab.config['ssl_ca_file']
pem File.read(Gitlab.config['pem_cert']), Gitlab.config['pem_cert_passphrase']
ssl_ca_file Gitlab.config['ssl_ca_file']
endThis essentially enabled two-way SSL communication (SSL client certs).
It doesn't look like GitLab natively supports it. https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/services/web_hook_service.rb#L74
The user was originally doing this via GitLab v7.14 (source CE install). They were changing the WebHook model. The corresponding file on a EE omnibus install would be /opt/gitlab/embedded/service/gitlab-rails/app/models/hooks/web_hook.rb. The code block was being placed after the include Sortable line.
The current version of their GitLab installation is 11.7 (EE omnibus).
This has broken several pretty important projects. We NEED this.
What authentication options do users have today
Users can pass a secret token in the HTTP header request to the webhook, which can then be used to verify the request is legitimate.
Comparable functionality in other products
- Pager Duty: https://developer.pagerduty.com/docs/webhooks/webhooks-mutual-tls/
- Google Dialog Flow: https://cloud.google.com/dialogflow/es/docs/fulfillment-mtls
- Tink: https://docs.tink.com/resources/api-setup/receive-webhook-events-using-mutual-tls-authentication
- Sparkpost: https://www.sparkpost.com/docs/tech-resources/webhook-authentication/
Intended users
unknown