In module 3.3 you defused the Kladde key by key: SQL without a password, the signing key in Key Vault, redacted logs. At that time the Kladde ran in a subscription where a good deal was already in place. Some key was no longer needed only because a setting had been made in the portal that never made it into Bicep. In the empty subscription that shows: What isn't in the template is at its default value, and for most data services the default allows access with a key.
The goal of this lesson is in K3's outcome: not a single key in code, parameters, configuration or pipeline logs. And where it is possible, there is none at all, because the service no longer accepts one. The proof is a script that searches and finds nothing, and a counter-test that shows it would find something.
Where keys hide
| Service | Keys that exist | Switching off in Bicep | Replacement for the app identity |
|---|---|---|---|
| Azure SQL | SQL logins with a password, including the server administrator | administrators.azureADOnlyAuthentication: true |
database user for the identity (3.3.1) |
| Storage account | account keys, account SAS, service SAS | allowSharedKeyAccess: false |
Storage Blob Data Contributor; SAS only as a user delegation SAS (3.6.3) |
| Service Bus | SAS keys in connection strings | disableLocalAuth: true |
Azure Service Bus Data Sender and Data Receiver |
| Key Vault | access policies instead of roles | enableRbacAuthorization: true |
Key Vault Secrets User |
| Application Insights | ingestion only with a connection string | DisableLocalAuth: true |
Monitoring Metrics Publisher (3.4.2) |
| Container Registry | admin user with a password | adminUserEnabled: false |
AcrPull (in the foundation, 3.10.2) |
| Sign-in with Entra ID | client secret of the app registration | create no secret | federated credential for the app identity |
| Pipeline | client secret of a service connection | – | federated credential (3.10.2) |
Two things about the table matter. Switching off is something different from not using. As long as a storage account accepts account keys,
anyone with the role Contributor can retrieve the key (listKeys) and use it to access the data, past all roles.
And Application Insights' connection string is no longer a secret once ingestion requires an Entra token. It
then only shows where the telemetry goes.