Description
When a Function App directly manages connection strings or access keys for other Azure resources, those credentials can be exposed or missed during replacement. Managed identity supports authentication to compatible services without a separate application secret. Its absence alone does not prove that secrets are used or exposed.
Potential impact
- Credentials stored in code or settings can be exposed.
- Credential replacement and revocation can be missed.
- Managing access permissions for individual functions can require more work.
Remediation
For supported connections, configure an appropriate SystemAssigned or UserAssigned ID in the identity block. Grant only the required target permissions and configure the function to actually use managed identity tokens. Verify operation before removing and revoking replaced secrets.
Examples
This legacy AzureRM 3.x azurerm_function_app example adds a system-assigned managed identity. Required storage settings, target permissions and token-using code are omitted.
Before
resource "azurerm_function_app" "example" {
name = "test-azure-functions"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
app_service_plan_id = azurerm_app_service_plan.example.id
}
After
resource "azurerm_function_app" "example" {
name = "test-azure-functions"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
app_service_plan_id = azurerm_app_service_plan.example.id
identity {
type = "SystemAssigned"
}
}
The after example attaches a SystemAssigned identity. This does not itself grant target permissions or automatically replace existing connection strings. Managed identity is also separate from authenticating callers of the function.