Added Azure Functions - Ready For QA #51
Conversation
✅ Deploy Preview for confident-wilson-c4de9b ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
Modified content in terms of spelling and grammar to get a consistent structure with other pages.
|
|
||
| The advice below does not consider any vulnerabilities that have been introduced into Azure Functions by user supplied code. Instead, it will focus on secure configuration practices when deploying Azure Functions. Any code provided to a function should be assessed before deployment. | ||
|
|
||
| There are three Azure Function hosting plans, depending on which different security features are available: |
There was a problem hiding this comment.
We mention that its got 3 plans but we then show 5 plans.
|
|
||
| ## Assessment Notes | ||
| ### Networking Options | ||
| The available network isolation options will depend on which of the three hosting options offered was used when creating a function. For example the Consumption, Premium and App Service plans run on a multi-tenant infrastructure. Consumption plan has the least number of options for network isolation, whilst App Service and Premium provide more robust controls to restrict network access. |
There was a problem hiding this comment.
The ASEs should be fully dedicated also and not be running as a multi-tenant offering. So we need to be clearer on what we mean here when we say all 3 types of plans run on multi-tenant
| Hosting a function in an ASE, deploys the function on a single-tenant infrastructure and offers full network isolation such as deploying it in a personal VNet. The network isolation options available for the above mentioned plans are summarised in a table [here] (https://learn.microsoft.com/en-gb/azure/azure-functions/functions-networking-options?tabs=azure-cli). | ||
|
|
||
| #### Inbound Access Restrictions | ||
| This option, which is available for all hosting plans, allows users to define a list of IP addresses which are allowed or denied access to a function. When no entries have been defined, an implicit “deny all” is applied. |
There was a problem hiding this comment.
From memory the implicit deny as the last rule only exists once you've already added at least one IP rule. Otherwise with no rules being defined it sticks to an "allow all". Could we check that to make sure the operation is described correctly?
There was a problem hiding this comment.
When there are one or more entries, an implicit "deny all" exists at the end of the list. IP restrictions work with all function-hosting options.
| az functionapp vnet-integration list --name --resource-group | ||
| ``` | ||
|
|
||
| Once the VNet integration has been configured, the function will not by default have access to Azure resources. This would require a specific configuration following the change to ensure communication is possible with other internal resources. |
There was a problem hiding this comment.
On another review the original terminology wasn't clear on whether function apps by default when integrated do not have inbound or do not have outbound connectivity to other Azure resources in the VNet. I would assume they do have outbound default connectivity from function -> resource but inbound from resource -> function is not allowed and would vary due to the regional or gateway-required integration. Worth clarifying that bit.
| - Gateway-required VNet integration – when the function is connecting to VNets in different regions. | ||
|
|
||
| When reviewing Gateway-required VNet integrations, the following security features are important to keep in mind: | ||
| - If a VNet has got peering connections set up with other VNets or VPNs, the connection from the function App will be transitive, causing resources in additional networks to be reachable. |
There was a problem hiding this comment.
This is interesting can we share a bit more information regarding this on the transitive bits here? Are we saying that if network A is peered with B and B is peered with C that the function will be able to talk from A -> C? Cause normal peering isn't transitive by nature so this would be interesting if so.
|
|
||
| When reviewing Gateway-required VNet integrations, the following security features are important to keep in mind: | ||
| - If a VNet has got peering connections set up with other VNets or VPNs, the connection from the function App will be transitive, causing resources in additional networks to be reachable. | ||
| - Access to resources across Azure ExpressRoute or service endpoints is not enabled. |
There was a problem hiding this comment.
what do we mean by this? If I understand correctly gateway-required integration fundamentally can't be used if the VNet has an ExpressRoute gateway so this wouldn't be something we can review when looking at gateway-required integrations.
|
|
||
| Additionally, a “system-key” is used for webhook authentication required by different extensions used within a Function App. This system-key will be created by extension which will also determine whether it’s a host-level or function-level key. | ||
|
|
||
| As with other resources, relying on shared keys to access a resource is not an ideal scenario in terms of secrets management across an estate. Under the Authentication blade, it is possible to set up an authentication provider such as Azure AD which makes use of the tenant's authentication capabilities to restrict access to function endpoints. Further information can be found [here](https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization). |
There was a problem hiding this comment.
What about the usage of API Management to authenticate requests to the function app? Since that's also a suggested and valid way of handling auth to your functions.
| ### Logging and Monitoring | ||
| In the Overview blade, the Microsoft Defender for Cloud service will provide recommendations and security alerts in relation to a function that has been evaluated. This can be a quick source of common misconfigurations and provides alerts for certain possibly malicious activities that had occurred. However, a more in-depth approach to reviewing the security configuration should be taken especially when considering networking restrictions which often depend on the context of the broader platform which would require manual review. | ||
|
|
||
| Activity logs are a different source of telemetry for the resources that are enabled by default. All "/write" operations to Azure Functions resources will be logged, however this does not include "/read" operations. |
There was a problem hiding this comment.
Although a useful clarification on general Azure Monitor behaviour can we clarify what type of log sources are available for Function Apps in Azure Montiro. AKA what sort of resource logs you can collect as a whole.
|
|
||
| Activity logs are a different source of telemetry for the resources that are enabled by default. All "/write" operations to Azure Functions resources will be logged, however this does not include "/read" operations. | ||
|
|
||
| The Azure Application Insights service can be integrated with Azure Functions. Insights can provide more useful information on application logs, performance, and error data which can be used to detect performance anomalies. Application Insights are enabled by default but can be disabled. |
There was a problem hiding this comment.
Similarly for this, it would be useful to discuss a bit the relevant categories provided by app insights for functions that could be useful from a security perspective.
| ## Overview | ||
| Azure Functions is Microsoft’s cloud on-demand, serverless computing offering used for completing complex tasks via a collection of code written in a variety of programming or scripting languages. Azure Functions run code (also known as “functions”) that has been provided by the users, whilst Azure deploys and maintains the infrastructure to perform the tasks provided by the code. Every function has a trigger which can be time-based or manually run from an API call. Once triggered Azure will execute the code provided within the function. | ||
|
|
||
| Microsoft are responsible for provisioning and maintaining the underlying infrastructure that Azure Functions utilises. This includes practices such as separating resources from other customers, ensuring regular updates of common software and runtimes that deployed functions run on and handling communication with other Azure services such as Azure Storage or Azure SQL that are done over Azure’s network. |
There was a problem hiding this comment.
Can we add any additional available context on how functions are isolated? Is there any information in the documentation that can provide some info on how functions are handled when they go cold or while they're kept warm.
|
|
||
| As with other resources, relying on shared keys to access a resource is not an ideal scenario in terms of secrets management across an estate. Under the Authentication blade, it is possible to set up an authentication provider such as Azure AD which makes use of the tenant's authentication capabilities to restrict access to function endpoints. Further information can be found [here](https://learn.microsoft.com/en-us/azure/app-service/overview-authentication-authorization). | ||
|
|
||
| ### IAM |
There was a problem hiding this comment.
Can we add some extra detail on how usage of managed identities is done for function apps? So we can provide some information of what sort of activities a malicious user might attempt to do (e.g. try the metadata endpoint to get auth token, env variables and how they're used). Those sorts of bits would be valuable to be in their own subsection or added to the IAM page here.
Initial Azure Functions Page