We have reached out to microsoft azure support and gotten back the following response:
"The temp usage we are seeing is to be expected as it is taken up by blessed images used by the app service in other configurations (these are said to take up 23gb of storage)."
Our solution was to redirect logs to stderr and decrease their verbosity (our application would log detailed http requests and responses for third party services), thus moving log management to azure (we set it to 100mb or 60 days retention).
One other feature that can take up space here is application insights - application dumps are stored there.
There is no way to clear the storage used for blessed images (if, like us you are using a custom container and do not need them) - it's just a part of the app service.
There is no way to access this storage area under linux (tutorials suggest it should be possible under windows by accessing D:\temp after setting the WEBSITE_DISABLE_SCM_SEPARATION flag).
The flag WEBSITE_DISABLE_SCM_SEPARATION does nothing under linux (there are reports of it actually crashing the container, though I cannot confirm that - it just does nothing).
Overall Kudu for linux webapps appears to be slightly different to the windows versions and some tutorials/documentation do not apply.
The size of the app service storage is a bit misleading when using a docker container, what they actually run on is temp storage.
The actual size is related to these and is described here (if there is a suggestion box anywhere, I would ask that the pricing tables be updated to include these values - finding them is not easy)
In order to get access to the 250gb storage area you MUST use shared storage if you are using containers. You can do this by setting the flag WEBSITES_ENABLE_APP_SERVICE_STORAGE to true in the configuration blade of your app service. This storage is always mounted under /home (owned by nobody.nogroup - uid.guid is 65534.65534), and will contain a folder structure described here.
If you want your app to use this storage, be very mindful of Path Traversal vulnerabilities - if you are using a framework your app should be fine, but if you are rolling your own file access (or are accessing it directly) make sure you don't expose yourself to this vulnerability.
If your container uses isolation techniques (chroot, SELinux, open_basedir), you will need to work around this -
mount --bind perhaps, you will need to work within the pre-defined folder structure and manage permissions inside the container. Also prepare to build a default /home to fallback on when running the container locally.