Description
Containers in a Container Group can incur exposure risks and management overhead when they store access keys or client secrets for other Azure services. Managed identity lets Azure manage credentials for supported connections. Its absence does not necessarily mean static credentials are used; examine the actual authentication method.
Potential impact
- Long-lived credentials can be exposed in container environment variables or deployment state.
- Leaked credentials can be used to access other Azure resources within their permissions.
- Credential replacement and permission revocation can become more complex.
Remediation
Assign the required SystemAssigned or UserAssigned ID in the Container Group identity block. Set identity_ids for a user-assigned ID and grant minimal target permissions. Configure containers to use managed identity tokens, verify connectivity and revoke replaced secrets.
Examples
These examples add a system-assigned managed identity to the same Container Group. Configure referenced resources such as the subnet and target permissions separately.
Before
resource "azurerm_container_group" "example" {
name = "example-continst"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
ip_address_type = "Private"
subnet_ids = [azurerm_subnet.aci.id]
os_type = "Linux"
container {
name = "app"
image = "nginx:stable"
cpu = "0.5"
memory = "1.5"
}
}
After
resource "azurerm_container_group" "example" {
name = "example-continst"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
ip_address_type = "Private"
subnet_ids = [azurerm_subnet.aci.id]
os_type = "Linux"
identity {
type = "SystemAssigned"
}
container {
name = "app"
image = "nginx:stable"
cpu = "0.5"
memory = "1.5"
}
}
The after example configures a SystemAssigned identity. It does not automatically establish network paths or target permissions, so verify actual authentication and connectivity from the container.