Conversation
…stem Previously, the bastion SSH key was written to ~/.ssh/ during `pulumi up` via a local command, which only worked for the engineer who ran the initial deployment. Other engineers would fail to connect because the key wasn't on their machine. Now the SSH key is exported as a Pulumi stack output and fetched on demand when starting a proxy session. The key is written to a temp file and cleaned up when the proxy stops. Additional changes: - Consolidate BastionName/JumpBoxId into single BastionInfo lookup - Export PTD_ROOT in workon shell for manual pulumi commands - Remove local.run_output that wrote SSH key to ~/.ssh/
| "app_gateway_subnet_id": self.app_gateway_subnet.id, | ||
| "bastion_name": self.bastion.bastion_host.name, | ||
| "bastion_jumpbox_id": self.bastion.jumpbox_host.id, | ||
| "bastion_ssh_private_key": self.bastion.jumpbox_ssh_key.private_key_openssh, |
There was a problem hiding this comment.
I think this needs to be explicitly marked as a secret if we're going to put it in the output?
This probably makes more sense to fetch from azure secret vault, right?
There was a problem hiding this comment.
The resource output is marked as secret, so our own output inherits that (meaning, it's a secret already):
There was a problem hiding this comment.
I used pulumi state as an intermediary since we don't have a comprehensive Azure Secrets solution yet. But honestly, I'm not sure what advantage we even gain from using Azure Secrets here. What I care about most: 1) least surprise: no one should run into an error or have to debug (like we have been if you hadn't run persistent on your local machine for a particular workload) and 2) secrets need to be stored securely (which they are here). 🤷 I could be convinced otherwise, but this honestly feels like a reasonable long-term solution, too.
There was a problem hiding this comment.
no you're spot on as long as we're encrypting it.
2 participants
Description
The Azure bastion SSH key was previously written to
~/.ssh/duringpulumi upvia alocal.run_outputcommand. This only worked for the engineer who ran the initial deployment — other engineers couldn't connect because the key wasn't on their machine.This PR exports the SSH key as a Pulumi stack output and fetches it on demand when starting a proxy session.
Code Flow
bastion_ssh_private_key) from the persistent stack viaazure_workload_persistent.py.target.go):BastionName()andJumpBoxId()are consolidated into a singleBastionInfo()method that fetches all bastion connection details (name, jumpbox ID, SSH key) from the persistent stack in one lookup.proxy.go): When starting a proxy session, the SSH key is written to a temp file viaos.CreateTemp, used for the SSH SOCKS connection, and cleaned up inStop().workon.go):PTD_ROOTis now exported to theworkonshell environment so thatpulumicommands work correctly within the shell.Rollout
The
bastion_ssh_private_keyoutput must be registered viapulumi upon the persistent stack for each Azure workload before deploying the new binary. I will runensureon all Azure workloads so the new stack output is in place for everyone before merging.Category of change