The app services in the title can be function apps, web apps or more. We can deploy the app services on the native app service environment provided by Microsoft or using containers.

What’s the different between using the native environment or using containers?

The differences aren’t many and it’s not easy to identify when it’s better to use the native environment or when its’s better to user containers.

There are two main differences we can identify:

• The cold startup time is better using the native environment than using a container
• We need to manage all the patches to a custom container, in the opposite to the native environment. Microsoft manages the patches to the native environment.

These doesn’t appear to be very critical decision points on most situations. But let’s dig further and add more variables.

Certificates and Containers

We can choose to use a Linux container or use a Windows container. There are some differences according to our choice. A few weeks ago, I stumbled upon one of the difference.

In some applications, we may need to insert a certificate inside the container.  WEBSITE_LOAD_CERTIFICATES is a special configuration we can use for this. This configuration makes the app service insert the certificate inside the container.

In windows containers, the app service installs the certificate inside the windows certificate storage and the certificate is recognized by the applications in the container.

On the other hand, if the container uses linux, the certificate is copied to one folder in a DER format. Most of the times the application will need to read the certificate from the file system and use it by code. This would require code change, usually this is not good.

These links contain explanations about this configuration and code to read the certificate from the file system in a Linux container:

https://docs.microsoft.com/en-us/azure/app-service/configure-ssl-certificate-in-code

https://stackoverflow.com/questions/55599001/azure-function-key-vault-reference-for-certificates

Security Scans

This happened to me some weeks ago. A security code scan tool started to complain about one dll: Microsoft.AspNetCore.Http.dll version 2.1.0.

You can find more about this issue on the following links:
https://github.com/dotnet/announcements/issues/165
https://nvd.nist.gov/vuln/detail/CVE-2020-1045#match-6013238

This assembly is a reference included in the package Microsoft.NET.Sdk.Functions . More than that, it’s part of the .NET Core Framework. How to solve a security problema like this?

It’s usual to find security problems with frameworks such as .NET Core. The framework is always evolving. You can check the framework versions and the security patches published on the following links:
https://dotnet.microsoft.com/en-us/download/dotnet/3.1
https://dotnet.microsoft.com/en-us/download/dotnet/6.0

The solution to the security problem is to update the .NET Core framework on the execution machine.

There are some details capable to make anyone confused. When the .NET project is compiled, the assemblies are inserted in the BIN folder. The version of the Microsoft.AspNetCore.Http.dll is the bad version, 2.1.0, even if the .NET Core framework on the machine is updated. How could this be possible?

We can even think further: if the assembly is in the BIN folder, this means a devOps pipeline would pack and deploy this assembly. How the update on the .NET Core framework would solve this?

The explanation is simple: Framework assemblies in the BIN folder are ignored, and the app uses the .NET Core assemblies.

Checking .NET Version in an App Service

App Services have the Advanced Tools. On the left menu, you under Developer Tools, you can click Advanced Tools and click the link Go on the page which will appear in the middle.

This will open an advanced development environment. On this environment, click  Debug Console on the top menu and choose a CMD console or Powershell console. Both can be used.

Once on the console, you can use one or both of the following statements:

dotnet –version

dotnet –list-runtimes

The first one will tell you the .NET version. You can use the .NET download pages (links above) to confirm your environment is up-to-date with the latest .NET version.

The 2nd one will tell you the exactly version of the main core libraries. The security report usualy will contain exactly the library versions you should have to be safe and you will be able to confirm you have them.

 

 

Security Scans Impact on App Service Containers

If you deploy your app service on the native environment, the app service will make updates to the .NET Core regularly. Microsoft deploys new fixes to the app service environment in 1 or 2 weeks after they are available.

However, if you deploy your app service as a container, it’s your responsibility to make updates to the container. You will be the responsible to create an automated flow in your devOps environment to identify new security features to the environment, update the container image and deploy it again regularly, avoiding down time.

Conclusion

Innitialy the requirement to manage the updates to the app service containers may appear a small difference, but when we check the security updates and the need to create an automated process to apply these security updates to the containers images we end up finding a very good reason to avoid deploying containers to app services and stick to the native environment.

If something changes later, it’s easy to deploy the application to a container when needed.