Security Enhancements - ja-guzzle/guzzle_docs GitHub Wiki

• Background
• Hardening of Guzzle VM on Azure

Guzzle follows a classic architecture of single page app + rest api for backend. This api can’t be compromised and the webserve we can move to app gateway or some other option (but node sever we use also solid) , but basically my third option is to further harden. Example network firewall rules, look at the node (with push state) and springboot and if there are any vulnerabilities

1. Guzzle VM to not have a public IP (as the recommended approach)

2. Various options to trigger Guzzle jobs without using the current rest API are (which in turn require us to expose Guzzle are):

   1. One is making all the orchestration and job invoking wrapper to be spark job (major change in architecture). This is then called by submitting the spark app from ADF or other scheudler
   2. Move the implementation of orchestration to azure function and that directly calls databricks and reads guzzle home for all the spark env details - you just pass azure function what you are passing to cli (infact move cli to azure function or some pass) so that vm does not get exposed / needs to be active
   3. Or let’s find a way to harden the vm - we can use app gateway etc.
   4. Using Cron or Guzzle scheduler and in that way not having any dependency on having inbound traffic in guzzle from any other Azure services

3. So UI and SSH access via bastion / fixed IP API access via app gw