From 62c4d451f5d6f5d6097692b5fb64e7d887168338 Mon Sep 17 00:00:00 2001 From: Dalibor Kovacevic <56942801+RobiladK@users.noreply.github.com> Date: Fri, 24 Jul 2026 09:48:00 -0700 Subject: [PATCH] Update SRE Agent VNet subnet examples to /28 Update deployment defaults and VNet integration samples to use the current /28 minimum while retaining unrelated gateway and private-endpoint subnet sizes. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- labs/zava-aks-postgres/AGENTS.md | 2 +- labs/zava-aks-postgres/README.md | 2 +- labs/zava-aks-postgres/infra/main.json | 20 ++++++++-------- .../infra/modules/vnet.bicep | 24 +++++++++---------- .../knowledge-base/zava-architecture.md | 2 +- sreagent-templates/bicep/assemble-agent.sh | 2 +- sreagent-templates/bin/deploy.sh | 2 +- sreagent-templates/bin/ps/Deploy-Agent.ps1 | 2 +- .../vnet-integrated-keyvault/README.md | 2 +- .../terraform.tfvars.example | 2 +- .../vnet-integrated-keyvault/variables.tf | 2 +- 11 files changed, 31 insertions(+), 31 deletions(-) diff --git a/labs/zava-aks-postgres/AGENTS.md b/labs/zava-aks-postgres/AGENTS.md index 28126ab1d..b904520b7 100644 --- a/labs/zava-aks-postgres/AGENTS.md +++ b/labs/zava-aks-postgres/AGENTS.md @@ -41,7 +41,7 @@ These are gotchas for someone editing this repo's IaC or Bicep — they're *not* - **Scenario 2 NetworkPolicy is named `database-tier-isolation`, not `block-postgres`.** This is deliberate de-spoon-feeding: the old name let the agent reach the diagnosis purely from string-matching. The new name reads like a security-architect zero-trust attempt that accidentally over-blocks; the agent has to read the egress rules and reason about the destination subnet to find it. - **NSG deny rule installed by `break-network.ps1` is a red herring, not a "breadcrumb".** PG Flexible Server private access uses a delegated subnet whose routing/policy is platform-managed (see [subnet-delegation-overview](https://learn.microsoft.com/azure/virtual-network/subnet-delegation-overview) and [PG private networking](https://learn.microsoft.com/azure/postgresql/network/concepts-networking-private)), so a user-added NSG rule on 5432 looks like the smoking gun in config but isn't the active enforcement point. The agent is expected to cross-reference the KB and discount it. Don't reintroduce framing that calls it a "cosmetic clue" — that telegraphs the answer. - **No `SendOutlookEmail` tool wired into the skills.** Email-out requires an OAuth consent flow that has to be completed by an interactive user in the agent's portal — there is no Bicep/ARM verb to provision it on the agent's behalf. Adding it to `skill.tools[]` without that consent makes the skill *fail to load*. If you want post-remediation email for your own deployment, follow the public docs ([Microsoft 365 connector for SRE Agent](https://learn.microsoft.com/azure/sre-agent/)) to grant consent in the portal, then re-add `'SendOutlookEmail'` to the relevant skill's `tools` array and a "send a summary email" line to the runbook. -- **The network is hub-and-spoke (three VNets), not one flat VNet.** `vnet.bicep` deploys a **hub** (`vnet-Zava-hub-*`, 10.10.0.0/22 — `AzureFirewallSubnet` + the Azure Firewall, a reserved `GatewaySubnet` for a future ExpressRoute/VPN gateway, and `pe-subnet` for the AMPLS private endpoint), a **platform spoke** (`vnet-Zava-platform-*`, 10.20.0.0/16 — `aks-subnet` + delegated `db-subnet`), and an **agent spoke** (`vnet-Zava-agent-*`, 10.30.0.0/24 — the delegated `agent-subnet`). The firewall lives in the **hub**; the agent subnet force-tunnels to it via a UDR (`0.0.0.0/0` → firewall private IP `10.10.0.4`) over VNet peering, and the firewall policy's `sourceAddresses` is the agent subnet (`10.30.0.0/27`) — update both if you renumber. This is safe because the agent reaches AKS via native `kubectl` over the private API-server path and PG through the in-cluster helper, never raw DB sockets, so it never needed to share a VNet with them. Consequence for scripts: anything that picks "the VNet" must select the one containing its target subnet — `break-network.ps1` now queries `[?subnets[?name=='aks-subnet']]`, not `[0]`. +- **The network is hub-and-spoke (three VNets), not one flat VNet.** `vnet.bicep` deploys a **hub** (`vnet-Zava-hub-*`, 10.10.0.0/22 — `AzureFirewallSubnet` + the Azure Firewall, a reserved `GatewaySubnet` for a future ExpressRoute/VPN gateway, and `pe-subnet` for the AMPLS private endpoint), a **platform spoke** (`vnet-Zava-platform-*`, 10.20.0.0/16 — `aks-subnet` + delegated `db-subnet`), and an **agent spoke** (`vnet-Zava-agent-*`, 10.30.0.0/24 — the delegated `agent-subnet`). The firewall lives in the **hub**; the agent subnet force-tunnels to it via a UDR (`0.0.0.0/0` → firewall private IP `10.10.0.4`) over VNet peering, and the firewall policy's `sourceAddresses` is the agent subnet (`10.30.0.0/28`) — update both if you renumber. This is safe because the agent reaches AKS via native `kubectl` over the private API-server path and PG through the in-cluster helper, never raw DB sockets, so it never needed to share a VNet with them. Consequence for scripts: anything that picks "the VNet" must select the one containing its target subnet — `break-network.ps1` now queries `[?subnets[?name=='aks-subnet']]`, not `[0]`. - **Agent VNet injection is REGIONAL; cross-region reach is via PEERING.** The `agent-subnet` (delegated to `Microsoft.App/environments`) **must be in the same region as the `Microsoft.App/agents` resource** — VNet injection is regional, not a tuning knob ([SRE Agent subnet requirements](https://learn.microsoft.com/azure/sre-agent/network-integration#configure-azure-vnet-mode): *"The subnet must be in the same region as your SRE Agent resource"*). A single-region `azd up` satisfies this automatically — `vnet.bicep` deploys all three VNets and `sre-agent.bicep` deploys the agent with the same `location: location`; don't move the agent subnet to another region expecting injection to work. The agent's **reach is NOT regional**, though: peered to the hub, it routes to anything the hub peers to — **other Azure regions over global VNet peering**, **on-prem over the reserved `GatewaySubnet` gateway** (*"as long as your network routes and rules allow it"*). The on-prem example is just one instance of this. `vnet.bicep` ships a **commented `remote-region` global-peering example** (after the local peerings) and the README's *"Reaching other regions and on-premises"* section is the narrative. Because the agent is force-tunneled to the hub firewall, reaching a new peered range also needs a firewall network rule (`agent-subnet → that range`), not just the peering. - **Native kubectl requires the AKS private-DNS link, and that link is now codified.** `vnet.bicep` already adds the agent-subnet → AKS API :443 firewall rule and SNAT. The remaining requirement is linking the AKS-managed private-DNS zone (`.privatelink..azmk8s.io`, created in the node resource group after cluster creation) to the agent VNet. That zone name is dynamic, so it cannot be a static Bicep resource; `scripts/post-provision.ps1` **Step 4b** now discovers the node RG, azmk8s.io zone, and agent VNet, then idempotently creates the `agent-link` virtual-network link on every deploy. Before this was codified, fresh deploys could spend minutes floundering on private AKS DNS before falling back/proceeding. - **The Microsoft Learn MCP connector routes entirely through the hub Azure Firewall (no platform bypass) — `raw.githubusercontent.com` must be allow-listed or it silently surfaces zero tools.** The `microsoft-learn` connector is a *Streamable-HTTP* MCP server (`endpoint: https://learn.microsoft.com/api/mcp`). We keep **`allowHttpMcpServerNetworkAccess: false`** (the default) on purpose: when `true`, the platform routes the MCP runtime endpoint as `Rewrite{RoutingMode=Platform}` — a broker that egresses *outside* the customer VNet, bypassing our firewall (an egress escape hatch that contradicts the lab's "every connection gated by our firewall" thesis; empirically, with it on, the MCP runtime to `learn.microsoft.com` never appears in our `AZFWApplicationRule` logs). With it `false`, the MCP host falls under AzureVNet's **default-Allow** and egresses via the VNet → forced-tunnel → hub Azure Firewall. So both the in-sandbox `mcp-broker`'s **server-bits fetch from `raw.githubusercontent.com`** (the `microsoftdocs/mcp` repo, during the `tools/list` handshake) AND the **runtime stream to `learn.microsoft.com`** are gated by our firewall. `vnet.bicep`'s `allow-microsoft-learn` collection allows `learn.microsoft.com` + an `allow-github-raw-mcp-bits` rule scoped to **`raw.githubusercontent.com`** only (the single host the agent hits — verified in `AZFWApplicationRule` denials; no `*.githubusercontent.com` wildcard). Without the GitHub-raw allow the connector provisions `Succeeded` yet shows **"no active connection"** with **zero** tools (a raw GET to `/api/mcp` returns `405` "use a streamable HTTP transport", so the endpoint is reachable — it's the bits fetch that's blocked). This is a **Standard** firewall, so L7 matching is FQDN/SNI only — pinning the exact repo path would need Azure Firewall **Premium** + TLS inspection (`targetUrls`). (The only true pod-side bypass is the platform `ExperimentalSettings.HttpMcpInSandbox` flag, which defaults to the locked-down in-sandbox broker and isn't exposed in our bicep.) **Separately**, MCP connector tools ship `defaultMode: disabled` (skill-gated — they only surface once a skill like `database-incidents` is active). To make the 3 Learn tools part of the **global** tool roster, `setup-sre-agent.ps1` Step 2b enables them via `POST /api/v2/agent/tools/configure` (`{overrides:[{name,enabled}]}`, merge semantics) — there is **no ARM/Bicep property** for per-tool state (the agent's `permissions` stays `null`; Microsoft's `srectl tool config set` CLI exists for exactly this). diff --git a/labs/zava-aks-postgres/README.md b/labs/zava-aks-postgres/README.md index 3b780f80e..2c5819ff3 100644 --- a/labs/zava-aks-postgres/README.md +++ b/labs/zava-aks-postgres/README.md @@ -162,7 +162,7 @@ This lab is configured so the agent uses **native `kubectl`** against the privat ZONE=$(az network private-dns zone list -g --query "[?contains(name,'azmk8s')].name|[0]" -o tsv) az network private-dns link vnet create -g -z $ZONE -n agent-link -v -e false ``` -2. **Firewall** — `vnet.bicep` adds an allow rule (`agent-subnet 10.30.0.0/27 → aks-subnet 10.20.0.0/20 :443`) **and SNATs** all traffic (`snat.privateRanges = 255.255.255.255/32`). SNAT is essential: the API server's NSG only admits the `VirtualNetwork` tag and the agent spoke isn't *directly* peered to the platform spoke, so the agent's source IP is rewritten to the firewall's hub IP (which *is* in the tag) — that also makes the return path symmetric without touching the AKS subnet's routing. +2. **Firewall** — `vnet.bicep` adds an allow rule (`agent-subnet 10.30.0.0/28 → aks-subnet 10.20.0.0/20 :443`) **and SNATs** all traffic (`snat.privateRanges = 255.255.255.255/32`). SNAT is essential: the API server's NSG only admits the `VirtualNetwork` tag and the agent spoke isn't *directly* peered to the platform spoke, so the agent's source IP is rewritten to the firewall's hub IP (which *is* in the tag) — that also makes the return path symmetric without touching the AKS subnet's routing. **Agent in-session setup — encoded in the skill runbook:** 1. `az aks get-credentials -g -n --overwrite-existing` diff --git a/labs/zava-aks-postgres/infra/main.json b/labs/zava-aks-postgres/infra/main.json index c5e5bf6c8..9ec08e531 100644 --- a/labs/zava-aks-postgres/infra/main.json +++ b/labs/zava-aks-postgres/infra/main.json @@ -5,7 +5,7 @@ "_generator": { "name": "bicep", "version": "0.43.1.21952", - "templateHash": "3184786289939969259" + "templateHash": "17454459993975253304" } }, "parameters": { @@ -83,7 +83,7 @@ "_generator": { "name": "bicep", "version": "0.43.1.21952", - "templateHash": "14346587368849512345" + "templateHash": "7676869149456753884" } }, "parameters": { @@ -252,7 +252,7 @@ { "name": "agent-subnet", "properties": { - "addressPrefix": "10.30.0.0/27", + "addressPrefix": "10.30.0.0/28", "routeTable": { "id": "[resourceId('Microsoft.Network/routeTables', format('rt-agent-{0}', parameters('uniqueSuffix')))]" }, @@ -401,7 +401,7 @@ "TCP" ], "sourceAddresses": [ - "10.30.0.0/27" + "10.30.0.0/28" ], "destinationAddresses": [ "168.63.129.16" @@ -428,7 +428,7 @@ "TCP" ], "sourceAddresses": [ - "10.30.0.0/27" + "10.30.0.0/28" ], "destinationAddresses": [ "10.20.0.0/20" @@ -455,7 +455,7 @@ "TCP" ], "sourceAddresses": [ - "10.30.0.0/27" + "10.30.0.0/28" ], "destinationAddresses": [ "10.10.2.0/27" @@ -482,7 +482,7 @@ "TCP" ], "sourceAddresses": [ - "10.30.0.0/27" + "10.30.0.0/28" ], "destinationAddresses": "[if(parameters('lockAgentToPrivateMonitor'), createArray('AzureResourceManager', 'AzureActiveDirectory'), createArray('AzureResourceManager', 'AzureActiveDirectory', 'AzureMonitor'))]", "destinationPorts": [ @@ -504,7 +504,7 @@ "name": "allow-arm-aad-graph", "description": "FQDN access to ARM, Entra ID, and Microsoft Graph", "sourceAddresses": [ - "10.30.0.0/27" + "10.30.0.0/28" ], "protocols": [ { @@ -533,7 +533,7 @@ "name": "allow-learn-microsoft-com", "description": "Microsoft Learn docs + MCP runtime endpoint (the agent looks up Azure/AKS/PostgreSQL guidance here)", "sourceAddresses": [ - "10.30.0.0/27" + "10.30.0.0/28" ], "protocols": [ { @@ -551,7 +551,7 @@ "name": "allow-github-raw-mcp-bits", "description": "GitHub raw content — the Microsoft Learn MCP connector fetches its server bits here to complete the tool-discovery handshake", "sourceAddresses": [ - "10.30.0.0/27" + "10.30.0.0/28" ], "protocols": [ { diff --git a/labs/zava-aks-postgres/infra/modules/vnet.bicep b/labs/zava-aks-postgres/infra/modules/vnet.bicep index 1412e35ab..6459c1537 100644 --- a/labs/zava-aks-postgres/infra/modules/vnet.bicep +++ b/labs/zava-aks-postgres/infra/modules/vnet.bicep @@ -41,7 +41,7 @@ param lockAgentToPrivateMonitor bool = true // └─ db-subnet 10.20.16.0/24 PostgreSQL Flexible Server delegation. // // SPOKE 2 — agent vnet-Zava-agent-* 10.30.0.0/24 (the SRE Agent) -// └─ agent-subnet 10.30.0.0/27 Microsoft.App/environments delegation; +// └─ agent-subnet 10.30.0.0/28 Microsoft.App/environments delegation; // ALL egress forced to the hub firewall // via a UDR (0.0.0.0/0 → firewall private // IP) over peering. @@ -226,10 +226,10 @@ resource agentVnet 'Microsoft.Network/virtualNetworks@2024-01-01' = { { // SRE Agent workload subnet — delegated to Microsoft.App/environments so // the agent's sandbox is injected here, with all egress forced through - // the hub Azure Firewall (route table above). Minimum size is /27. + // the hub Azure Firewall (route table above). Minimum size is /28. name: 'agent-subnet' properties: { - addressPrefix: '10.30.0.0/27' + addressPrefix: '10.30.0.0/28' routeTable: { id: agentRouteTable.id } delegations: [ { @@ -372,7 +372,7 @@ resource peerAgentToHub 'Microsoft.Network/virtualNetworks/virtualNetworkPeering // // range to the ruleCollectionGroup below (the module already SNATs all egress, // // so the return path stays symmetric): // // { name: 'allow-agent-to-remote-region', ruleType: 'NetworkRule', -// // sourceAddresses: ['10.30.0.0/27'], destinationAddresses: ['10.40.0.0/24'], +// // sourceAddresses: ['10.30.0.0/28'], destinationAddresses: ['10.40.0.0/24'], // // destinationPorts: ['*'], ipProtocols: ['Any'] } // // Cross-region peering alone is enough for VNet-to-VNet traffic that ISN'T // // force-tunneled; this lab force-tunnels the agent, hence the extra firewall rule. @@ -426,7 +426,7 @@ resource firewallPolicy 'Microsoft.Network/firewallPolicies@2024-05-01' = { // exposing the cluster API server publicly. // AzureCloud is deliberately NOT used (it covers ~65k prefixes including // third-party SaaS); precise service tags are used instead. The source is the -// agent spoke's subnet (10.30.0.0/27). +// agent spoke's subnet (10.30.0.0/28). // // To let the agent reach a NETWORK DEVICE or other private service DIRECTLY, its // management endpoint must be HTTPS and its FQDN added BOTH here (an application @@ -451,7 +451,7 @@ resource ruleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionG name: 'allow-azure-dns' description: 'DNS resolution via Azure DNS (required for the firewall DNS proxy)' ipProtocols: ['UDP', 'TCP'] - sourceAddresses: ['10.30.0.0/27'] + sourceAddresses: ['10.30.0.0/28'] destinationAddresses: ['168.63.129.16'] destinationPorts: ['53'] } @@ -475,7 +475,7 @@ resource ruleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionG name: 'agent-to-apiserver' description: 'Agent subnet -> AKS API server (enables native kubectl)' ipProtocols: ['TCP'] - sourceAddresses: ['10.30.0.0/27'] + sourceAddresses: ['10.30.0.0/28'] destinationAddresses: ['10.20.0.0/20'] destinationPorts: ['443'] } @@ -500,7 +500,7 @@ resource ruleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionG name: 'agent-to-ampls-pe' description: 'Agent subnet -> AMPLS private endpoint (private Azure Monitor)' ipProtocols: ['TCP'] - sourceAddresses: ['10.30.0.0/27'] + sourceAddresses: ['10.30.0.0/28'] destinationAddresses: ['10.10.2.0/27'] destinationPorts: ['443'] } @@ -517,7 +517,7 @@ resource ruleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionG name: 'allow-azure-services-l4' description: 'L4 access to Azure services via precise service tags (NOT AzureCloud)' ipProtocols: ['TCP'] - sourceAddresses: ['10.30.0.0/27'] + sourceAddresses: ['10.30.0.0/28'] // AzureMonitor is dropped by DEFAULT (lockAgentToPrivateMonitor=true) // so the agent reaches Monitor only over the AMPLS private endpoint — // private-only / maximum restraint; the agent remains fully functional @@ -544,7 +544,7 @@ resource ruleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionG ruleType: 'ApplicationRule' name: 'allow-arm-aad-graph' description: 'FQDN access to ARM, Entra ID, and Microsoft Graph' - sourceAddresses: ['10.30.0.0/27'] + sourceAddresses: ['10.30.0.0/28'] protocols: [{ protocolType: 'Https', port: 443 }] targetFqdns: [ 'management.azure.com' @@ -564,7 +564,7 @@ resource ruleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionG ruleType: 'ApplicationRule' name: 'allow-learn-microsoft-com' description: 'Microsoft Learn docs + MCP runtime endpoint (the agent looks up Azure/AKS/PostgreSQL guidance here)' - sourceAddresses: ['10.30.0.0/27'] + sourceAddresses: ['10.30.0.0/28'] protocols: [{ protocolType: 'Https', port: 443 }] targetFqdns: [ 'learn.microsoft.com' @@ -585,7 +585,7 @@ resource ruleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionG // (raw.githubusercontent.com/microsoftdocs/mcp/*) you'd need Azure // Firewall Premium + TLS inspection (targetUrls). See README caveats. description: 'GitHub raw content — the Microsoft Learn MCP connector fetches its server bits here to complete the tool-discovery handshake' - sourceAddresses: ['10.30.0.0/27'] + sourceAddresses: ['10.30.0.0/28'] protocols: [{ protocolType: 'Https', port: 443 }] targetFqdns: [ 'raw.githubusercontent.com' diff --git a/labs/zava-aks-postgres/sre-config/knowledge-base/zava-architecture.md b/labs/zava-aks-postgres/sre-config/knowledge-base/zava-architecture.md index 618cbfec4..a035fc400 100644 --- a/labs/zava-aks-postgres/sre-config/knowledge-base/zava-architecture.md +++ b/labs/zava-aks-postgres/sre-config/knowledge-base/zava-architecture.md @@ -55,7 +55,7 @@ App regressions are often shipped by a deployment, not caused by infra. Every ch ## Hub-and-spoke network and the hub firewall -You run VNet-injected in your **own spoke** (`vnet-Zava-agent-*`, `agent-subnet` 10.30.0.0/27), with all egress forced through a **shared Azure Firewall in the hub** (`vnet-Zava-hub-*`) over VNet peering. The workload — AKS and PostgreSQL — sits in a separate **platform spoke** (`vnet-Zava-platform-*`). Your agent subnet is pinned to **your own region** (VNet injection is regional — the subnet must be in the same region as you), but that only fixes *where you run*, not *what you can reach*: peering lets you operate on resources in **other Azure regions** (global VNet peering) or **on-prem** (ExpressRoute/VPN) too — here everything you act on is co-regional, so no cross-region hop is needed. Nothing about how you operate changes: you reach the private AKS API server through native `kubectl` run from your sandbox terminal, PostgreSQL through the in-cluster `bin/run-sql.js` helper, ARM / Entra / Microsoft Learn over allow-listed HTTPS, and Azure Monitor (Log Analytics / App Insights) over the AMPLS private endpoint by default — all through the hub firewall, and your Monitor query tools work normally over the private path. You never need raw L3 reachability to the other spokes. +You run VNet-injected in your **own spoke** (`vnet-Zava-agent-*`, `agent-subnet` 10.30.0.0/28), with all egress forced through a **shared Azure Firewall in the hub** (`vnet-Zava-hub-*`) over VNet peering. The workload — AKS and PostgreSQL — sits in a separate **platform spoke** (`vnet-Zava-platform-*`). Your agent subnet is pinned to **your own region** (VNet injection is regional — the subnet must be in the same region as you), but that only fixes *where you run*, not *what you can reach*: peering lets you operate on resources in **other Azure regions** (global VNet peering) or **on-prem** (ExpressRoute/VPN) too — here everything you act on is co-regional, so no cross-region hop is needed. Nothing about how you operate changes: you reach the private AKS API server through native `kubectl` run from your sandbox terminal, PostgreSQL through the in-cluster `bin/run-sql.js` helper, ARM / Entra / Microsoft Learn over allow-listed HTTPS, and Azure Monitor (Log Analytics / App Insights) over the AMPLS private endpoint by default — all through the hub firewall, and your Monitor query tools work normally over the private path. You never need raw L3 reachability to the other spokes. When an incident has a network/egress dimension, the **hub Azure Firewall is itself an inspectable resource**: read its policy and rule collections over ARM (your Reader role covers `az network firewall [policy] show`), and see what it actually allowed or denied in the resource-specific **`AZFW*`** Log Analytics tables (`AZFWNetworkRule`, `AZFWApplicationRule`, `AZFWNatRule`, `AZFWDnsQuery`) — those tables exist because the firewall's diagnostic setting uses the `Dedicated` destination. There is no third-party network device in this environment, and your sandbox egress is allow-listed HTTPS only, so you cannot open a raw TCP/SSH socket to a device IP; a device's own telemetry (if one shipped syslog/CEF to this workspace) would be the path, never a direct connection. diff --git a/sreagent-templates/bicep/assemble-agent.sh b/sreagent-templates/bicep/assemble-agent.sh index 3179dccd5..ad99184e3 100755 --- a/sreagent-templates/bicep/assemble-agent.sh +++ b/sreagent-templates/bicep/assemble-agent.sh @@ -177,7 +177,7 @@ NET_SUBNET_ID=$(echo "$AGENT_JSON" | jq -r '.networkConfiguration.subnetId // "" NET_RG=$(echo "$AGENT_JSON" | jq -r '.networkConfiguration.resourceGroup // ""') NET_VNET=$(echo "$AGENT_JSON" | jq -r '.networkConfiguration.vnetName // ""') NET_SUBNET_NAME=$(echo "$AGENT_JSON" | jq -r '.networkConfiguration.subnetName // "agent-subnet"') -NET_SUBNET_PREFIX=$(echo "$AGENT_JSON" | jq -r '.networkConfiguration.subnetPrefix // "10.2.0.0/27"') +NET_SUBNET_PREFIX=$(echo "$AGENT_JSON" | jq -r '.networkConfiguration.subnetPrefix // "10.2.0.0/28"') NET_ALLOWED_HOSTS=$(echo "$AGENT_JSON" | jq -c '.networkConfiguration.allowedHosts // []') NET_ALLOWED_REGISTRIES=$(echo "$AGENT_JSON" | jq -c '.networkConfiguration.allowedRegistries // []') NET_ALLOWED_CODE_REPOS=$(echo "$AGENT_JSON" | jq -c '.networkConfiguration.allowedCodeRepositories // []') diff --git a/sreagent-templates/bin/deploy.sh b/sreagent-templates/bin/deploy.sh index 4a37ada03..925e35a0a 100755 --- a/sreagent-templates/bin/deploy.sh +++ b/sreagent-templates/bin/deploy.sh @@ -217,7 +217,7 @@ if [[ -f "$AGENT_JSON_FILE" ]]; then NET_RG=$(jq -r '.networkConfiguration.resourceGroup // ""' "$AGENT_JSON_FILE") NET_VNET=$(jq -r '.networkConfiguration.vnetName // ""' "$AGENT_JSON_FILE") NET_SUBNET_NAME=$(jq -r '.networkConfiguration.subnetName // "agent-subnet"' "$AGENT_JSON_FILE") - NET_SUBNET_PREFIX=$(jq -r '.networkConfiguration.subnetPrefix // "10.2.0.0/27"' "$AGENT_JSON_FILE") + NET_SUBNET_PREFIX=$(jq -r '.networkConfiguration.subnetPrefix // "10.2.0.0/28"' "$AGENT_JSON_FILE") # Resolve subnet ID from broken-out fields if not given directly if [[ -z "$NET_SUBNET_ID" && -n "$NET_VNET" && -n "$NET_RG" ]]; then diff --git a/sreagent-templates/bin/ps/Deploy-Agent.ps1 b/sreagent-templates/bin/ps/Deploy-Agent.ps1 index 9649bf3d1..6611ca8fc 100644 --- a/sreagent-templates/bin/ps/Deploy-Agent.ps1 +++ b/sreagent-templates/bin/ps/Deploy-Agent.ps1 @@ -407,7 +407,7 @@ if ($IsDirectory) { $netRg = if ($netCfg.resourceGroup) { $netCfg.resourceGroup } else { '' } $netVnet = if ($netCfg.vnetName) { $netCfg.vnetName } else { '' } $netSubnetName = if ($netCfg.subnetName) { $netCfg.subnetName } else { 'agent-subnet' } - $netSubnetPrefix = if ($netCfg.subnetPrefix) { $netCfg.subnetPrefix } else { '10.2.0.0/27' } + $netSubnetPrefix = if ($netCfg.subnetPrefix) { $netCfg.subnetPrefix } else { '10.2.0.0/28' } # Resolve subnet ID from broken-out fields if not given directly if (-not $netSubnetId -and $netVnet -and $netRg) { diff --git a/sreagent-templates/examples/vnet-integrated-keyvault/README.md b/sreagent-templates/examples/vnet-integrated-keyvault/README.md index 8f60e6cbd..746ff5168 100644 --- a/sreagent-templates/examples/vnet-integrated-keyvault/README.md +++ b/sreagent-templates/examples/vnet-integrated-keyvault/README.md @@ -27,7 +27,7 @@ refuses: | Resource | Setting that matters | |---|---| | VNet `sreagent-vnet` (`10.30.0.0/24`) | One VNet, two subnets | -| ‣ `agent-subnet` (`10.30.0.0/27`) | Delegated to `Microsoft.App/environments` - agent injected here | +| ‣ `agent-subnet` (`10.30.0.0/28`) | Delegated to `Microsoft.App/environments` - agent injected here | | ‣ `pe-subnet` (`10.30.0.32/27`) | Holds the Key Vault private endpoint | | Key Vault | `public_network_access_enabled = false`, `default_action = Deny`, `bypass = None`, RBAC | | Private endpoint `pe-kv` | `subresource = vault`, in `pe-subnet` | diff --git a/sreagent-templates/examples/vnet-integrated-keyvault/terraform.tfvars.example b/sreagent-templates/examples/vnet-integrated-keyvault/terraform.tfvars.example index dcc2d8acc..ee3678d62 100644 --- a/sreagent-templates/examples/vnet-integrated-keyvault/terraform.tfvars.example +++ b/sreagent-templates/examples/vnet-integrated-keyvault/terraform.tfvars.example @@ -12,5 +12,5 @@ key_vault_name = "my-sre-agent-kv" # Address space (safe to leave as-is unless it collides with existing networks). vnet_address_space = "10.30.0.0/24" -agent_subnet_prefix = "10.30.0.0/27" +agent_subnet_prefix = "10.30.0.0/28" pe_subnet_prefix = "10.30.0.32/27" diff --git a/sreagent-templates/examples/vnet-integrated-keyvault/variables.tf b/sreagent-templates/examples/vnet-integrated-keyvault/variables.tf index dd4e7e922..187da8797 100644 --- a/sreagent-templates/examples/vnet-integrated-keyvault/variables.tf +++ b/sreagent-templates/examples/vnet-integrated-keyvault/variables.tf @@ -49,7 +49,7 @@ variable "vnet_address_space" { variable "agent_subnet_prefix" { description = "Delegated subnet the SRE Agent is injected into (Microsoft.App/environments)." type = string - default = "10.30.0.0/27" + default = "10.30.0.0/28" } variable "pe_subnet_prefix" {