Add network watcher enablement when safe (#22)

* Add network watcher enablement when safe Signed-off-by: Chad Kittel <[email protected]> * Fix typo in param description. Signed-off-by: Chad Kittel <[email protected]>
mspnp · Jul 7, 2021 · 7326195 · 7326195
1 parent a59c160
commit 7326195
Show file tree

Hide file tree

Showing 4 changed files with 136 additions and 5 deletions.
diff --git a/docs/additional-considerations.md b/docs/additional-considerations.md
@@ -38,6 +38,8 @@ In addition to Network Watcher aiding in compliance considerations, it's also a
 
 If you do not have Network Watchers and NSG Flow Logs enabled on your subscription, consider doing so via Azure Policy at the Subscription or Management Group level to provide consistent naming and region selection. See the [Deploy network watcher when virtual networks are created](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fa9b99dd8-06c5-4317-8629-9d86a3c6e7d9) policy combined with the [Flow logs should be enabled for every network security group](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F27960feb-a23c-4577-8d36-ef8b5f35e0be) policy.
 
+The [subscription.json](../subscription.json) file does include related Network Watcher policies, and will attempt to deploy Network Watcher if you do not already have evidence of them in your subscription. Reference those policy implementations if you would like to evaluate your current Network Watcher deployment strategy.
+
 ### More strict Network Security Groups (NSGs)
 
 The NSGs that exist around the cluster node pool subnets specifically block any SSH access attempts only allow traffic from the vnet into them. As your workloads, system security agents, etc are deployed, consider adding even more NSG rules that help define the type of traffic that should and should not be traversing those subnet boundaries. Because each nodepool lives in its own subnet, you can apply more specific rules based on known/expected traffic patterns of your workload.

diff --git a/docs/deploy/04-subscription.md b/docs/deploy/04-subscription.md
@@ -17,8 +17,9 @@ The following three resource groups will be created in the steps below.
 | rg-enterprise-networking-hubs   | Contains all of your organization's regional hubs. A regional hub resources in this implementation include an the hub Virtual Network, egress firewall, Azure Bastion, and Log Analytics for network logging. They may also contain your VPN Gateways, which are not addressed in this implementation. |
 | rg-enterprise-networking-spokes | Contains all of your organization's regional spokes and related networking resources. All spokes will peer with their regional hub and subnets will egress through the regional firewall in the hub. |
 | rg-bu0001a0005                  | Contains the regulated cluster resources. |
+| networkWatcherRG                | Contains regional Network Watchers. _(This is only created if your subscription doesn't already have Network Watchers in place.)_ |
 
-Both Azure Kubernetes Service and Azure Image Builder Service use a concept of a dynamically-created _infrastructure_ resource group. So in addition to the three resource groups mentioned above, as you follow these instructions, you'll end up with five resource groups; two of which are automatically created and their lifecycle tied to their owning service. You will not see these two infrastructure resource groups get created until later in the walkthrough when their owning service is created.
+Both Azure Kubernetes Service and Azure Image Builder Service use a concept of a dynamically-created _infrastructure_ resource group. So in addition to the four resource groups mentioned above, as you follow these instructions, you'll end up with six resource groups; two of which are automatically created and their lifecycle tied to their owning service. You will not see these two infrastructure resource groups get created until later in the walkthrough when their owning service is created.
 
 ### Azure Policy applied
 
@@ -27,9 +28,13 @@ To help govern our resources, there are policies we apply over the scope of thes
 | Policy Name                    | Scope                           | Purpose                                                                                           |
 |--------------------------------|---------------------------------|---------------------------------------------------------------------------------------------------|
 | Enable Azure Defender Standard | Subscription                    | Ensures that Azure Defender for Kubernetes, Container Service, and Key Vault are always enabled.  |
+| Deploy Network Watcher         | Subscription                    | A _Deploy if not exists_ policy to ensure there is a regional network watcher for your virtual networks. _(This is only created if your subscription doesn't already have Network Watchers in place.)_ |
 | Allowed resource types         | rg-enterprise-networking-hubs   | Restricts the hub resource group to just relevant networking resources.                           |
+| VNet must have Network Watcher | rg-enterprise-networking-hubs   | Audit policy that will trigger if a network is deployed to a region that doesn't have a Network Watcher. _(This is only created if your subscription doesn't already have Network Watchers in place.)_ |
 | Allowed resource types         | rg-enterprise-networking-spokes | Restricts the spokes resource group to just relevant networking resources.                        |
+| VNet must have Network Watcher | rg-enterprise-networking-spokes | Audit policy that will trigger if a network is deployed to a region that doesn't have a Network Watcher. _(This is only created if your subscription doesn't already have Network Watchers in place.)_ |
 | Allowed resource types         | rg-bu0001a0005                  | Restricts the workload resource group to just resources necessary for this specific architecture. |
+| Allowed resource types         | networkWatcherRG                | Restricts the Network Watcher resource group to just Network Watcher resources. _(This is only created if your subscription doesn't already have Network Watchers in place.)_ |
 | No public AKS clusters         | rg-bu0001a0005                  | Restricts the creation of AKS clusters to only those with private Kubernetes API server.   |
 | No out-of-date AKS clusters    | rg-bu0001a0005                  | Restricts the creation of AKS clusters to only recent versions.                            |
 | No AKS clusters without RBAC   | rg-bu0001a0005                  | Restricts the creation of AKS clusters to only those that are Azure AD RBAC enabled.       |
@@ -76,20 +81,28 @@ Not only do we enable them in the steps below by default, but also set up an Azu
    TENANTID_AZURERBAC=$(az account show --query tenantId -o tsv)
    ```
 
+1. Check for existing Network Watchers.
+
+   ```bash
+   [ $(az network watcher list --query 'length([])' -o tsv) -eq 0 ] && ENABLE_NETWORK_WATCHERS=true || ENABLE_NETWORK_WATCHERS=false
+   ```
+
+   > Azure Network Watchers are regional singletons in your subscription and should always be handled external to any specific workload; at the subscription level. Because your subscription may already have configuration (existing instances and/or a corresponding _deploy if not exists_ policy applied) around Network Watcher, it's hard to deliver a "one size fits all" solution in this isolated walkthrough. If the subscription you're deploying into doesn't have _any_ Network Watchers deployed, you'll have them set up as part of this deployment. If however, you already have Network Watcher resources, we'll leave those alone and won't deploy any additional resources related to them. If you have any conflicts in this walkthrough related to Network Watchers (existing management group policies, etc.), simply set `ENABLE_NETWORK_WATCHERS=false` and all related attempts to set up Network Watchers will be skipped.
+
 1. Perform subscription-level deployment.
 
    This will deploy the resource groups, Azure Policies, and Azure Security Center configuration all as identified above.
 
    ```bash
    # [This may take up to six minutes to run.]
-   az deployment sub create -f subscription.json -l centralus
+   az deployment sub create -f subscription.json -l centralus -p enableNetworkWatchers=${ENABLE_NETWORK_WATCHERS}
    ```
 
    If you do not have permissions on your subscription to enable Azure Defender (which requires the Azure RBAC role of _Subscription Owner_ or _Security Admin_), then instead execute the following variation of the same command. This will not enable Azure Defender services nor will Azure Policy attempt to enable the same (the policy will still be created, but in audit-only mode). Your final implementation should be to a subscription with these security services activated.
 
    ```bash
    # [This may take up to five minutes to run.]
-   az deployment sub create -f subscription.json -l centralus -p enableAzureDefender=false enforceAzureDefenderAutoDeployPolicies=false
+   az deployment sub create -f subscription.json -l centralus -p enableAzureDefender=false enforceAzureDefenderAutoDeployPolicies=false enableNetworkWatchers=${ENABLE_NETWORK_WATCHERS}
    ```
 
 ## Azure Security Benchmark

diff --git a/docs/deploy/14-cleanup.md b/docs/deploy/14-cleanup.md
@@ -16,6 +16,8 @@ After you are done exploring your deployed [AKS Baseline Cluster for Regulated W
    az group delete -n rg-enterprise-networking-hubs
    ```
 
+   Depending on your subscription's starting point, this walkthrough might have also deployed a resource group by the name of `networkWatcherRG`. If you know this to be the case, and wish to remove it as well, you can execute `az group delete -n networkWatcherRG`. If you are not sure, you can leave that resource group in place, the resources deployed as part of this walkthrough to that resource group are not cost or security impacting.
+
 1. Purge Azure Key Vault
 
    > Because this reference implementation enables soft delete on Key Vault, execute a purge so your next deployment of this implementation doesn't run into a naming conflict.
@@ -26,7 +28,7 @@ After you are done exploring your deployed [AKS Baseline Cluster for Regulated W
 
 1. If any temporary changes were made to Azure AD or Azure RBAC permissions consider removing those as well.
 
-1. [Remove the Azure Policy assignments](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyMenuBlade/Compliance) scoped to the cluster's resource group. To identify those created by this implementation, look for ones that are prefixed with `[your-cluster-name` and `[your-resource-group-names] `.  If you added **Azure Security Benchmark** or **Enable Azure Defender Standard** as part of this as well, you can remove that.
+1. [Remove the Azure Policy assignments](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyMenuBlade/Compliance) scoped to the cluster's resource group. To identify those created by this implementation, look for ones that are prefixed with `[your-cluster-name] ` and `[your-resource-group-names] `.  If you added **Azure Security Benchmark** or **Enable Azure Defender Standard** as part of this as well, you may choose to remove them as well.
 
    Execute the following commands will handle all Resource Group-scoped policies: