[MGNLHOOK-173] Service to trigger 3rd party endpoints from SaaS instances Created: 15/Jul/22  Updated: 26/Aug/22  Resolved: 26/Jul/22

Status: Closed
Project: Magnolia Webhooks
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0.0

Type: Story Priority: Neutral
Reporter: Javier Benito Assignee: Javier Benito
Resolution: Done Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
relation
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLHOOK-187 ADR Documentation Task Completed Javier Benito  
MGNLHOOK-188 Review Sub-task Completed Jaroslav Simak  
Team: DeveloperX
Date of First Response:
Epic Link: Webhook on SaaS
Sprint: DevX 15
Story Points: 2

 Description   

As part of the DevX Webhooks Initiative, we need to make HTTP requests to third party endpoints from a SaaS instance.
SRE team detected that, allowing customers to configure any target endpoint could potentially lead to security problems, being a security breach in Magnolia SaaS infrastructure. So Magnolia itself can not perform those HTTP request to a 3rd party service.
 
So we need to make those HTTP requests from a different service (new).



 Comments   
Comment by Rubén Martín Romero [ 18/Jul/22 ]

Hi czimmermann! Below I try to summarize the security issues/concerns that we see related to this new webhooks feature if we implement it directly on magnolia instances side:

  • From the first pentest carried out by Compass we got from them the warning described in SRE-3300, so trying to fix/avoid this security risk, we were trying to control through some network rules applied to magnolia instances the outbound traffic/targets that are allowed to be requested from the Magnolia instances, since trying to control the inbound connectivity seems more challenging, as far as the Magnolia instances need to be publicly accessible: author instance for sure and public instance very likely for some operation that can not be performed going through the delivery Fastly CDN service. Even though the approach (outbound or inbound restrictions) is not decided yet, adding this webhooks service directly to Magnolia webapp would directly discard the outbound restriction approach/option, making it very difficult to isolate Magnolia instances at the network level if they need to be accessed publicly and also need to access any target because of the new webhooks feature.
  • Having the capability to call other services directly from Magnolia instances, which are deployed in the SaaS k8s cluster/platform, would allow to call any other internal/private service (not publicly accessible) directly from Magnolia, such as the endpoint /private of the Subscription service or the Config Ingestion service (not publicly accessible), so we would need to isolate all these private services in some way to disallow any request coming from Magnolia instances to any private service, which looks challenging since there are some other requests from Magnolia instances to those private services that are legit and expected. However having the feature in an dedicated and multi-tenant service, it is much easier to apply this kind of isolation, since we could for example add directly some egress/outbound network rule to it to avoid that the service can request any service whose IP is a private one belonging to the VPC in which the k8s cluster/platform is deployed.

You can get a better understanding of the network communications between the different services deployed in the SaaS platform reviewing the SaaS architecture diagram:

https://git.magnolia-cms.com/projects/CLOUD/repos/magnolia-cloud/browse

CC: chanh.hua, luong.nguyen (if you want to add some additional thought, feel free to do it)

Comment by Christopher Zimmermann [ 20/Jul/22 ]

rmartinr Thanks for the detailed explanation! Makes sense.

Generated at Mon Feb 12 10:01:46 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.