Blocking ux.console.azure.com seems to work fine for Cloud Shell in a browser, but Cloud Shell via Windows Terminal (v1.11.2921.0) still works.

[BhargaviAnnadevara]

Blocking ux.console.azure.com seems to work fine for Cloud Shell in a browser, but Cloud Shell via Windows Terminal (v1.11.2921.0) still works.

How do we block Cloud Shell access via Windows Terminal?

Originally posted by @dsmithcloud in https://github.com/MicrosoftDocs/azure-docs/issues/55489#issuecomment-972067811, and in microsoft/terminal#11775

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @maertendMSFT.

Issue Details

---

Blocking ux.console.azure.com seems to work fine for Cloud Shell in a browser, but Cloud Shell via Windows Terminal (v1.11.2921.0) still works.

How do we block Cloud Shell access via Windows Terminal?

Originally posted by @dsmithcloud in https://github.com/MicrosoftDocs/azure-docs/issues/55489#issuecomment-972067811, and in microsoft/terminal#11775

Author:	BhargaviAnnadevara-MSFT
Assignees:	-
Labels:	Service Attention, Cloud Shell, needs-triage
Milestone:	-

[yonzhan]

route to CloudShell team

[ShachafGoldstein]

According to this and some tests - both portal and terminal use some api that redirects to endpoints of the form https://<Gateway>.<REGION>.console.azure.com so seems like blocking *.console.azure.com can help block all methods.

[timwebster9]

Blocking CloudShell using network controls isn't really a good solution, although understandably people are doing this because it seems like the only option. There should be an easier way to enable this for privileged users, and disable for everyone else.

Controlling access to storage isn't a good option either. We need developers to be able to work with storage for their applications.

Deploying it into a virtual network also isn't ideal. That will need to either be centrally managed, or loads of controls put in because it involves enabling ACI. Containers may or may not be an 'approved' technology with some customers.

It's a security / DLP risk. Ideally it should be controlled via RBAC or at the tenant level (e.g. enable/disable Cloud Shell in Azure AD). Can we please have some proper controls for this?

[jdelabr]

I agree with @timwebster9, there should be an admin setting to allow cloudshell governance: allow/deny based on RBAC or resource provider, and ability to provision cloudshell in a compliant way (i.e. integrated in VNet). Azure policy should also be able to monitor that or at least Security team should be able to get a report or build one using APIs.

[GeraldGoldstein]

cloud shell provider should be controlling this, the advice via enterprise scale/msft consulting is front line control is providers, then use RBAC. cloud shell blocking seem to be a complete after thought.

The other way to handle this is to have the ability to choose the compute region. 99% of all customers want to block cloudhsell because there is no control of where the compute is located, if we had the ability to provision compute in the "approved" regions then we wouldn't need to disable the service.

normally we control the regions via policy, so this control would apply to cloudshell, so that only the regions we whitelist can be selected to deploy the compute. its about time this was fixed, it has been a problem for years now.

[mbifeld]

Thank you all for the feedback. We are starting work towards more granular controls of choosing compute region and giving customers RBAC controls for Cloud Shell. Unfortunately, no ETA yet on this work.

Today, you can file a support ticket to block Cloud Shell at the tenant level, and Cloud Shell team will manually set up a block for your tenant which will work across all Cloud Shell environments, including Windows Terminal. This is the only solution today. Closing this issue as the original issue was regarding blocking controls for all Cloud Shell environments. Please provide further feedback / requests at https://github.com/Azure/CloudShell/discussions