Since K3, the Kladde has reached every service through its public endpoint: Azure SQL, Key Vault, Service Bus, Blob Storage. That is not careless. Every connection is signed in with Entra ID, there are no passwords and no keys, and every identity has only the data roles it needs (lesson 4.8.5). The review from lesson 4.7.1 still noted a finding: SE:04, “Azure SQL and Key Vault reachable from the internet,” with the consequence “ADR.”
This lesson clarifies what a network of its own would do for the Kladde, what it costs and what it does not do. You describe the
network architecture in Bicep, check it with az bicep build and what-if, and decide in an ADR which services become private and which
do not. A deploy is optional: it creates a new environment and costs money for as long as it exists.
Where the Kladde is open today
| Component | reachable today | what protects it today | private possible |
|---|---|---|---|
| Container Apps environment | on Azure's network; Kladde.Web with a public ingress, worker without an ingress |
sign-in, antiforgery, rate limiting per visitor address | yes, with your own VNet; internal only with an entry point in front (Front Door Premium) |
| Azure SQL Database | public endpoint, firewall rules from K3 | Entra sign-in only, data roles | yes, private endpoint |
| Key Vault | public endpoint | Azure RBAC, role Key Vault Secrets User | yes, private endpoint |
| Service Bus (Standard) | public endpoint | Entra, roles Data Sender and Data Receiver | only in Premium: private endpoints and VNet rules |
| Blob Storage | public endpoint | Entra, role Storage Blob Data Contributor | yes, one private endpoint per subresource (blob) |
| Container Registry | public endpoint | pull with a managed identity | private endpoint only in Premium |
Two things stand out. First: not every service can become private in every tier, and the higher tier costs many times as much. Second: the environment itself cannot be placed in a VNet afterward. That is why this decision needs an ADR.