In order for webhooks to work appropriately, the /flexdeploy/webhooks/v1 resource needs to be available for the system sending the webhook. This often means the endpoint needs to be publicly available which poses its own problems and security concerns which this document aims to address.
| Info | |
|---|---|
| title | WarningBefore configuring any security or tunneling for webhooks, your security team should be engaged and approve the process. |
| Table of Contents |
|---|
Allowing webhooks into your FlexDeploy application
...
https://abc123.ngrok.io/flexdeploy/webhooks/v1/git/push
| Info |
|---|
CautionThe approach outlined above is only intended to demonstrate the process and how to get up and running. What the above approach results in is opening port 8000 of the machine publicly, meaning anyone can access your FlexDeploy application by navigating to https://abc123.ngrok.io/flexdeploy. See the security concerns section below for ways to address this. |
...
Once we have some reverse proxy forwarding our webhooks to FlexDeploy, we need to ensure that no malicious requests are being forwarded from the reverse proxy. This can be accomplished a number of different ways as highlighted below:
Method | Description | Pros | Cons |
|---|---|---|---|
IP Whitelisting | Denies any request from an IP address that is not included in the IP whitelist. | Arguably the most secure | In today's cloud and serverless world, the amount of IP addresses and ranges can be endless. For example, Slack webhooks originate from AWS which has 1000s of possible IP addresses. |
Tokens | Passing some token (generally as a query param) in webhook urls. The reverse proxy then denies any request without this token. | Not restricted by IP | Token is visible in webhook urls |
Resource Matching | Ensuring that your reverse proxy only forwards requests for certain resources. For example /flexdeploy/webhooks/v1. This denies any request to the base flexdeploy application through the proxy but allows requests to the webhook resource. | Not restricted by IP Not maintaining a token | Allows all requests through the proxy as long as the resource is /flexdeploy/webhooks/v1 Puts more ownership on the Provider Match script to determine malicious intent. |
Hmac Encryption | A number of webhook providers (GitHub, Slack, Bitbucket Server) will encrypt the payload with a secret that you provide and pass the encrypted string as a header. When receiving the request you then encrypt the payload with the same secret and validate it matches the header that was passed from the provider. This is a more secure version of the Token approach above but not offered by all providers. | Second most secure behind IP whitelisting | Not offered by all providers |
The approach used is ultimately decided by you. Having said that, if the dynamic IPs are not an issue for your team, then IP whitelisting should definitely be included. Experiment with any combination of the above and see what works for your organization.
...