Azure Private Proxy Automation is needed

The purpose of this issue is two-fold. First, we want to write down the need to automate this process as part of our CLI deployment process. Second, we want to document how to do the process manually until we can do this in code.

Steps:

1. Run the persistent step in the Azure Workload steps. This will provision a BastionHost, its subnet and required adjacent resources.

2. Run the clusters step in the Azure Workload steps. This will configure access between the BastionHost Subnet and the Private Subnet in which the JumpBox will exist and where the AKS cluster API lives.

3. Go to the Azure Portal (click-ops! yay!). You are going to go to Create Resource > Compute > Virtual Machine > Create.

   a. Basics: Corresponding subscription, resource group, appropriate VM name, Azure-selected zone, Trusted launch virtual machines, Image: Ubuntu Server 24.04 LTS, VM arch: x64, Size: Standard_B1ms, Authentication type: SSH public key, Username: ptd-admin, Generate a new SSH key, RSA SSH format, No public inbound ports
   b. Disks: Don't change anything about the disk provided (30GB)
   c. Networking: The only vnet that should be part of the subscription, choose the private subnet, no public IP, Basic NIC NSG, no public inbound ports, delete NIC when VM is deleted
   d. Management: Login with Microsoft Entra ID check
   e. Go to Review + Create; don't change the phone number to yours
   f. This will prompt you to download a private key, download the key and upload it to our Team vault in 1Password. Share the name of the secret in #ptd-backstage so we all know what it is. (suggestions welcome on how to improve this)
   You may also need to run chmod 400 file_name locally before using it.

4. Once the JumpBox has been created (see step 3), you are going to go to Virtual Machines in your Azure Portal; click on the JumpBox instance, then go to Settings > Properties and scroll all the way down to Resource ID, you are going to need this value, note it down.

5. Azure Portal > Bastions: Copy the name of the BastionHost

6. Go to the AKS Networking tab and add the JumpBox Private IP address followed by a /32 mask to allow traffic from the instance to the cluster. (Not required for private clusters.)

7. Open a new terminal, run az login and set up with the corresponding Azure subscription of the workload cluster

8. You are going to need 3 terminal windows to configure this.
   a. First terminal: az network bastion tunnel --name $BASTION_HOST --resource-group $RG_NAME --target-resource-id $JUMPBOX_RESOURCE_ID --resource-port 22 --port 22001
   b. Second terminal: ssh -ND 1080 ptd-admin@localhost -p 22001 -i <path-to-pem-file from step 3.f.>
   (This will hang, open third terminal for the next command.)
   c. Third terminal: curl -v --socks5 localhost:1080 https://<K8S-API>:443 -k
   (On Overview tab of Kubernetes cluster in the portal.)

9. Log into AWS, change kube context to the Control Room of the workload before running CLI

The third terminal is to confirm that the proxy is properly working, you can then use this one to run ptd ensure

Start by reviewing the Azure Workload persistent and clusters steps and the existing CLI deployment flow; no repository files or tests are named. The work is done when the manual private-proxy procedure is documented and the required Bastion, JumpBox, AKS access, and proxy validation steps are automated for ptd ensure.