Allow cloudshell to be created inside a VNET
It would be quite helpful to be able to SSH or PowerShell into systems that are only accessible from inside of the VNET. This would reduce the need for me to fire up my laptop if I just need to check on something quickly on a VM (I could just use the Azure app on my phone at that point).
I am a big fan of CloudShell. Using Cloudshell, I have created PS scripts to Encrypt a blob file using AWS Encryption SDK. Now i need to shift/copy the encrypted file to S3 Bucket. Without Public IP which is mandatory to be part of S3 IP Range Whitelist, i couldn't proceed, though i have Cloudshell that took care of all my scripting requirements. Is there a plan to assign a PublicIP to cloudshell? This would make life of azure automation using PS/Bash scripts. Any thoughts?
Cody Batt commented
I've deployed 3 VMs. The VMs are configured such that login is disallowed. They can be clustered together via a REST API. I thought I would just fire up the cloud shell and make the API request, but I can't reach the internal address on the vnet. Now I have to create a new VM in order to run a powershell command or expose my VMs to the internet. How frustrating when azure cloud shell is right there. I feel like Tantalus in Tartarus but I'm not sure what I did to deserve my punishment.
Leon Africa commented
Yes please - very handy to simplify troubleshooting.
Benjamin Mitchell commented
Another month and another "No Update".. How long is this going to be "Under Review"? Is this on the backlog or not?
maybe control this via vnet peer (so peer to cloudshell)
It is crazy that you expect us to expose resources to the public internet to use this tool.for management.
Ben Mitchell commented
Add me to the list of users that would LOVE this. Attaching cloud shell to VNET would let us manage our resources more securely and efficiently.
Handy for us too. Would like to mount a storage account with our command line tools for managing resources on our VNET, for our support staff etc.
We're looking at a managed bastion host as a service. Was hoping ACS would get us close, but it looks like all VMs still need PIPs and winrm open to Any (eeeek).
Jasper Siegmund commented
We had the same idea. To add to the scenario, we would also find it very useful to be able to do basic things like ping, trace route, DNS resolve, etc. etc. for debug-type scenarios where you would quickly want to see what the situation is for a specific component.
So what we imagine is that you could instantiate a shell within a specific resource group / vnet / subnet to execute these command within that environment. This would eliminate the need to spawn a VM, which our current way of doing this.