AKS Baseline regulated - New Azure Defender for containers feature in…

…troduced. (#57) * Policy changes at subscription level and property added to cluster deployment file * More docs updated * Fixed subscription policy set * Changing text in deployment steps according to new defender feature rename * Falco and defender coexisting text * Adding new policy assignment to the list in the subscription step * Runtime scanning of images sentence added * Update docs/deploy/11-gitops.md Co-authored-by: Chad Kittel <[email protected]> * Update docs/deploy/10-pre-bootstrap.md Co-authored-by: Chad Kittel <[email protected]> * Update docs/deploy/11-gitops.md Co-authored-by: Chad Kittel <[email protected]> * Update docs/deploy/13-validation-logs.md Co-authored-by: Chad Kittel <[email protected]> * Update docs/deploy/13-validation-logs.md Co-authored-by: Chad Kittel <[email protected]> * Update docs/deploy/04-subscription.md Co-authored-by: Chad Kittel <[email protected]> * Addressing comments, feature register is no longer needed as it's GA now, updated defender links to new location * Changed defender in cluster policy name and moved to the right place in the list * Update docs/deploy/01-prerequisites.md * Update docs/deploy/04-subscription.md * Update docs/deploy/04-subscription.md Co-authored-by: Chad Kittel <[email protected]> * Update docs/deploy/04-subscription.md Co-authored-by: Chad Kittel <[email protected]>
mspnp · Jan 26, 2022 · 8a5978e · 8a5978e
1 parent bd69d2e
commit 8a5978e
Show file tree

Hide file tree

Showing 8 changed files with 82 additions and 89 deletions.
diff --git a/cluster-stamp.json b/cluster-stamp.json
@@ -1457,7 +1457,13 @@
                 "podIdentityProfile": { 
                     "enabled": true
                 },
-                "disableLocalAccounts": true
+                "disableLocalAccounts": true,
+                "securityProfile": {
+                    "azureDefender": {
+                        "enabled": true,
+                        "logAnalyticsWorkspaceResourceId": "[resourceId('Microsoft.OperationalInsights/workspaces', variables('logAnalyticsWorkspaceName'))]"
+                    }
+                }
             },
             "identity": {
                 "type": "UserAssigned",

diff --git a/cluster-stamp.v2.json b/cluster-stamp.v2.json
@@ -1468,7 +1468,13 @@
                         }
                     ]
                 },
-                "disableLocalAccounts": true
+                "disableLocalAccounts": true,
+                "securityProfile": {
+                    "azureDefender": {
+                        "enabled": true,
+                        "logAnalyticsWorkspaceResourceId": "[resourceId('Microsoft.OperationalInsights/workspaces', variables('logAnalyticsWorkspaceName'))]"
+                    }
+                }
             },
             "identity": {
                 "type": "UserAssigned",

diff --git a/docs/deploy/04-subscription.md b/docs/deploy/04-subscription.md
@@ -27,7 +27,7 @@ To help govern our resources, there are policies we apply over the scope of thes
 
 | Policy Name                    | Scope                           | Purpose                                                                                           |
 |--------------------------------|---------------------------------|---------------------------------------------------------------------------------------------------|
-| Enable Microsoft Defender Standard | Subscription                | Ensures that Microsoft Defender for Kubernetes, Container Service, and Key Vault are always enabled. |
+| Enable Microsoft Defender Standard | Subscription                | Ensures that Microsoft Defender for Containers, DNS, Key Vault, and Resource Manager are always enabled. |
 | 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.                        |
@@ -40,6 +40,7 @@ To help govern our resources, there are policies we apply over the scope of thes
 | No AKS clusters without Azure Policy | rg-bu0001a0005            | Restricts the creation of AKS clusters to only those that have the Azure Policy Add-on enabled.   |
 | No AKS clusters without BYOK OS & Data Disk Encryption | rg-bu0001a0005  | Restricts the creation of AKS clusters to only those that have customer-managed disk encryption enabled. (_This is in audit only mode, as not all customers may wish to do this._) |
 | No AKS clusters without encryption-at-host | rg-bu0001a0005      | Restricts the creation of AKS clusters to only those that have the Encryption-At-Host feature enabled. (_This is in audit only mode, as not all customers may wish to do this._) |
+| No AKS clusters without Microsoft Defender for Containers | rg-bu0001a0005                | Restricts the creation of AKS clusters to only those that have the Microsoft Defender for Containers feature enabled. |
 | No App Gateways without WAF    | rg-bu0001a0005                  | Restricts the creation of Azure Application Gateway to only the WAF SKU. |
 | No VMSS with public IPs        | rg-bu0001a0005                  | Only VMSS that do not have public IPs can be created in this resource group. |
 
@@ -55,11 +56,10 @@ Also, depending on your workload subscription scope, some of the policies applie
 
 As mentioned in the Azure Policy section above, we enable the following Microsoft Defender for Cloud's services.
 
-* [Microsoft Defender for Kubernetes](https://docs.microsoft.com/azure/security-center/defender-for-kubernetes-introduction)
-* [Microsoft Defender for Container Registries](https://docs.microsoft.com/azure/security-center/defender-for-container-registries-introduction)
-* [Microsoft Defender for Key Vault](https://docs.microsoft.com/azure/security-center/defender-for-key-vault-introduction)
-* [Microsoft Defender for Azure DNS](https://docs.microsoft.com/azure/security-center/defender-for-dns-introduction)
-* [Microsoft Defender for Azure Resource Manager](https://docs.microsoft.com/azure/security-center/defender-for-resource-manager-introduction)
+* [Microsoft Defender for Containers](https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-introduction)
+* [Microsoft Defender for Key Vault](https://docs.microsoft.com/azure/defender-for-cloud/defender-for-key-vault-introduction)
+* [Microsoft Defender for Azure DNS](https://docs.microsoft.com/azure/defender-for-cloud/defender-for-dns-introduction)
+* [Microsoft Defender for Azure Resource Manager](https://docs.microsoft.com/azure/defender-for-cloud/defender-for-resource-manager-introduction)
 
 Not only do we enable them in the steps below by default, but also set up an Azure Policy that ensures they stay enabled.
 

diff --git a/docs/deploy/10-pre-bootstrap.md b/docs/deploy/10-pre-bootstrap.md
@@ -16,7 +16,7 @@ You'll end up with the following images imported into your ACR instance, after h
 
 ## Quarantine pattern
 
-Quarantining first- and third-party images is a recommended security practice. This allows you to get your images onto a dedicated container registry and subject them to any sort of security/compliance scrutiny you wish to apply. Once validated, they can then be promoted to being available to your cluster. There are many variations on this pattern, with different tradeoffs for each. For simplicity in this walkthrough we are simply going to import our images to repository names that starts with `quarantine/`. We'll then show you Microsoft Defender for container registries's scan of those images, and then you'll import those same images directly from `quarantine/` to `live/` repositories (retaining their sha256 digest). We've restricted our cluster to only allow pulling from `live/` repositories and we've built an alert if an image was imported to `live/` from a source other than `quarantine/`. This isn't a preventative security control; _this won't block a direct import_ request or _validate_ that the image actually passed quarantine checks. There are other solutions you can use for this pattern that are more exhaustive. [Aquasec](https://go.microsoft.com/fwlink/?linkid=2002601&clcid=0x409) and [Twistlock](https://go.microsoft.com/fwlink/?linkid=2002600&clcid=0x409) both offer integrated solutions specifically for Azure Container Registry scanning and compliance management. Azure Container Registry has an [integrated quarantine feature](https://docs.microsoft.com/azure/container-registry/container-registry-faq#how-do-i-enable-automatic-image-quarantine-for-a-registry) as well that could be considered, however it is in preview at this time.
+Quarantining first- and third-party images is a recommended security practice. This allows you to get your images onto a dedicated container registry and subject them to any sort of security/compliance scrutiny you wish to apply. Once validated, they can then be promoted to being available to your cluster. There are many variations on this pattern, with different tradeoffs for each. For simplicity in this walkthrough we are simply going to import our images to repository names that starts with `quarantine/`. We'll then show you Microsoft Defender for Containers' scan of those images, and then you'll import those same images directly from `quarantine/` to `live/` repositories (retaining their sha256 digest). We've restricted our cluster to only allow pulling from `live/` repositories and we've built an alert if an image was imported to `live/` from a source other than `quarantine/`. This isn't a preventative security control; _this won't block a direct import_ request or _validate_ that the image actually passed quarantine checks. There are other solutions you can use for this pattern that are more exhaustive. [Aquasec](https://go.microsoft.com/fwlink/?linkid=2002601&clcid=0x409) and [Twistlock](https://go.microsoft.com/fwlink/?linkid=2002600&clcid=0x409) both offer integrated solutions specifically for Azure Container Registry scanning and compliance management. Azure Container Registry has an [integrated quarantine feature](https://docs.microsoft.com/azure/container-registry/container-registry-faq#how-do-i-enable-automatic-image-quarantine-for-a-registry) as well that could be considered, however it is in preview at this time.
 
 > :notebook: See [Azure Architecture Center guidance for PCI-DSS 3.2.1 Requirement 6.3.2 in AKS](https://docs.microsoft.com/azure/architecture/reference-architectures/containers/aks-pci/aks-pci-malware#requirement-632).
 
@@ -28,7 +28,7 @@ Once your images are built (or identified from a public container registry such
 
 ## Continuous scanning
 
-The quarantine pattern is ideal for detecting issues with newly pushed images, but _continuous scanning_ is also desirable as CVEs can be found at any time for your images that are in use. **Microsoft Defender for container registries** will perform daily scanning of active images. Third party ISV solutions can perform similar tasks. It is recommended that you implement continuous scanning at the registry level. Microsoft Defender for container registries currently has limitations with private Azure Container Registry instances (such as yours, exposed exclusively via Private Link). Ensure your continuous scan solution can work within your network restrictions. You may need to bring a third party ISV solution into network adjacency to your container registry to be able to perform your desired scanning. How you react to a CVE (or other issue) detected in your images should be documented in your security operations playbooks. For example, you could remove the image from being available to pull, but that could cause a downstream outage while you're remediating.
+The quarantine pattern is ideal for detecting issues with newly pushed images, but _continuous scanning_ is also desirable as CVEs can be found at any time for your images that are in use. **Microsoft Defender for containers** will perform daily scanning of active images and also provide [run-time visibility of vulnerabilities](https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-introduction?tabs=defender-for-container-arch-aks#scanning-images-at-runtime) by grouping them and providing details about the issues discovered and how to remediate them. Third party ISV solutions can perform similar tasks. It is recommended that you implement continuous scanning at the registry level. Microsoft Defender for containers currently has limitations with private Azure Container Registry instances (such as yours, exposed exclusively via Private Link). Ensure your continuous scan solution can work within your network restrictions. You may need to bring a third party ISV solution into network adjacency to your container registry to be able to perform your desired scanning. How you react to a CVE (or other issue) detected in your images should be documented in your security operations playbooks. For example, you could remove the image from being available to pull, but that could cause a downstream outage while you're remediating.
 
 ## In-cluster scanning
 
@@ -62,7 +62,7 @@ Using a security agent that is container-aware and can operate from within the c
 
 1. Run security audits on images.
 
-   If you had sufficient permissions when we did [subscription configuration](./04-subscription.md), Microsoft Defender for container registries is enabled on your subscription. Microsoft Defender for container registries will begin [scanning all newly imported images](https://docs.microsoft.com/azure/security-center/defender-for-container-registries-introduction#when-are-images-scanned) in your Azure Container Registry using a Microsoft hosted version of Qualys. The results of those scans will be available in Microsoft Defender for Cloud within 15 minutes. _If Microsoft Defender for container registries is not enabled on your subscription, you can skip this step._
+   If you had sufficient permissions when we did [subscription configuration](./04-subscription.md), Microsoft Defender for containers is enabled on your subscription. Microsoft Defender for containers will begin [scanning all newly imported images](https://docs.microsoft.com/azure/security-center/defender-for-container-registries-introduction#when-are-images-scanned) in your Azure Container Registry using a Microsoft hosted version of Qualys. The results of those scans will be available in Microsoft Defender for Cloud within 15 minutes. _If Microsoft Defender for containers is not enabled on your subscription, you can skip this step._
 
    To see the scan results in Microsoft Defender for Cloud, perform the following actions:
 
@@ -72,7 +72,7 @@ Using a security agent that is container-aware and can operate from within the c
    1. Expand **Affected resources**.
    1. Click on your ACR instance name under one of the **registries** tabs.
 
-   In here, you can see which container images are **Unhealthy** (had a scan detection), **Healthy** (was scanned, but didn't result in any alerts), and **Unverified** (was unable to be scanned). Unfortunately, Microsoft Defender for container registries is [unable to scan all artifacts types](https://docs.microsoft.com/azure/security-center/defender-for-container-registries-introduction#availability). Also, because your container registry is exposed exclusively through Private Link, you won't get a list of those Unverified images listed here. Microsoft Defender for container registries is only full-featured with non-network restricted container registries.
+   In here, you can see which container images are **Unhealthy** (had a scan detection), **Healthy** (was scanned, but didn't result in any alerts), and **Unverified** (was unable to be scanned). Unfortunately, Microsoft Defender for containers is [unable to scan all artifacts types](https://docs.microsoft.com/azure/security-center/defender-for-container-registries-introduction#availability). Also, because your container registry is exposed exclusively through Private Link, you won't get a list of those Unverified images listed here. Microsoft Defender for containers is only full-featured with non-network restricted container registries.
 
    As with any Microsoft Defender for Cloud product, you can set up alerts or via your connected SIEM to be identified when an issue is detected. Periodically checking and discovering security alerts via the Azure Portal is not the expected method to consume these security status notifications. No Microsoft Defender for Cloud alerts are currently configured for this walkthrough.