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 | ||
|---|---|---|
| ||
Before 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
...
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 todays cloud and serverless world the amount of IP addresses and ranges can be endless. |
Viewing Messages
The table on the left side of the screen shows all webhooks received within the last week. Messages are purged automatically after 7 days.
...
Viewing Message Details
Click on any webhook message row in the table to view more details about an individual message. This will show more detail about the execution, including any webhook functions which were executed from this trigger and their statuses, as well as more context about the incoming webhook, including query parameters, headers, and additional properties. More information on the execution can be viewed by clicking . This will show any log messages printed in function scripts using the LOG methods. Click
to view the entire JSON POST payload as received from the provider. You can also submit an incoming webhook message for execution again with the
button. Keep in mind this is only meant to be used for debugging purposes.
Log Messages
Some logs are printed automatically during execution, but most are printed by using the LOG (link??) methods in the provider match and function scripts. By default, the logging level will be based on the global FlexDeploy logging level. This can be modified specifically for webhook logs by setting the logging level for flexagon.fd.services.webhooks.functions.LogFunctions in Admin → Admin Operations.
...
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.