However, there is one issue when it comes to Cloud Shell, it is an issue that I see “glossed over” in way too many environments, and that is how to run this for real , in an actual environment that is governed by processes.
Cloud Shell allows you to do many nice things, like uploading files to a drive, it remembers your shell history, editing files, creating a PowerShell profile, etc. All of that though requires some sort of storage.
If you are not aware, when you access the Cloud Shell for the first time Azure will ask you to create this storage in the form of an Azure Storage Account and an Azure File Share, obviously this needs to be deployed into a Resource Group.
This immediately presents the following issues:
Those are a lot of questions for a regular user to find answers to. So what do we do to make sure we do not end up in a total mess of resources all over the place once we have more than one user using the Cloud Shell like in this image here where no convention was followed and resources are spread across multiple locations? (this is with only two users already)
We have a few options here to counter the mess mentioned above.
I recommend my customers to follow this simple automated process which is usually implemented via an Azure DevOps pipeline or even a small Azure Function called from ServiceNow or a LogicApp for example.
Now, when a user logs in to Azure and tries to open up Cloud Shell they just need to select the right resources that have been deployed for them.
Hot tip: Reuse the Storage Account! Just create new File Shares for new users. There is no limit on the number of File Shares in a Storage Account.
Until we are able to actually connect a user account to a Cloud Shell without user interaction following this process should keep your environment tidy.
How do you manage all your Cloud Shells?