A customer recently asked me how Azure Pack websites are isolated and how one website is prevented from interfering with another website running on the same worker. Microsoft don’t really document this anywhere, so I had to do a bit of digging.
The first part of the answer actually comes from the screenshot I had in an earlier post about where the websites actually are.
When you look at task manager and look at the user running the w3wp process for your site, you’ll see a user corresponding to the name of the site. However, if you look in the local user database you won’t find any users with those names. The websites are running using “virtual accounts” which were introduced in Windows Server 2008 R2 and are documented here. They are part of the same set of technology as Managed Service Accounts, but probably less well known.
You can configure an IIS website to use a virtual account by setting the identity of the application pool to “ApplicationPoolIdentity”. As we saw in the “where are my websites?” post, you don’t get to see an Azure Pack website in IIS, but if you look in the ApplicationHostConfig file for the website you’ll see the entry below, showing that the Azure Pack website is using ApplicationPoolIdentity.
<add name=”website1″ managedRuntimeVersion=”v4.0″>
<processModel identityType=”ApplicationPoolIdentity” />
A plan that include the web sites service has a set of quotas assigned to it, which can be customised for each web site mode (Intro shared, Basic shared, Reserved). The quota limit for memory is implemented as a Win32 job limit, which you can view using Process Explorer. If you get the properties of one of the website w3wp.exe instances, you can see the properties on the job page. The quota limit for memory can be seen in the Max Working Set property, and if you change an instance to a mode with a different quota you’ll see this change reflected once the process has been restarted in the new mode.
The CPU & network quotas are tracked by the “Resource Metering” service, and this information is sent to the controller, which is actually responsible for enforcing any quota. The default action is to do nothing when quota is exceeded but if you’ve chosen to stop the site, the controller will take care of this.
The next level of isolation and protection is the application of quotas through FSRM on the workers. On a worker running instances of websites you can run the PowerShell cmdlet “get-fsrmquota”, and this will show you something like the below
Disabled : False
MatchesTemplate : True
Path : C:\inetpub\temp\DWASFiles\Sites\website2
PeakUsage : 361472
Size : 209715200
SoftLimit : False
Template : DynamicWasTempQuota
Usage : 361472
This shows that each website is limited to consume 200MB of disk space on the worker, and that is a hard limit (soft limit = False). So a runaway or malicious process on a worker could only ever get an individual website instance to use 200MB of disk space. As you can also see, this is created from a template called “DynamicWasTempQuota” which is created by Azure Pack (you can have a look at this using get-fsrmquotatemplate).
If you’re using a Windows file server for the web sites feature you can also explore the limits that are applied at the file server that correspond to the “Subscription Storage Space” value in the plan quota (the size value below corresponding to a 1GB hard limit):
Disabled : False
MatchesTemplate : False
Path : C:\WebSites\c9d2cf1a9d6b00b7d177\1f68e081ae3c489cbd98cdffcf86de1d
PeakUsage : 74752
Size : 1125899906842624
SoftLimit : False
Usage : 74752
The last piece of the security and isolation provided in Windows Azure Pack websites is an IP filtering function (as documented here) that is used to prevent the service from launching a denial of service against itself. This is implemented using a custom filter driver called RsFilter that is deployed as part of WAP on workers. You can see the filter loaded if you run ftlmc on a worker, and if you look in the registry you can see the entries for the IP filtering at HKLM:\System\CurrentControlSet\Services\RsFilter
Compare the block list configured in the portal:
that is then transfered to the workers registry:
That’s as much information as I’ve been able to find about the security and isolation model, hopefully that comes in handy for someone.