Skip to content

Accessing the kudu service

Suwat Ch edited this page Jul 15, 2021 · 16 revisions
Clone this wiki locally


Every Azure web site has an associated 'scm' service site, which runs both Kudu and other Site Extensions.

If your web site has URL, then the root URL of the Kudu service is Note the added scm token.

For mobile services, the site URL looks like, and the Kudu root URL is

Notes: The scm service host name is not affected by the presence of custom host names in your site. It always has the pattern above.

Authentication / Authorization

The scm service requires authentication and authorization.


There are 2 authentication mechanisms.

  • Single sign on. This is only available and a default mechanism accessing via browser. User will be authenticated via AAD login.
  • Basic Auth using Deployment-credentials. This is default for non browser - such as curl. However, one can force this mode on browser by appending basicauth such as


The authenticated user will be authorized using Role Based Access Check (RBAC). For site-level credential ($sitename), RBAC is not applicable; instead, it must be associated with the site being accessed.

Once you're in the Kudu service

The root of the Kudu service has links to various things that can be done from there, and are discussed elsewhere in this wiki. e.g., you can:

  • Get the Kudu diagnostic dump
  • Launch the diagnostic console
  • See info about the runtime environment
  • Navigate the REST API


Ones with Kudu access are ones owning the site - regardless if read-only or not. To expand, they can deploy any codes (good or malicious) to and able to read any secret settings of the site (eg. KeyVault, SQL and Storage credentials, Private Certificates, etc.). Hence for Azure, only those with Contributor / Owner access (to be exact, with microsoft.web/sites/publish/action or, for slot, microsoft.web/sites/slots/publish/action) can access to Kudu (SCM).