T09 · Insecure Skill Coding Practices
Warning
- Location
- references/bicep-patterns.md:132
- Finding
- Long-Lived ACR Administrator Credentials Exposed to Container App Configuration<![CDATA[ ## Vulnerability Details **File Location**: `references/bicep-patterns.md`, lines 132-140 and 200-216 **Related Location**: `references/troubleshooting.md`, lines 38-45 **Vulnerability Type**: Insecure cloud credential management **Risk Level**: Medium ### Vulnerable Code ```bicep resource containerRegistry 'Microsoft.ContainerRegistry/registries@2023-07-01' = { name: replace('acr${name}', '-', '') // ACR names can't have hyphens location: location tags: tags sku: { name: 'Basic' } properties: { adminUserEnabled: true // Required for Container Apps pull } } ``` ```bicep registries: [ { server: containerRegistry.properties.loginServer username: containerRegistry.listCredentials().username passwordSecretRef: 'acr-password' } ] secrets: [ { name: 'acr-password' value: containerRegistry.listCredentials().passwords[0].value } ] ``` The troubleshooting guide reinforces the same pattern: ```bicep properties: { adminUserEnabled: true } ``` ### Technical Analysis The documented infrastructure enables the Azure Container Registry administrator account and retrieves its password through `listCredentials()`. The password is subsequently copied into the Container App's secret configuration. The ACR administrator account is a long-lived, registry-wide credential rather than an identity scoped to the workload. It commonly provides both image pull and image push capabilities. This violates least-privilege principles because the Container App only needs permission to pull images. The pattern also contradicts the project's managed-identity guidance. Although the Container App has a system-assigned identity, the vulnerable module does not use that identity for registry authentication and instead introduces a reusable password. An attacker must first obtain permission to read the Container App secrets, invoke ACR credential-listing operations, or otherwise access deployment outputs containing the credential. The ...[truncated 1575 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Disable the ACR administrator account: ```bicep properties: { adminUserEnabled: false } ``` 2. Configure the Container App to authenticate with its system-assigned managed identity: ```bicep configuration: { registries: [ { server: containerRegistry.properties.loginServer identity: 'system' } ] } ``` 3. Grant only the `AcrPull` role to the Container App identity at the registry scope. Create the role assignment declaratively in Bicep where practical. 4. Remove all calls to `containerRegistry.listCredentials()` and remove the `acr-password` secret from Container App configuration. 5. Rotate both ACR administrator passwords after migrating existing deployments, then keep administrator access disabled. 6. Review Azure activity logs and ACR repository activity for unexpected credential-listing operations, image pushes, tag replacement, or manifest changes. 7. Update `references/troubleshooting.md` so authorization failures are resolved through managed-identity role assignments rather than by enabling administrator credentials. ]]>