How can I use this in Azure Container Instances?

[goldjg]

I am clearly missing something. I am trying to run this container in ACI but although it deployed successfully, I never get a functional shell, either in the Connect view in the portal or by browsing to the public dns name.

Why do I want to do this? Cloud shell represents a security risk in my org and I’d like to be able to block cloud shell in the portal and have people use a private version that we host in our tenant. That way we can restrict outbound internet access, ensure we have data leakage protection, mount one of our repos for tools and an azure file share for output.

[edyoung]

I'm afraid this repository doesn't provide everything you need for the full Cloud Shell experience, and we don't provide a full 'roll your own cloud shell' offering.

This is just the set of client tools that are in Cloud Shell. The missing parts are a web based terminal (the one in the Azure portal is based on xterm.js), a system to provision the container on demand (this is the resource provider in Azure Cloud Shell) and some code in the container to start the actual shell process and connect it to the terminal via websocket.

I'm afraid there's no near-term likelihood of our open-sourcing all those components. They're fairly complex and special-purpose and tied into other Azure systems so wouldn't be easily reusable. Rolling your own is a moderately complex exercise but not impossible.

If you need to block Cloud Shell for your tenant, you can create a support ticket to do so. You might also want to look at https://docs.microsoft.com/en-us/azure/cloud-shell/private-vnet to see if that helps with your security concerns.

[goldjg]

Thanks for the quick reply and the additional info - makes sense now. I’d seen a tech community article on running it locally but what I’d missed is that is just using docker pull and docker run and so you get a shell when you do that.

I’ll rethink my approach with this in mind.

My primary concerns with cloud shell in the portal are:

• The cloud shell has direct internet access which bypasses IDS/IPS/DLP and corporate proxies.
• Malware can either be side-loaded through the internet or via the external persisted storage with the use
• There’s no logs of the local actions, no logs of the internet egress and no antivirus etc
• Compromise of the storage account used by the shell could lead to privilege escalation via environment variable manipulation or cached credential extraction.

The ASB helps with some of these concerns but not malware and data leakage.

[goldjg]

Private vnet option is useful, though there is still the issue of cached credentials left kicking around on the storage account. Ideally the session would be ephemeral with no residual credentials, logs, files etc when you close the session or it times out. Anything that needed to persist should be in in an azure file share or blob mounted in the shell on initiation or via a connected private repo in ADO or GitHub for example.