+| [Conditional Access](../active-directory/conditional-access/overview.md) | Fully supported for administrative and user accounts. | A subset of Azure AD Conditional Access features is supported with [consumer accounts](user-overview.md#consumer-user) Learn how to configure Azure AD B2C [conditional access](conditional-access-user-flow.md).|

+Yes, Permissions Management is currently for tenants hosted in the European Union (EU).

+Yes, as of July 1st, 2022, new customers must acquire a free 90-trial license or a paid license to use the service. You can enable a trial here: [https://aka.ms/TryPermissionsManagement](https://aka.ms/TryPermissionsManagement) or you can directly purchase resource-based licenses here: [https://aka.ms/BuyPermissionsManagement](https://aka.ms/BuyPermissionsManagement)

+Transient NameID is also supported, but isn't available in the dropdown and can't be configured on Azure's side. To learn more about the NameIDPolicy attribute, see [Single sign-On SAML protocol](single-sign-on-saml-protocol.md).

+| **RegexReplace()** (Preview) | RegexReplace() transformation accepts as input parameters:<br />- Parameter 1: a user attribute as regex input<br />- An option to trust the source as multivalued<br />- Regex pattern<br />- Replacement pattern. The replacement pattern may contain static text format along with reference pointing to regex output groups and additional input parameters.<br /><br/>Additional instructions on how to use RegexReplace() Transformation described below. |

+1. Select the edit button (pencil icon) to open the claims transformation blade.

+1. Select the ΓÇ£RegexReplace()ΓÇ¥ option from the ΓÇ£TransformationΓÇ¥ options to use regex-based claims transformation method for claims transformation.

+1. ΓÇ£Parameter 1ΓÇ¥ is the source user input attribute which will be an input for the regular expression transformation. For example, user.mail which will have user email address such as admin@contoso.com.

+1. Some input user attributes can be multi-value user attributes. If the selected user attribute supports multiple values and the user wants to use multiple values for the transformation, they need to check the ΓÇ£Treat source as multivaluedΓÇ¥ checkbox. If an administrator checks the checkbox, all values will be used for regex match, otherwise only the first value will be used.

+1. The ΓÇ£Regex patternΓÇ¥ textbox accepts a regular expression which will be evaluated against the value of user attribute selected as ΓÇ£parameter 1ΓÇ¥. For example a regular expression to extract user alias from the userΓÇÖs email address would be represented as: ΓÇ£(?'domain'^.*?)(?i)(\@contoso\.com)$ΓÇ¥

+1. By using the ΓÇ£Add additional parameterΓÇ¥ button, an administrator can choose more user attributes, which can be used for the transformation. The values of the additional attributes would then be merged with regex transformation output. Currently, up to five additional parameters are supported.

+ <br />To illustrate, let's use user.country attribute as an input parameter. The value of this attribute is ΓÇ£USΓÇ¥. To merge this into the replacement pattern the administrator needs to refer to it as {country} inside the replacement pattern. Once the administrator selects the user attribute for the parameter, an info balloon for the parameter will explain how the parameter can be used inside the replacement pattern.

+1. The ΓÇ£Replacement patternΓÇ¥ textbox accepts the replacement pattern. Replacement pattern is the text template, which contains placeholders for regex outcome group name, input parameter group name, and static text value. All group names must be wrapped inside the curly braces such as {group-name}. LetΓÇÖs say the administration wants to use user alias with some other domain name e.g. xyz.com and merge country name with it. In this case the replacement pattern would be ΓÇ£{country}.{domain}@xyz.comΓÇ¥, where {country} will be the value of input parameter and {domain} will be the group output from the regular expression evaluation. In such a case, the expected outcome will be ΓÇ£US.swmal@xyz.comΓÇ¥

+1. RegexReplace() transformation will be evaluated only if the value of the selected user attribute for ΓÇ£Parameter 1ΓÇ¥ matches with the regular expression provided in ΓÇ£Regex patternΓÇ¥ textbox. If they do not match, the default claim value will be added to the token. To validate regular expression against the input parameter value, a test experience is available within the transform blade. This test experience operates on dummy values only. When additional input parameters are used, the name of the parameter will be added to the test result instead of the actual value. You can see a sample output in point 18. To access the test section an administrator can select the ΓÇ£Test transformationΓÇ¥ button.

+1. Regex-based claims transformations are not limited to the first transformation and can be used as the second level transformation as well. Any other transformation method can be used as the first transformation.

+1. If RegexReplace() is selected as a second level transformation, output of first level transformation will be used as an input for the second level transformation. The second level regex expression should match the output of the first transformation else the transformation won't be applied.

+1. Administrators can delete the selected input parameter if they donΓÇÖt need it anymore.

+1. Once administrator selects ΓÇ£Test transformationΓÇ¥, the ΓÇ£Test transformationΓÇ¥ section will be displayed, and ΓÇ£Test transformationΓÇ¥ button goes away.

+1. Select the close or (X) button to hide the test section and re-render the ΓÇ£Test transformationΓÇ¥ button again on the blade.

+1. The ΓÇ£Test regex inputΓÇ¥ textbox accepts the dummy input, which will be used as an input for regular expression test evaluation. In case regex-based claims transformation is configured as a second level transformation, the administrator needs to provided a dummy value, which would be the expected output of the first transformation.

+1. Once the administrator provides the test regex input and configures the ΓÇ£Regex patternΓÇ¥, ΓÇ£Replacement patternΓÇ¥ and ΓÇ£Input parametersΓÇ¥, they can evaluate the expression by clicking on the ΓÇ£Run testΓÇ¥ button.

+1. If evaluation succeeds, an output of test transformation will be rendered against the ΓÇ£Test transformation resultΓÇ¥ label.

+1. The administrator can remove the second level transformation by using ΓÇ£Remove transformationΓÇ¥ button.

+1. When a regex input value is configured against the ΓÇ£Parameter 1ΓÇ¥ which doesn't matches the ΓÇ£Regular expressionΓÇ¥, the transformation is skipped. In such cases, the administrator can configure the alternate user attribute, which will be added to the token for the claim by checking the checkbox for ΓÇ£Specify output if no matchΓÇ¥.

+1. If an administrator wants to return alternate user attribute in case of no match and checked the ΓÇ£Specify output if no matchΓÇ¥ checkbox, they can select alternate user attribute by using the dropdown. This dropdown is available against ΓÇ£Parameter 3 (output if no match)ΓÇ¥.

+1. At the bottom of the blade a full summary of the format is displayed which explains the meaning of transformation in simple text.

+1. Once the administrator is satisfied with the configuration settings for the transformation, they can save it to claims policy by selecting the ΓÇ£AddΓÇ¥ button. Changes wonΓÇÖt be saved unless the administrator manually selects the ΓÇ£SaveΓÇ¥ toolbar button available on ΓÇ£Manage ClaimΓÇ¥ blade.

+Input parameters with duplicate user attributes aren't allowed. If duplicate user attributes are selected, the following validation message will be rendered after the administrator selects ΓÇ£AddΓÇ¥ or ΓÇ£Run testΓÇ¥ button.

+A `Signature` element in `AuthnRequest` elements is optional. Azure AD does not validate signed authentication requests if a signature is present. Requestor verification is provided for by only responding to registered Assertion Consumer Service URLs.

+ > [!TIP]

+ >If you intend to trust inbound MFA for external users, make sure you don't have an [Identity Protection policy](../identity-protection/howto-identity-protection-configure-mfa-policy.md) in place that requires external users to register for MFA. When both of these policies are present, external users wonΓÇÖt be able to satisfy the requirements for access. If you want to enforce the Identity Protection MFA registration policy, be sure to exclude external users.

+> The tokens that your application receives are cached by the underlying infrastructure, which means that any changes to the managed identity's roles can take significant time to take effect. For more information, see [Limitation of using managed identities for authorization](managed-identity-best-practice-recommendations.md#limitation-of-using-managed-identities-for-authorization).

+ - Run scripts locally by installing the latest version of [the Az PowerShell module](/powershell/azure/install-az-ps). You can also use the [Microsoft Graph PowerShell SDK](/powershell/microsoftgraph/get-started).

+ **For a system-assigned managed identity**, you can find the object ID on the Azure portal on the resource's **Identity** page. You can also use the following PowerShell script to find the object ID. You'll need the resource ID of the resource you created in step 1, which is available in the Azure portal on the resource's **Properties** page.

+ ```powershell

+ $resourceIdWithManagedIdentity = '/subscriptions/{my subscription ID}/resourceGroups/{my resource group name}/providers/Microsoft.Compute/virtualMachines/{my virtual machine name}'

+ (Get-AzResource -ResourceId $resourceIdWithManagedIdentity).Identity.PrincipalId

+ ```

+ **For a user-assigned managed identity**, you can find the managed identity's object ID on the Azure portal on the resource's **Overview** page. You can also use the following PowerShell script to find the object ID. You'll need the resource ID of the user-assigned managed identity.

+ ```powershell

+ $userManagedIdentityResourceId = '/subscriptions/{my subscription ID}/resourceGroups/{my resource group name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{my managed identity name}'

+ (Get-AzResource -ResourceId $userManagedIdentityResourceId).Properties.PrincipalId

+ ```

+ # [Azure PowerShell](#tab/azurepowershell)

+ ```powershell

+ $serverServicePrincipalObjectId = (Get-AzureADServicePrincipal -Filter "DisplayName eq '$applicationName'").ObjectId

+ ```

+ # [Microsoft Graph](#tab/microsoftgraph)

+

+1. Add an [app role](../develop/howto-add-app-roles-in-azure-ad-apps.md) to the application you created in step 3. You can create the role using the Azure portal or by using Microsoft Graph. For example, you could add an app role like this:

+ # [Azure PowerShell](#tab/azurepowershell)

+ ```powershell

+ New-AzureADServiceAppRoleAssignment `

+ -ObjectId $managedIdentityObjectId `

+ -Id $appRoleId `

+ -PrincipalId $managedIdentityObjectId `

+ -ResourceId $serverServicePrincipalObjectId

+ ```

+ # [Microsoft Graph](#tab/microsoftgraph)

+

+# [Azure PowerShell](#tab/azurepowershell)

+```powershell

+# Install the module. This step requires you to be an administrator on your machine.

+# Install-Module AzureAD

+# Your tenant ID (in the Azure portal, under Azure Active Directory > Overview).

+$tenantID = '<tenant-id>'

+# The name of your web app, which has a managed identity that should be assigned to the server app's app role.

+$webAppName = '<web-app-name>'

+$resourceGroupName = '<resource-group-name-containing-web-app>'

+# The name of the server app that exposes the app role.

+$serverApplicationName = '<server-application-name>' # For example, MyApi

+# The name of the app role that the managed identity should be assigned to.

+$appRoleName = '<app-role-name>' # For example, MyApi.Read.All

+# Look up the web app's managed identity's object ID.

+$managedIdentityObjectId = (Get-AzWebApp -ResourceGroupName $resourceGroupName -Name $webAppName).identity.principalid

+Connect-AzureAD -TenantId $tenantID

+# Look up the details about the server app's service principal and app role.

+$serverServicePrincipal = (Get-AzureADServicePrincipal -Filter "DisplayName eq '$serverApplicationName'")

+$serverServicePrincipalObjectId = $serverServicePrincipal.Id

+$appRoleId = ($serverServicePrincipal.AppRoles | Where-Object {$_.Value -eq $appRoleName }).Id

+# Assign the managed identity access to the app role.

+New-AzureADServiceAppRoleAssignment `

+ -ObjectId $managedIdentityObjectId `

+ -Id $appRoleId `

+ -PrincipalId $managedIdentityObjectId `

+ -ResourceId $serverServicePrincipalObjectId

+```

+# [Microsoft Graph](#tab/microsoftgraph)

+>[!NOTE]

+>Approvers are not able to approve their own role activation requests.

+[manage-resource-group-cli]: /azure/azure-resource-manager/management/manage-resource-groups-cli

+**Capacity** is the most important [Azure Monitor metric](api-management-howto-use-azure-monitor.md#view-metrics-of-your-apis) for making informed decisions whether to [scale or upgrade](upgrade-and-scale.md) an API Management instance to accommodate more load. Its construction is complex and imposes certain behavior.

+> This article discusses how you can monitor and scale your Azure API Management instance based upon its capacity metric. However, it is equally important to understand what happens when an individual API Management instance has actually *reached* its capacity. Azure API Management will not apply service-level throttling to prevent a physical overload of the instances. When an instance reaches its physical capacity, it will behave similar to any overloaded web server that is unable to process incoming requests: latency will increase, connections will get dropped, timeout errors will occur, and so on. This means that API clients should be prepared to deal with this possibility as they do with any other external service (for example, by applying retry policies).

+To follow the steps in this article, you must have:

+**Capacity** is an indicator of load on an API Management instance. It reflects usage of resources (CPU, memory) and network queue lengths. CPU and memory usage reveals consumption of resources by:

+Total **capacity** is an average of its own values from every [unit](upgrade-and-scale.md) of an API Management instance.

+The more complex operations on the requests are, the higher the **capacity** consumption will be. For example, complex transformation policies consume much more CPU than a simple request forwarding. Slow backend service responses will increase it, too.

+**Capacity** can also spike intermittently or be greater than zero even if no requests are being processed. It happens because of system- or platform-specific actions and should not be taken into consideration when deciding whether to scale an instance.

+## Use the Azure portal to examine capacity

+1. Navigate to your API Management instance in the [Azure portal](https://portal.azure.com/).

+2. In the left menu, under **Monitoring**, select **Metrics**.

+3. Select the **Capacity** metric from the available metrics and leave the default **Avg** aggregation.

+ > If you've deployed your instance to multiple locations, you should always look at a **capacity** metric breakdown per location to avoid wrong interpretations.

+4. To split the metric by location, from the section at the top, select **Apply splitting** and then select **Location**.

+ You can set a [metric alert](api-management-howto-use-azure-monitor.md#set-up-an-alert-rule) to let you know when something unexpected is happening. For example, get notifications when your API Management instance has exceeded its expected peak capacity for more than 20 minutes.

+ > You can configure alerts to let you know when your service is running low on capacity or use Azure Monitor [autoscaling](api-management-howto-autoscale.md) to automatically add an Azure API Management unit. Scaling operation can take around 30 minutes, so you should plan your rules accordingly.

+**Capacity** is the metric for making decisions whether to scale an API Management instance to accommodate more load. The following are general considerations:

+> If you are able to estimate your traffic beforehand, test your API Management instance on workloads you expect. You can increase the request load on your tenant gradually and monitor the value of the capacity metric that corresponds to your peak load. Follow the steps from the previous section to use Azure portal to understand how much capacity is used at any given time.

+- [Upgrade and scale an Azure API Management service instance](upgrade-and-scale.md)

+- [Automatically scale an Azure API Management instance](api-management-howto-autoscale.md)

+- [Plan and manage costs for API Management](plan-manage-costs.md)

+### Elements

+| Name | Description | Required |

+| | | -- |

+| `set-graphql-resolver` | Root element. | Yes |

+| `http-data-source` | Configures the HTTP request and optionally the HTTP response that are used to resolve data for the given `parent-type` and `field`. | Yes |

+| `http-request` | Specifies a URL and child policies to configure the resolver's HTTP request. Each child element can be specified at most once. | Yes |

+| `set-method`| Method of the resolver's HTTP request, configured using the [set-method](api-management-advanced-policies.md#SetRequestMethod) policy. | Yes |

+| `set-url` | URL of the resolver's HTTP request. | Yes |

+| `set-header` | Header set in the resolver's HTTP request, configured using the [set-header](api-management-transformation-policies.md#SetHTTPheader) policy. | No |

+| `set-body` | Body set in the resolver's HTTP request, configured using the [set-body](api-management-transformation-policies.md#SetBody) policy. | No |

+| `authentication-certificate` | Client certificate presented in the resolver's HTTP request, configured using the [authentication-certificate](api-management-authentication-policies.md#ClientCertificate) policy. | No |

+| `http-response` | Optionally specifies child policies to configure the resolver's HTTP response. If not specified, the response is returned as a raw string. Each child element can be specified at most once. |

+| `json-to-xml` | Transforms the resolver's HTTP response using the [json-to-xml](api-management-transformation-policies.md#ConvertJSONtoXML) policy. | No |

+| `xml-to-json` | Transforms the resolver's HTTP response using the [xml-to-json](api-management-transformation-policies.md#ConvertJSONtoXML) policy. | No |

+| `find-and-replace` | Transforms the resolver's HTTP response using the [find-and-replace](api-management-transformation-policies.md#Findandreplacestringinbody) policy. | No |

+### Attributes

+| Name | Description | Required | Default |

+| -- | - | -- | - |

+| `parent-type`| An object type in the GraphQL schema. | Yes | N/A |

+| `field`| A field of the specified `parent-type` in the GraphQL schema. | Yes | N/A |

+> [!NOTE]

+> Currently, the values of `parent-type` and `field` aren't validated by this policy. If they aren't valid, the policy is ignored, and the GraphQL query is forwarded to a GraphQL endpoint (if one is configured).

+### Usage

+This policy can be used in the following policy [sections](./api-management-howto-policies.md#sections) and [scopes](./api-management-howto-policies.md#scopes).

+- **Policy sections:** backend

+- **Policy scopes:** all scopes

+### GraphQL Context

+* The context for the HTTP request and HTTP response (if specified) differs from the context for the original gateway API request:

+ * `context.ParentResult` is set to the parent object for the current resolver execution.

+ * The HTTP request context contains arguments that are passed in the GraphQL query as its body.

+ * The HTTP response context is the response from the independent HTTP call made by the resolver, not the context for the complete response for the gateway request.

+The `context` variable that is passed through the request and response pipeline is augmented with the GraphQL context when used with `<set-graphql-resolver>` policies.

+#### ParentResult

+The `context.ParentResult` is set to the parent object for the current resolver execution. Consider the following partial schema:

+``` graphql

+type Comment {

+ id: ID!

+ owner: string!

+ content: string!

+}

+type Blog {

+ id: ID!

+ Title: string!

+ content: string!

+ comments: [Comment]!

+ comment(id: ID!): Comment

+}

+type Query {

+ getBlog(): [Blog]!

+ getBlog(id: ID!): Blog

+}

+```

+Also, consider a GraphQL query for all the information for a specific blog:

+``` graphql

+query {

+ getBlog(id: 1) {

+ title

+ content

+ comments {

+ id

+ owner

+ content

+ }

+ }

+}

+```

+If you set a resolver for `parent-type="Blog" field="comments"`, you will want to understand which blog ID to use. You can get the ID of the blog using `context.ParentResult.AsJObject()["id"].ToString()`. The policy for configuring this resolver would resemble:

+``` xml

+<set-graphql-resolver parent-type="Blog" field="comments">

+ <http-data-source>

+ <http-request>

+ <set-method>GET</set-method>

+ <set-url>@{

+ var blogId = context.ParentResult.AsJObject()["id"].ToString();

+ return $"https://data.contoso.com/api/blog/{blogId}";

+ }</set-url>

+ </http-request>

+ </http-data-source>

+</set-graphql-resolver>

+```

+#### Arguments

+The arguments for a parameterized GraphQL query are added to the body of the request. For example, consider the following two queries:

+``` graphql

+query($id: Int) {

+ getComment(id: $id) {

+ content

+ }

+}

+query {

+ getComment(id: 2) {

+ content

+ }

+}

+```

+These queries are two ways of calling the `getComment` resolver. GraphQL sends the following JSON payload:

+``` json

+{

+ "query": "query($id: Int) { getComment(id: $id) { content } }",

+ "variables": { "id": 2 }

+}

+{

+ "query": "query { getComment(id: 2) { content } }"

+}

+```

+When the resolver is executed, the `arguments` property is added to the body. You can define the resolver as follows:

+``` xml

+<set-graphql-resolver parent-type="Blog" field="comments">

+ <http-data-source>

+ <http-request>

+ <set-method>GET</set-method>

+ <set-url>@{

+ var commentId = context.Request.Body.As<JObject>(true)["arguments"]["id"];

+ return $"https://data.contoso.com/api/comment/{commentId}";

+ }</set-url>

+ </http-request>

+ </http-data-source>

+</set-graphql-resolver>

+```

+

+### More examples

+#### Resolver for GraphQL query

+##### Example schema

+##### Example policy

+#### Resolver for a GraqhQL query that returns a list, using a liquid template

+The following example uses a liquid template, supported for use in the [set-body](api-management-transformation-policies.md#SetBody) policy, to return a list in the HTTP response to a query. It also renames the `username` field in the response from the REST API to `name` in the GraphQL response.

+##### Example schema

+##### Example policy

+ "name": "{{elem.username}}"

+#### Resolver for GraphQL mutation

+The following example resolves a mutation that inserts data by making a `POST` request to an HTTP data source. The policy expression in the `set-body` policy of the HTTP request modifies a `name` argument that is passed in the GraphQL query as its body. The body that is sent will look like the following JSON:

+``` json

+{

+ "name": "the-provided-name"

+}

+```

+##### Example schema

+##### Example policy

+ var args = context.Request.Body.As<JObject>(true)["arguments"];

+ jsonObject.Add("name", args["name"])

+The following example sets the root path `/` to the `public` subdirectory (which works for Laravel), and also adds a second virtual application at the `/app2` path. To run it, create a file called `json.txt` with the following contents.

+```txt

+[

+ {

+ "physicalPath"':' "site\\wwwroot\\public",

+ "preloadEnabled"':' false,

+ "virtualDirectories"':' null,

+ "virtualPath"':' "/"

+ },

+ {

+ "physicalPath"':' "site\\wwwroot\\app2",

+ "preloadEnabled"':' false,

+ "virtualDirectories"':' null,

+ "virtualPath"':' "/app2"

+ }

+]

+```

+Change `<group-name>` and `<app-name>` for your resources and run the following command. Be aware of escape characters when running this command. For more information on escape characters, see [Tips for using the Azure CLI successfully](/cli/azure/use-cli-effectively).

+az resource update --resource-group <group-name> --resource-type Microsoft.Web/sites/config --name <app-name>/config/web --set properties.virtualApplications="@json.txt"

+zone_pivot_groups: app-service-containers-windows-linux-portal

+[WordPress](https://www.wordpress.org) is an open source content management system (CMS) that can be used to create websites, blogs, and other applications. Over 40% of the web uses WordPress from blogs to major news websites.

+In this quickstart, you'll learn how to create and deploy your first [WordPress](https://www.wordpress.org) site to [Azure App Service on Linux](overview.md#app-service-on-linux) using [Azure portal](https://portal.azure.com). It uses the **Basic** tier and [**incurs a cost**](https://azure.microsoft.com/pricing/details/app-service/linux/) for your Azure subscription. The WordPress installation comes with pre-installed plugins for performance improvements, [W3TC](https://wordpress.org/plugins/w3-total-cache/) for caching and [Smush](https://wordpress.org/plugins/wp-smushit/) for image compression.

+> [After November 28, 2022, PHP will only be supported on App Service on Linux.](https://github.com/Azure/app-service-linux-docs/blob/master/Runtime_Support/php_support.md#end-of-life-for-php-74) Due to this reason, this article deploys WordPress to App Service on Linux.

+1. Sign in to the Azure portal at https://portal.azure.com.

+1. Under **Instance details**, type a globally unique name for your web app and choose **Linux** for **Operating System**. Select **Basic** for **Hosting plan**. See the table below for app and database SKUs for given hosting plans. You can view [hosting plans details in the announcement](https://techcommunity.microsoft.com/t5/apps-on-azure-blog/the-new-and-better-wordpress-on-app-service/ba-p/3202594). For pricing, visit [App Service pricing](https://azure.microsoft.com/pricing/details/app-service/linux/) and [Azure Database for MySQL pricing](https://azure.microsoft.com/pricing/details/mysql/flexible-server/).

+1. Select the **Advanced** tab. Under **Additional Settings** choose your preferred **Site Language** and **Content Distribution**. If you're unfamiliar with a [Content Delivery Network](../cdn/cdn-overview.md) or [Blob Storage](../storage/blobs/storage-blobs-overview.md), select **Disabled**. For more details on the Content Distribution options, see [WordPress on App Service](https://azure.github.io/AppService/2022/02/23/WordPress-on-App-Service-Public-Preview.html).

+ :::image type="content" source="./media/quickstart-wordpress/08-wordpress-advanced-settings.png" alt-text="Screenshot of WordPress Advanced Settings":::

+ :::image type="content" source="./media/quickstart-wordpress/09-wordpress-create.png?text=WordPress create button" alt-text="Screenshot of WordPress create button":::

+ > App Service creates environment variables and application settings needed for WordPress/PHP configuration. For more information on customizing environment variables, see the WordPress section in [Environment variables and app settings in Azure App Service](reference-app-settings.md#wordpress).

+> [!div class="nextstepaction"]

+> [Tutorial: Map a custom domain name](app-service-web-tutorial-custom-domain.md)

+> [!NOTE]

+> Bicep files use the same underlying engine as ARM templates. All of the tips, notes, and important information found in the [ARM template quickstart](./quickstart-resource-manager.md) apply here. It's recommended to reference this information when working with Bicep files.

+You can connect to Azure Fluid Relay by providing the tenant ID and key that is uniquely generated for you when creating the Azure resource. You can build your own token provider implementation or you can use the two token provider implementations that the Fluid Framework provides: [InsecureTokenProvider](https://fluidframework.com/docs/apis/test-client-utils/insecuretokenprovider) and [AzureFunctionTokenProvider](https://fluidframework.com/docs/apis/azure-client/azurefunctiontokenprovider).

+- **Storage isolation** ΓÇô To ensure cryptographic certainty of logical data isolation, Azure Storage relies on data encryption at rest using advanced algorithms with multiple ciphers. This process relies on multiple encryption keys and services such as Azure Key Vault and Azure AD to ensure secure key access and centralized key management. Azure Storage service encryption ensures that data is automatically encrypted before persisting it to Azure Storage and decrypted before retrieval. All data written to Azure Storage is [encrypted through FIPS 140 validated 256-bit AES encryption](../storage/common/storage-service-encryption.md#about-azure-storage-service-side-encryption) and you can use Key Vault for customer-managed keys (CMK). Azure Storage service encryption encrypts the page blobs that store Azure Virtual Machine disks. Moreover, Azure Disk encryption may optionally be used to encrypt Azure Windows and Linux IaaS Virtual Machine disks to increase storage isolation and assure cryptographic certainty of your data stored in Azure. This encryption includes managed disks.

+Storage service encryption is enabled by default for all new and existing storage accounts and it [can't be disabled](../storage/common/storage-service-encryption.md#about-azure-storage-service-side-encryption). As shown in Figure 17, the encryption process uses the following keys to help ensure cryptographic certainty of data isolation at rest:

+ Title: Filled map in Azure Maps Power BI Visual

+description: In this article, you'll learn about the Filled map feature in Azure Maps Power BI Visual.

+# Filled map in Azure Maps Power BI Visual (Preview)

+Filled maps use varying degrees of shading, tinting or different patterns to provide a visual display that quickly shows differences in values across a geography or region. Showing these relative differences with shading that ranges from light (less-frequent/lower) to dark (more-frequent/more) is a useful way to quickly convey pertinent information to viewers.

+<!--

+

+-->

+The image above shows an example of a filled map. The map of America shows each state with a different shade that represents the sales by state. A viewer can immediately see that California has the most sales followed by Texas, then Florida.

+## When to use a filled map

+Filled maps can be a great choice:

+* To display quantitative information on a map.

+* To show spatial patterns and relationships.

+* When your data is standardized.

+* When working with socioeconomic data.

+* When defined regions are important.

+* To get an overview of the distribution across geographic locations.

+Some common uses for filled maps include:

+* Visualize sales or revenue results by country or state.

+* Visualize election results where the color represents the party that won and the shading represent the margin of victory.

+* Visualize unemployment rates by region, state or county.

+## Prerequisites

+This article uses [Sales and Marketing Sample PBIX](https://download.microsoft.com/download/9/7/6/9767913A-29DB-40CF-8944-9AC2BC940C53/Sales%20and%20Marketing%20Sample%20PBIX.pbix) as the data source for demonstration purposes. You can create a new report using this data before continuing if you wish to follow along.

+## Filled map settings

+There are two places where you can adjust filled maps settings: Build and format visuals. Both are located in the **Visualizations** pane.

+### Build visuals

+| Setting Name | Description | Setting values |

+|--|||

+| Shape | Configure fill transparency in a geometry on the map | 0-100% |

+| Colors | Use meters or pixels as unit to visualize the data. Default: Pixels | Set colors for different data category or gradient for numeric data.|

+| Border | Sets the border color, width and transparency | Color picker<BR>Width 1-10 pixels<BR>Transparency 0-100% |

+| Min zoom | Minimum zoom level the layer is visible at. Default: 0 | Integer (0 - 22) |

+| Max zoom | Maximum zoom level the layer is visible at. Default: 22 | Integer (0 - 22) |

+| Options | Specify the position of the layer relative to other map layers | Drop down menu:<BR>Above labels<BR>Below labels<BR>Below roads |

+> [!TIP]

+> You can use **Conditional formatting** in the **Colors** setting to set the field that your map is based on, as demonstrated in the [Create a filled map](#create-a-filled-map) section below.

+### Format visuals

+| Bucket | Description |

+|-|-|

+| Location | Geospatial area with a boundary, such as country, state, city, county or postal code. Street and address aren't supported in filled map. |

+| Legend | Categorical data that will be used to shade the map. |

+| Tool Tips (optional) | Determined the data/columns that would be shown in tool tips |

+## Create a filled map

+1. From the **Fields** pane, select the **Geo > State** field. Notice that it populates the **Location** field in the **Visualizations** pane.

+ <!--

+ 

+ -->

+ :::image type="content" source="media/power-bi-visual/filled-map-geo-state.png" alt-text="A screenshot showing the selection of the state field from the geo table.":::

+1. Select **Sales $** from the **SalesFact** table and drag it to the **Tooltips** field in the **Visualizations** pane.

+1. In the **Visualizations** pane, select **Format your visual**

+1. Set **Filled map** to **On**

+ <!--

+ 

+ -->

+ :::image type="content" source="media/power-bi-visual/filled-map-visualization-setting.png" alt-text="A screenshot showing the filled maps option in the visualizations pane in the Format your visual view.":::

+1. Select **Filled maps** to expand that section then select **Colors**.

+1. Select **Conditional formatting**.

+ <!--

+ 

+ -->

+ :::image type="content" source="media/power-bi-visual/filled-map-conditional-formatting.png" alt-text="A screenshot showing the Conditional formatting button in the colors section.":::

+1. The **Default color - Filled map** dialog should appear, select the **What field should we base this on?** Drop down, then select **Sales $** from the **SalesFact** table.

+ <!--

+ 

+ -->

+ :::image type="content" source="media/power-bi-visual/filled-map-sales.png" lightbox="media/power-bi-visual/filled-map-sales.png" alt-text="A screenshot showing Default color - Filled map dialog box with sales selected from the What field should we base this on? Drop down.":::

+1. Set the **Minimum** color to white then select the **OK** button.

+ > The map should appear with varying degrees of shading depicting the relative sales. Since this data only includes numbers for the continental United States, you can filter out Alaska if you wish.

+1. Filter the map to display only the continental United States.

+ a. To the left of the "Visualizations" pane, look for the "Filters" pane. Expand it if it's minimized.

+ b. Hover over **State** and select the expand chevron.

+ c. Place a check mark next to **Select all** and remove the check mark next to **AK**.

+ :::image type="content" source="media/power-bi-visual/filled-map-us-minus-alaska.png" lightbox="media/power-bi-visual/filled-map-us-minus-alaska.png" alt-text="A screenshot showing a map of America with states colored in teal with varying degrees of shading depending on the amount of sales attained in each state.":::

+ <!--

+ 

+ -->

+## Next steps

+Change how your data is displayed on the map:

+> [!div class="nextstepaction"]

+> [Add a bar chart layer](power-bi-visual-add-bar-chart-layer.md)

+> [!div class="nextstepaction"]

+> [Add a heat map layer](power-bi-visual-add-heat-map-layer.md)

+Add more context to the map:

+> [!div class="nextstepaction"]

+> [Add a reference layer](power-bi-visual-add-reference-layer.md)

+> [!div class="nextstepaction"]

+> [Add a tile layer](power-bi-visual-add-tile-layer.md)

+> [!div class="nextstepaction"]

+> [Show real-time traffic](power-bi-visual-show-real-time-traffic.md)

+Customize the visual:

+> [!div class="nextstepaction"]

+> [Tips and tricks for color formatting in Power BI](/power-bi/visuals/service-tips-and-tricks-for-color-formatting)

+> [!div class="nextstepaction"]

+> [Customize visualization titles, backgrounds, and legends](/power-bi/visuals/power-bi-visualization-customize-title-background-and-legend)

+| Debian 11 ¹ | X | | | |

+| Red Hat Enterprise Linux Server 8.5, 8.6 | X | | | |

+| Red Hat Enterprise Linux Server 8, 8.1, 8.2, 8.3, 8.4 | X ³ | X | X | |

+| April 2022 | <ul><li>Private IP information added in Log Analytics <i>Heartbeat</i> table for Windows and Linux</li><li>Fixed bugs in Windows IIS log collection (preview) <ul><li>Updated IIS site column name to match backend KQL transform</li><li>Added delay to IIS upload task to account for IIS buffering</li></ul></li><li>Fixed Linux CEF syslog forwarding for Sentinel</li><li>Removed 'error' message for Azure MSI token retrieval failure on Arc to show as 'Info' instead</li><li>Support added for Ubuntu 22.04, RHEL 8.5, 8.6, AlmaLinux and RockyLinux distros</li></ul> | 1.4.1.0^Hotfix | 1.19.3 |

+Azure Monitor agent is available in all public regions and Azure Government clouds. It is not yet supported in Air-gapped clouds. See here for [product availability by region](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fazure.microsoft.com%2Fen-us%2Fglobal-infrastructure%2Fservices%2F%3Fproducts%3Dmonitor%26rar%3Dtrue%26regions%3Dall&data=05%7C01%7Cjeffwo%40microsoft.com%7Cf8f9cf9cebdd4cf5794308da6368792e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637931597629278725%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=VJzaLPOJlBqyOHS0zmvyHMdviIjIGAWCmVD%2FWJZjUIA%3D&reserved=0)

+If you don't have alert rules defined for the selected resource, you can [enable recommended out-of-the-box alert rules in the Azure portal](alerts-page.md#alert-rule-recommendations-preview).

+You can query your alerts instances to create custom views outside of the Azure portal, or to analyze your alerts to identify patterns and trends.

+We recommended that you use [Azure Resource Graphs](https://portal.azure.com/?feature.customportal=false#blade/HubsExtension/ArgQueryBlade) with the 'AlertsManagementResources' schema for managing alerts across multiple subscriptions. For a sample query, see [Azure Resource Graph sample queries for Azure Monitor](../resource-graph-samples.md).

+If you don't have alert rules defined for the selected resource, either individually or as part of a resource group or subscription, you can [create a new alert rule](alerts-log.md#create-a-new-log-alert-rule-in-the-azure-portal), or enable recommended out-of-the-box alert rules in the Azure portal.

+The system compiles a list of recommended alert rules based on:

+- The resource providerΓÇÖs knowledge of important signals and thresholds for monitoring the resource.

+- Telemetry that tells us what customers commonly alert on for this resource.

+To enable recommended alert rules:

+1. On the **Alerts** page, select **Enable recommended alert rules**. The **Enable recommended alert rules** pane opens with a list of recommended alert rules based on your type of resource.

+1. In the **Alert me if** section, select all of the rules you want to enable. The rules are populated with the default values for the rule condition, such as the percentage of CPU usage that you want to trigger an alert. You can change the default values if you would like.

+1. In the **Notify me by** section, select the way you want to be notified if an alert is fired.

+1. Select **Enable**.

+> ΓÜá JRE is not supported.

+> [!TIP]

+> ΓÜá Read-only file system is not supported.

+> [!TIP]

+> ΓÜá The invocation must be requested at the beginning of the `main` method.

+> With a programmatic configuration, the `applicationinsights.log` file containing the agent logs is located in the directory from where the JVM is launched (user directory). This default behavior can be changed (see the _Self-diagnostics_ part of [this page](../app/java-standalone-config.md)).

+You can remove any installed monitoring solution, except **LogManagment**, which is a built-in solution that contains the schemas that aren't associated to a specific solution.

+* See all [Azure CLI commands for Azure Monitor](/cli/azure/azure-cli-reference-for-monitor).

+Azure Monitor ensures that all data and saved queries are encrypted at rest using Microsoft-managed keys (MMK). You also have the option to encrypt data with your own key in [Azure Key Vault](../../key-vault/general/overview.md), with control over key lifecycle and ability to revoke access to your data at any time. Azure Monitor use of encryption is identical to the way [Azure Storage encryption](../../storage/common/storage-service-encryption.md#about-azure-storage-service-side-encryption) operates.

+You need to have "write" permissions on your workspace and cluster to perform this operation. It includes `Microsoft.OperationalInsights/workspaces/write` and `Microsoft.OperationalInsights/clusters/write`.

+- Explicit key version updateΓÇöupdate your cluster with key version in ```"keyVersion"``` property. Rotation of keys requires an explicit ```"keyVaultProperties"``` update in cluster, see [Update cluster with Key identifier details](#update-cluster-with-key-identifier-details). If you generate new key version in Key Vault but don't update it in the cluster, the cluster storage will keep using your previous key. If you disable or delete the old key before updating a new one in the cluster, you will get into [key revocation](#key-revocation) state.

+When linking your own storage (BYOS) to workspace, the service stores *saved-searches* and *log alerts* queries to your Storage Account. With the control on Storage Account and the [encryption-at-rest policy](../../storage/common/customer-managed-keys-overview.md), you can protect *saved-searches* and *log alerts* with Customer-managed key. You will, however, be responsible for the costs associated with that Storage Account.

+* Fired log alerts will not contain search results or alert query. You can use [alert dimensions](../alerts/alerts-unified-log.md#split-by-alert-dimensions) to get context in the fired alerts.

+ - Double encryption settings can not be changed after the cluster has been created.

+- [Search jobs asynchronous queries](./search-jobs.md) aren't supported in Customer-managed key scenario currently.

+ - 400 ΓÇö Cluster is in deleting state. Async operation is in progress. Cluster must complete its operation before any update operation is performed.

+Using criteria parameters, you can define a set of criteria based on previously specified parameters which will be evaluated to provide a dynamic value. The main benefit of using criteria parameters is that criteria parameters can resolve values of previously specified parameters and perform simple conditional operations without making any network calls. Below is an example of such a use case.

+## Set up criteria

+ > The first parameter in the workbook will not show the `Criteria` tab.

+1. A grid appears. Select **Edit** next to the blank text box to open the 'Criteria Settings' form. Refer to [Criteria Settings form](#criteria-settings-form) for the description of each field.

+ Title: Sample Azure Workbooks with links

+description: See sample Azure Workbooks.

+# Sample Azure Workbooks

+This article includes sample Azure Workbooks.

+## Sample JSON Path parameter workbook

+```json

+{

+ "version": "Notebook/1.0",

+ "items": [

+ {

+ "type": 9,

+ "content": {

+ "version": "KqlParameterItem/1.0",

+ "parameters": [

+ {

+ "id": "f2552663-d809-40da-93c4-9618dfde9b1d",

+ "version": "KqlParameterItem/1.0",

+ "name": "selection",

+ "type": 1,

+ "value": "{ \"series\":\"Failures\", \"x\": 5, \"y\": 10}"

+ }

+ ],

+ "style": "above",

+ "queryType": 0,

+ "resourceType": "microsoft.operationalinsights/workspaces"

+ },

+ "name": "parameters - 1"

+ },

+ {

+ "type": 1,

+ "content": {

+ "json": "For example, you may have a string parameter named `selection` that was the result of a query or selection in a visualization that has the following value \r\n```json\r\n{selection:json}\r\n```\r\n\r\nUsing JSONPath, you could get individual values from that object:\r\n\r\nformat | result\r\n|\r\n`selection:$.series` | `{selection:$..series}`\r\n`selection:$.x` | `{selection:$..x}`\r\n`selection$.y`| `{selection:$..y}`"

+ },

+ "name": "text - 0"

+ }

+ ],

+ "$schema": "https://github.com/Microsoft/Application-Insights-Workbooks/blob/master/schema/workbook.json"

+}

+```

+## Sample ARM template for creating a workbook template

+```json

+{

+ "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",

+ "contentVersion": "1.0.0.0",

+ "parameters": {

+ "resourceName": {

+ "type": "string",

+ "defaultValue": "test-template",

+ "metadata": {

+ "description": "The unique name for this workbook template instance"

+ }

+ }

+ },

+ "resources": [

+ {

+ "name": "[parameters('resourceName')]",

+ "type": "microsoft.insights/workbooktemplates",

+ "location": "[resourceGroup().location]",

+ "apiVersion": "2019-10-17-preview",

+ "dependsOn": [],

+ "properties": {

+ "priority": 1,

+ "galleries": [

+ {

+ "name": "A Workbook Template",

+ "category": "Deployed Templates",

+ "order": 100,

+ "type": "workbook",

+ "resourceType": "Azure Monitor"

+ }

+ ],

+ "templateData": {

+ "version": "Notebook/1.0",

+ "items": [

+ {

+ "type": 1,

+ "content": {

+ "json": "## New workbook\n\n\nWelcome to your new workbook. This area will display text formatted as markdown.\n\n\nWe've included a basic analytics query to get you started. Use the `Edit` button below each section to configure it or add more sections."

+ },

+ "name": "text - 2"

+ },

+ {

+ "type": 3,

+ "content": {

+ "version": "KqlItem/1.0",

+ "query": "union withsource=[\"$TableName\"] *\n| summarize Count=count() by TableName=[\"$TableName\"]\n| render barchart",

+ "size": 1,

+ "exportToExcelOptions": "visible",

+ "queryType": 0,

+ "resourceType": "microsoft.operationalinsights/workspaces"

+ },

+ "name": "query - 2"

+ }

+ ],

+ "styleSettings": {},

+ "$schema": "https://github.com/Microsoft/Application-Insights-Workbooks/blob/master/schema/workbook.json"

+ }

+ }

+ }

+ ]

+}

+```

+## Sample workbook with links

+```json

+{

+ "version": "Notebook/1.0",

+ "items": [

+ {

+ "type": 11,

+ "content": {

+ "version": "LinkItem/1.0",

+ "style": "tabs",

+ "links": [

+ {

+ "cellValue": "selectedTab",

+ "linkTarget": "parameter",

+ "linkLabel": "Tab 1",

+ "subTarget": "1",

+ "style": "link"

+ },

+ {

+ "cellValue": "selectedTab",

+ "linkTarget": "parameter",

+ "linkLabel": "Tab 2",

+ "subTarget": "2",

+ "style": "link"

+ }

+ ]

+ },

+ "name": "links - 0"

+ },

+ {

+ "type": 1,

+ "content": {

+ "json": "# selectedTab is {selectedTab}\r\n(this text step is always visible, but shows the value of the `selectedtab` parameter)"

+ },

+ "name": "always visible text"

+ },

+ {

+ "type": 1,

+ "content": {

+ "json": "## content only visible when `selectedTab == 1`"

+ },

+ "conditionalVisibility": {

+ "parameterName": "selectedTab",

+ "comparison": "isEqualTo",

+ "value": "1"

+ },

+ "name": "selectedTab 1 text"

+ },

+ {

+ "type": 1,

+ "content": {

+ "json": "## content only visible when `selectedTab == 2`"

+ },

+ "conditionalVisibility": {

+ "parameterName": "selectedTab",

+ "comparison": "isEqualTo",

+ "value": "2"

+ },

+ "name": "selectedTab 2"

+ }

+ ],

+ "styleSettings": {},

+ "$schema": "https://github.com/Microsoft/Application-Insights-Workbooks/blob/master/schema/workbook.json"

+}

+```

+## Sample workbook with toolbar links

+```json

+{

+ "version": "Notebook/1.0",

+ "items": [

+ {

+ "type": 9,

+ "content": {

+ "version": "KqlParameterItem/1.0",

+ "crossComponentResources": [

+ "value::all"

+ ],

+ "parameters": [

+ {

+ "id": "eddb3313-641d-4429-b467-4793d6ed3575",

+ "version": "KqlParameterItem/1.0",

+ "name": "Subscription",

+ "type": 6,

+ "isRequired": true,

+ "multiSelect": true,

+ "quote": "'",

+ "delimiter": ",",

+ "query": "where type =~ \"microsoft.web/sites\"\r\n| summarize count() by subscriptionId\r\n| order by subscriptionId asc\r\n| project subscriptionId, label=subscriptionId, selected=row_number()==1",

+ "crossComponentResources": [

+ "value::all"

+ ],

+ "value": [],

+ "typeSettings": {

+ "additionalResourceOptions": [],

+ "showDefault": false

+ },

+ "timeContext": {

+ "durationMs": 86400000

+ },

+ "queryType": 1,

+ "resourceType": "microsoft.resourcegraph/resources"

+ },

+ {

+ "id": "8beaeea6-9550-4574-a51e-bb0c16e68e84",

+ "version": "KqlParameterItem/1.0",

+ "name": "site",

+ "type": 5,

+ "description": "global parameter set by selection in the grid",

+ "isRequired": true,

+ "isGlobal": true,

+ "query": "where type =~ \"microsoft.web/sites\"\r\n| project id",

+ "crossComponentResources": [

+ "{Subscription}"

+ ],

+ "isHiddenWhenLocked": true,

+ "typeSettings": {

+ "additionalResourceOptions": [],

+ "showDefault": false

+ },

+ "timeContext": {

+ "durationMs": 86400000

+ },

+ "queryType": 1,

+ "resourceType": "microsoft.resourcegraph/resources"

+ },

+ {

+ "id": "0311fb5a-33ca-48bd-a8f3-d3f57037a741",

+ "version": "KqlParameterItem/1.0",

+ "name": "properties",

+ "type": 1,

+ "isRequired": true,

+ "isGlobal": true,

+ "isHiddenWhenLocked": true

+ }

+ ],

+ "style": "above",

+ "queryType": 1,

+ "resourceType": "microsoft.resourcegraph/resources"

+ },

+ "name": "parameters - 0"

+ },

+ {

+ "type": 11,

+ "content": {

+ "version": "LinkItem/1.0",

+ "style": "toolbar",

+ "links": [

+ {

+ "id": "7ea6a29e-fc83-40cb-a7c8-e57f157b1811",

+ "cellValue": "{site}",

+ "linkTarget": "ArmAction",

+ "linkLabel": "Start",

+ "postText": "Start website {site:name}",

+ "style": "primary",

+ "icon": "Start",

+ "linkIsContextBlade": true,

+ "armActionContext": {

+ "pathSource": "static",

+ "path": "{site}/start",

+ "headers": [],

+ "params": [

+ {

+ "key": "api-version",

+ "value": "2019-08-01"

+ }

+ ],

+ "isLongOperation": false,

+ "httpMethod": "POST",

+ "titleSource": "static",

+ "title": "Start {site:name}",

+ "descriptionSource": "static",

+ "description": "Attempt to start:\n\n{site:grid}",

+ "resultMessage": "Start {site:name} completed",

+ "runLabelSource": "static",

+ "runLabel": "Start"

+ }

+ },

+ {

+ "id": "676a0860-6ec8-4c4f-a3b8-a98af422ae47",

+ "cellValue": "{site}",

+ "linkTarget": "ArmAction",

+ "linkLabel": "Stop",

+ "postText": "Stop website {site:name}",

+ "style": "primary",

+ "icon": "Stop",

+ "linkIsContextBlade": true,

+ "armActionContext": {

+ "pathSource": "static",

+ "path": "{site}/stop",

+ "headers": [],

+ "params": [

+ {

+ "key": "api-version",

+ "value": "2019-08-01"

+ }

+ ],

+ "isLongOperation": false,

+ "httpMethod": "POST",

+ "titleSource": "static",

+ "title": "Stop {site:name}",

+ "descriptionSource": "static",

+ "description": "# Attempt to Stop:\n\n{site:grid}",

+ "resultMessage": "Stop {site:name} completed",

+ "runLabelSource": "static",

+ "runLabel": "Stop"

+ }

+ },

+ {

+ "id": "5e48925f-f84f-4a2d-8e69-6a4deb8a3007",

+ "cellValue": "{properties}",

+ "linkTarget": "CellDetails",

+ "linkLabel": "Properties",

+ "postText": "View the properties for Start website {site:name}",

+ "style": "secondary",

+ "icon": "Properties",

+ "linkIsContextBlade": true

+ }

+ ]

+ },

+ "name": "site toolbar"

+ },

+ {

+ "type": 3,

+ "content": {

+ "version": "KqlItem/1.0",

+ "query": "where type =~ \"microsoft.web/sites\"\r\n| extend properties=tostring(properties)\r\n| project-away name, type",

+ "size": 0,

+ "showAnalytics": true,

+ "title": "Web Apps in Subscription {Subscription:name}",

+ "showRefreshButton": true,

+ "exportedParameters": [

+ {

+ "fieldName": "id",

+ "parameterName": "site"

+ },

+ {

+ "fieldName": "",

+ "parameterName": "properties",

+ "parameterType": 1

+ }

+ ],

+ "showExportToExcel": true,

+ "queryType": 1,

+ "resourceType": "microsoft.resourcegraph/resources",

+ "crossComponentResources": [

+ "{Subscription}"

+ ],

+ "gridSettings": {

+ "formatters": [

+ {

+ "columnMatch": "properties",

+ "formatter": 5

+ }

+ ],

+ "filter": true,

+ "sortBy": [

+ {

+ "itemKey": "subscriptionId",

+ "sortOrder": 1

+ }

+ ]

+ },

+ "sortBy": [

+ {

+ "itemKey": "subscriptionId",

+ "sortOrder": 1

+ }

+ ]

+ },

+ "name": "query - 1"

+ },

+ {

+ "type": 1,

+ "content": {

+ "json": "## How this workbook works\r\n1. The parameters step declares a `site` resource parameter that is hidden in reading mode, but uses the same query as the grid. this parameter is marked `global`, and has no default selection. The parameters also declares a `properties` hidden text parameter. These parameters are [declared global](https://github.com/microsoft/Application-Insights-Workbooks/blob/master/Documentation/Parameters/Parameters.md#global-parameters) so they can be set by the grid below, but the toolbar can appear *above* the grid.\r\n\r\n2. The workbook has a links step, that renders as a toolbar. This toolbar has items to start a website, stop a website, and show the Azure Resourcve Graph properties for that website. The toolbar buttons all reference the `site` parameter, which by default has no selection, so the toolbar buttons are disabled. The start and stop buttons use the [ARM Action](https://github.com/microsoft/Application-Insights-Workbooks/blob/master/Documentation/Links/LinkActions.md#arm-action-settings) feature to run an action against the selected resource.\r\n\r\n3. The workbook has an Azure Resource Graph (ARG) query step, which queries for web sites in the selected subscriptions, and displays them in a grid. When a row is selected, the selected resource is exported to the `site` global parameter, causing start and stop buttons to become enabled. The ARG properties are also exported to the `properties` parameter, causing the poperties button to become enabled.",

+ "style": "info"

+ },

+ "conditionalVisibility": {

+ "parameterName": "debug",

+ "comparison": "isEqualTo",

+ "value": "true"

+ },

+ "name": "text - 3"

+ }

+ ],

+ "fallbackResourceIds": [

+ "Azure Monitor"

+ ],

+ "$schema": "https://github.com/Microsoft/Application-Insights-Workbooks/blob/master/schema/workbook.json"

+}

+```

+### Financial analytics and trading

+* [Host a Murex MX.3 workload on Azure](/azure/architecture/example-scenario/finance/murex-mx3-azure)

+| | Contributor | Resource group in which VM will be deployed | Alternatively, instead of a built-in-role, you can consider a custom role which has the following permissions: Microsoft.Resources/subscriptions/resourceGroups/write Microsoft.DomainRegistration/domains/write (required only for classic VM restore and not required for managed VMs), Microsoft.Compute/virtualMachines/write Microsoft.Compute/virtualMachines/read Microsoft.Network/virtualNetworks/read Microsoft.Network/virtualNetworks/subnets/read Microsoft.Network/virtualNetworks/subnets/join/action |

+* [Azure role-based access control troubleshooting](../role-based-access-control/troubleshooting.md): Get suggestions for fixing common issues.

+## Get the container name

+To get container name, run the following command. [Learn about this CLI command](/cli/azure/backup/container?view=azure-cli-latest#az-backup-container-list).

+```azurecli

+ az backup item list --resource-group <resource group name> --vault-name <vault name>

+```

+> During the public preview, RI is not supported.

+* Maximum of 16 bare metal nodes for public preview.

+* East US

+* West US 2

+| Rel 22-06 | [5014692] | Latest Cumulative Update(LCU) | [6.44] | Jun 14, 2022 |

+| Rel 22-06 | [5014678] | Latest Cumulative Update(LCU) | [7.12] | Jun 14, 2022 |

+| Rel 22-06 | [5014702] | Latest Cumulative Update(LCU) | [5.68] | Jun 14, 2022 |

+| Rel 22-06 | [5011486] | IE Cumulative Updates | [2.125], [3.112], [4.105] | Mar 8, 2022 |

+| Rel 22-06 | [5013641] | . NET Framework 3.5 and 4.7.2 Cumulative Update | [6.45] | May 10, 2022 |

+| Rel 22-06 | [5013630] | .NET Framework 4.8 Security and Quality Rollup | [7.13] | May 10, 2022 |

+| Rel 22-06 | [5014026] | Servicing Stack update | [5.69] | May 10, 2022 |

+| Rel 22-06 | [4494175] | Microcode | [5.69] | Sep 1, 2020 |

+| Rel 22-06 | [4494174] | Microcode | [6.45] | Sep 1, 2020 |

+| Rel 22-06 | [5013637] | .NET Framework 3.5 Security and Quality Rollup | [2.125] | Jun 14, 2022 |

+| Rel 22-06 | [5013644] | .NET Framework 4.6.2 Security and Quality Rollup | [2.125] | May 10, 2022 |

+| Rel 22-06 | [5013638] | .NET Framework 3.5 Security and Quality Rollup | [4.105] | Jun 14, 2022 |

+| Rel 22-06 | [5013643] | .NET Framework 4.6.2 Security and Quality Rollup | [4.105] | May 10, 2022 |

+| Rel 22-06 | [5013635] | .NET Framework 3.5 Security and Quality Rollup | [3.112] | Jun 14, 2022 |

+| Rel 22-06 | [5013642] | . NET Framework 4.6.2 Security and Quality Rollup | [3.112] | May 10, 2022 |

+| Rel 22-06 | [5014748] | Monthly Rollup | [2.125] | Jun 14, 2022 |

+| Rel 22-06 | [5014747] | Monthly Rollup | [3.112] | Jun 14, 2022 |

+| Rel 22-06 | [5014738] | Monthly Rollup | [4.105] | Jun 14, 2022 |

+| Rel 22-06 | [5014027] | Servicing Stack update | [3.112] | May 10, 2022 |

+| Rel 22-06 | [5014025] | Servicing Stack update | [4.105] | May 10, 2022 |

+| Rel 22-06 | [4578013] | Standalone Security Update | [4.105] | Aug 19, 2020 |

+| Rel 22-06 | [5011649] | Servicing Stack update | [2.125] | Mar 8, 2022 |

+[2.125]: ./cloud-services-guestos-update-matrix.md#family-2-releases

+[3.112]: ./cloud-services-guestos-update-matrix.md#family-3-releases

+[4.105]: ./cloud-services-guestos-update-matrix.md#family-4-releases

+[5.69]: ./cloud-services-guestos-update-matrix.md#family-5-releases

+[6.45]: ./cloud-services-guestos-update-matrix.md#family-6-releases

+[7.13]: ./cloud-services-guestos-update-matrix.md#family-7-releases

+###### **July 11, 2022**

+The June Guest OS has released.

+| WA-GUEST-OS-7.13_202206-01 | July 11, 2022 | Post 7.15 |

+|~~WA-GUEST-OS-7.11_202204-01~~| April 30, 2022 | July 11, 2022 |

+| WA-GUEST-OS-6.45_202206-01 | July 11, 2022 | Post 6.47 |

+|~~WA-GUEST-OS-6.43_202204-01~~| April 30, 2022 | July 11, 2022 |

+| WA-GUEST-OS-5.69_202206-01 | July 11, 2022 | Post 5.71 |

+|~~WA-GUEST-OS-5.67_202204-01~~| April 30, 2022 | July 11, 2022 |

+| WA-GUEST-OS-4.105_202206-02 | July 11, 2022 | Post 4.107 |

+| WA-GUEST-OS-4.103_202205-01 | May 26, 2022 | Post 4.106 |

+|~~WA-GUEST-OS-4.102_202204-01~~| April 30, 2022 | July 11, 2022 |

+| WA-GUEST-OS-3.112_202206-02 | July 11, 2022 | Post 3.114 |

+| WA-GUEST-OS-3.110_202205-01 | May 26, 2022 | Post 3.113 |

+|~~WA-GUEST-OS-3.109_202204-01~~| April 30, 2022 | July 11, 2022 |

+| WA-GUEST-OS-2.125_202206-02 | July 11, 2022 | Post 2.127 |

+| WA-GUEST-OS-2.123_202205-01 | May 26, 2022 | Post 2.126 |

+|~~WA-GUEST-OS-2.122_202204-01~~| April 30, 2022 | July 11, 2022 |

+As you design your bot in Power Virtual Agents, you can use [the Test bot pane](/power-virtual-agents/authoring-test-bot) to see how the bot leads a customer through the bot conversation.

+Publish your bot by following the steps in [Publish your bot](/power-virtual-agents/publication-fundamentals-publish-channels).

+Configure the demo website by following the steps in [Configure a chatbot for a live or demo website](/power-virtual-agents/publication-connect-bot-to-web-channels).

+| Bosnian (Bosnia and Herzegovina) | `bs-BA` |

+| Pashto (Afghanistan) | `ps-AF` |

+| French (Canada) | `fr-CA` |

+| Korean (Korea) | `ko-KR` |

+| Spanish (Mexico) | `es-MX` |

+|Estonian|`et-EE`|

+|Gujarati|`gu-IN`|

+|Irish|`ga-IE`|

+|Maltese|`mt-MT`|

+|Marathi|`mr-IN`|

+|Telugu|`te-IN`|

+|Ukrainian|`uk-UA`|

+* [**Multi-service**](https://portal.azure.com/#create/Microsoft.CognitiveServicesAllInOne) resource types enable access to multiple Cognitive Services using a single API key and endpoint.

+> [!NOTE]

+>

+> * For this quickstart it is recommended that you use a Translator text single-service subscription.

+> * With the single-service subscription you'll include one authorization header (**Ocp-Apim-Subscription-key**) with the REST API request. The value for Ocp-Apim-Subscription-key is your Azure secret key for your Translator Text subscription.

+> * If you choose to use the multi-service Cognitive Services subscription, it requires two authentication headers (**Ocp-Api-Subscription-Key** and **Ocp-Apim-Subscription-Region**). The value for Ocp-Apim-Subscription-Region is the region associated with your subscription.

+> * For more information on how to use the Ocp-Apim-Subscription-Region header, _see_ [Use the Text Translator APIs](translator-text-apis.md).

+* [**How-to guides**](translator-text-apis.md). Instructions for accessing and using the service in more specific or customized ways.

+| `TRUNCATE` | Yes |

+> [!VIDEO https://aka.ms/docs.continuous-backup-restore]

+ '/TenantId',

+ '/UserId',

+ '/SessionId'

+ "/TenantId",

+ "/UserId",

+ "/SessionId"

+The change feed processor is part of the Azure Cosmos DB [.NET V3](https://github.com/Azure/azure-cosmos-dotnet-v3) and [Java V4](https://github.com/Azure/azure-sdk-for-java/tree/main/sdk/cosmos/azure-cosmos) SDKs. It simplifies the process of reading the change feed and distributes the event processing across multiple consumers effectively.

+### [.NET](#tab/dotnet)

+If these three conditions apply, then the change feed processor will distribute all the leases in the lease container across all running instances of that deployment unit and parallelize compute using an equal distribution algorithm. One lease can only be owned by one instance at a given time, so the number of instances should not be greater than the number of leases.

+### [Java](#tab/java)

+An example of a delegate implementation would be:

+ [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeed/SampleChangeFeedProcessor.java?name=Delegate)]

+>[!NOTE]

+> In the above we pass a variable `options` of type `ChangeFeedProcessorOptions`, which can be used to set various values including `setStartFromBeginning`:

+> [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeed/SampleChangeFeedProcessor.java?name=ChangeFeedProcessorOptions)]

+We assign this to a `changeFeedProcessorInstance`, passing parameters of compute instance name (`hostName`), the monitored container (here called `feedContainer`) and the `leaseContainer`. We then start the change feed processor:

+ [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeed/SampleChangeFeedProcessor.java?name=StartChangeFeedProcessor)]

+>[!NOTE]

+> The above code snippets are taken from a sample in GitHub, which you can find [here](https://github.com/Azure-Samples/azure-cosmos-java-sql-api-samples/blob/main/src/main/java/com/azure/cosmos/examples/changefeed/SampleChangeFeedProcessor.java).

+## Processing life cycle

+The normal life cycle of a host instance is:

+1. Read the change feed.

+1. If there are no changes, sleep for a predefined amount of time (customizable with `options.setFeedPollDelay` in the Builder) and go to #1.

+1. If there are changes, send them to the **delegate**.

+1. When the delegate finishes processing the changes **successfully**, update the lease store with the latest processed point in time and go to #1.

+## Error handling

+The change feed processor is resilient to user code errors. That means that if your delegate implementation has an unhandled exception (step #4), the thread processing that particular batch of changes will be stopped, and a new thread will be created. The new thread will check which was the latest point in time the lease store has for that range of partition key values, and restart from there, effectively sending the same batch of changes to the delegate. This behavior will continue until your delegate processes the changes correctly and it's the reason the change feed processor has an "at least once" guarantee.

+> [!NOTE]

+> There is only one scenario where a batch of changes will not be retried. If the failure happens on the first ever delegate execution, the lease store has no previous saved state to be used on the retry. On those cases, the retry would use the [initial starting configuration](#starting-time), which might or might not include the last batch.

+To prevent your change feed processor from getting "stuck" continuously retrying the same batch of changes, you should add logic in your delegate code to write documents, upon exception, to a dead-letter queue. This design ensures that you can keep track of unprocessed changes while still being able to continue to process future changes. The dead-letter queue might be another Cosmos container. The exact data store does not matter, simply that the unprocessed changes are persisted.

+In addition, you can use the [change feed estimator](how-to-use-change-feed-estimator.md) to monitor the progress of your change feed processor instances as they read the change feed.

+<!-- ## Life-cycle notifications

+The change feed processor lets you hook to relevant events in its [life cycle](#processing-life-cycle), you can choose to be notified to one or all of them. The recommendation is to at least register the error notification:

+* Register a handler for `WithLeaseAcquireNotification` to be notified when the current host acquires a lease to start processing it.

+* Register a handler for `WithLeaseReleaseNotification` to be notified when the current host releases a lease and stops processing it.

+* Register a handler for `WithErrorNotification` to be notified when the current host encounters an exception during processing, being able to distinguish if the source is the user delegate (unhandled exception) or an error the processor is encountering trying to access the monitored container (for example, networking issues).

+[!code-csharp[Main](~/samples-cosmosdb-dotnet-v3/Microsoft.Azure.Cosmos.Samples/Usage/ChangeFeed/Program.cs?name=StartWithNotifications)] -->

+## Deployment unit

+A single change feed processor deployment unit consists of one or more compute instances with the same lease container configuration, the same `leasePrefix`, but different `hostName` name each. You can have many deployment units where each one has a different business flow for the changes and each deployment unit consisting of one or more instances.

+For example, you might have one deployment unit that triggers an external API anytime there is a change in your container. Another deployment unit might move data, in real time, each time there is a change. When a change happens in your monitored container, all your deployment units will get notified.

+## Dynamic scaling

+As mentioned before, within a deployment unit you can have one or more compute instances. To take advantage of the compute distribution within the deployment unit, the only key requirements are:

+1. All instances should have the same lease container configuration.

+1. All instances should have the same value set in `options.setLeasePrefix` (or none set at all).

+1. Each instance needs to have a different `hostName`.

+If these three conditions apply, then the change feed processor will distribute all the leases in the lease container across all running instances of that deployment unit and parallelize compute using an equal distribution algorithm. One lease can only be owned by one instance at a given time, so the number of instances should not be greater than the number of leases.

+The number of instances can grow and shrink, and the change feed processor will dynamically adjust the load by redistributing accordingly. Deployment units can share the same lease container, but they should each have a different `leasePrefix`.

+Moreover, the change feed processor can dynamically adjust to containers scale due to throughput or storage increases. When your container grows, the change feed processor transparently handles these scenarios by dynamically increasing the leases and distributing the new leases among existing instances.

+## Change feed and provisioned throughput

+Change feed read operations on the monitored container will consume [request units](../request-units.md). Make sure your monitored container is not experiencing [throttling](troubleshoot-request-rate-too-large.md), otherwise you will experience delays in receiving change feed events on your processors.

+Operations on the lease container (updating and maintaining state) consume [request units](../request-units.md). The higher the number of instances using the same lease container, the higher the potential request units consumption will be. Make sure your lease container is not experiencing [throttling](troubleshoot-request-rate-too-large.md), otherwise you will experience delays in receiving change feed events on your processors, in some cases where throttling is high, the processors might stop processing completely.

+## Starting time

+By default, when a change feed processor starts the first time, it will initialize the leases container, and start its [processing life cycle](#processing-life-cycle). Any changes that happened in the monitored container before the change feed processor was initialized for the first time won't be detected.

+### Reading from a previous date and time

+It's possible to initialize the change feed processor to read changes starting at a **specific date and time**, by setting `setStartTime` in `options`. The change feed processor will be initialized for that specific date and time and start reading the changes that happened after.

+> [!NOTE]

+> Starting the change feed processor at a specific date and time is not supported in multi-region write accounts.

+### Reading from the beginning

+In our above sample, we set `setStartFromBeginning` to `false`, which is the same as the default value. In other scenarios like data migrations or analyzing the entire history of a container, we need to read the change feed from **the beginning of that container's lifetime**. To do that, we can set `setStartFromBeginning` to `true`. The change feed processor will be initialized and start reading changes from the beginning of the lifetime of the container.

+> [!NOTE]

+> These customization options only work to setup the starting point in time of the change feed processor. Once the leases container is initialized for the first time, changing them has no effect.

+### [.NET](#tab/dotnet)

+### [Java](#tab/java)

+You can create a `Iterator<FeedResponse<JsonNode>> responseIterator` to process the change feed using the pull model. When creating `CosmosChangeFeedRequestOptions` you must specify where to start reading the change feed from. You will also pass the desired `FeedRange`. The `FeedRange` is a range of partition key values and specifies the items that will be read from the change feed. If you specify `FeedRange.forFullRange()`, you can process an entire container's change feed at your own pace. You can optionally specify a value in `byPage()`. When set, this property sets the maximum number of items received per page. Below is an example for obtaining a `responseIterator`.

+>[!NOTE]

+> All of the below code snippets are taken from a sample in GitHub, which you can find [here](https://github.com/Azure-Samples/azure-cosmos-java-sql-api-samples/blob/main/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java).

+ [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java?name=FeedResponseIterator)]

+We can then iterate over the results. Because the change feed is effectively an infinite list of items encompassing all future writes and updates, the value of `responseIterator.hasNext()` is always true. Below is an example, which reads all changes starting from the beginning. Each iteration persists a continuation token after processing all events, and will pick up from the last processed point in the change feed. This is handled using `createForProcessingFromContinuation`:.

+ [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java?name=AllFeedRanges)]

+## Consuming a partition key's changes

+In some cases, you may only want to process a specific partition key's changes. You can can process the changes for a specific partition key in the same way that you can for an entire container. Here's an example:

+ [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java?name=PartitionKeyProcessing)]

+## Using FeedRange for parallelization

+In the [change feed processor](change-feed-processor.md), work is automatically spread across multiple consumers. In the change feed pull model, you can use the `FeedRange` to parallelize the processing of the change feed. A `FeedRange` represents a range of partition key values.

+Here's an example showing how to obtain a list of ranges for your container:

+ [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java?name=GetFeedRanges)]

+When you obtain of list of FeedRanges for your container, you'll get one `FeedRange` per [physical partition](../partitioning-overview.md#physical-partitions).

+Using a `FeedRange`, you can then parallelize the processing of the change feed across multiple machines or threads. Unlike the previous example that showed how to process changes for the entire container or a single partition key, you can use FeedRanges to process the change feed in parallel.

+In the case where you want to use FeedRanges, you need to have an orchestrator process that obtains FeedRanges and distributes them to those machines. This distribution could be:

+* Using `FeedRange.toString()` and distributing this string value.

+* If the distribution is in-process, passing the `FeedRange` object reference.

+Here's a sample that shows how to read from the beginning of the container's change feed using two hypothetical separate machines that are reading in parallel:

+Machine 1:

+ [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java?name=Machine1)]

+Machine 2:

+ [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java?name=Machine2)]

+This Azure Blob storage connector is supported for the following capabilities:

+| Supported capabilities|IR | Managed private endpoint|

+|| --| --|

+|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|Γ£ô <small> Exclude storage account V1|

+|[Mapping data flow](concepts-data-flow-overview.md) (source/sink)|&#9312; |Γ£ô <small> Exclude storage account V1|

+|[Lookup activity](control-flow-lookup-activity.md)|&#9312; &#9313;|Γ£ô <small> Exclude storage account V1|

+|[GetMetadata activity](control-flow-get-metadata-activity.md)|&#9312; &#9313;|Γ£ô <small> Exclude storage account V1|

+|[Delete activity](delete-activity.md)|&#9312; &#9313;|Γ£ô <small> Exclude storage account V1|

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+This Azure Cosmos DB's API for MongoDB connector is supported for the following capabilities:

+| Supported capabilities|IR | Managed private endpoint|

+|| --| --|

+|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|Γ£ô |

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+This Azure Cosmos DB (SQL API) connector is supported for the following capabilities:

+| Supported capabilities|IR | Managed private endpoint|

+|| --| --|

+|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|Γ£ô |

+|[Mapping data flow](concepts-data-flow-overview.md) (source/sink)|&#9312; |Γ£ô |

+|[Lookup activity](control-flow-lookup-activity.md)|&#9312; &#9313;|Γ£ô |

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+This Azure Data Explorer connector is supported for the following capabilities:

+| Supported capabilities|IR |

+|| --|

+|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|

+|[Mapping data flow](concepts-data-flow-overview.md) (source/sink)|&#9312; |

+|[Lookup activity](control-flow-lookup-activity.md)|&#9312; &#9313;|

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+This Azure Data Lake Storage Gen2 connector is supported for the following capabilities:

+| Supported capabilities|IR | Managed private endpoint|

+|| --| --|

+|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|Γ£ô |

+|[Mapping data flow](concepts-data-flow-overview.md) (source/sink)|&#9312; |Γ£ô |

+|[Lookup activity](control-flow-lookup-activity.md)|&#9312; &#9313;|Γ£ô |

+|[GetMetadata activity](control-flow-get-metadata-activity.md)|&#9312; &#9313;|Γ£ô |

+|[Delete activity](delete-activity.md)|&#9312; &#9313;|Γ£ô |

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+ * **Output to a single file**: Combine the partitioned output files into a single named file. The path is relative to the dataset folder. Please be aware that the merge operation can possibly fail based upon node size. This option is not recommended for large datasets.

+This Azure Data Lake Storage Gen1 connector is supported for the following capabilities:

+| Supported capabilities|IR |

+|| --|

+|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|

+|[Mapping data flow](concepts-data-flow-overview.md) (source/sink)|&#9312; |

+|[Lookup activity](control-flow-lookup-activity.md)|&#9312; &#9313;|

+|[GetMetadata activity](control-flow-get-metadata-activity.md)|&#9312; &#9313;|

+|[Delete activity](delete-activity.md)|&#9312; &#9313;|

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+ * **Output to a single file**: Combine the partitioned output files into a single named file. The path is relative to the dataset folder. Please be aware that the merge operation can possibly fail based upon node size. This option is not recommended for large datasets.

+This Azure Database for MariaDB connector is supported for the following capabilities:

+| Supported capabilities|IR | Managed private endpoint|

+|| --| --|

+|[Copy activity](copy-activity-overview.md) (source/-)|&#9312; &#9313;|Γ£ô |

+|[Lookup activity](control-flow-lookup-activity.md)|&#9312; &#9313;|Γ£ô |

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+This Azure Database for MySQL connector is supported for the following capabilities:

+| Supported capabilities|IR | Managed private endpoint|

+|| --| --|

+|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|Γ£ô |

+|[Mapping data flow](concepts-data-flow-overview.md) (source/sink)|&#9312; |Γ£ô |

+|[Lookup activity](control-flow-lookup-activity.md)|&#9312; &#9313;|Γ£ô |

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+This Azure Database for PostgreSQL connector is supported for the following capabilities:

+| Supported capabilities|IR | Managed private endpoint|

+|| --| --|

+|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|Γ£ô |

+|[Mapping data flow](concepts-data-flow-overview.md) (source/sink)|&#9312; |Γ£ô |

+|[Lookup activity](control-flow-lookup-activity.md)|&#9312; &#9313;|Γ£ô |

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+This Azure Databricks Delta Lake connector is supported for the following capabilities:

+| Supported capabilities|IR |

+|| --|

+|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|

+|[Mapping data flow](concepts-data-flow-overview.md) (source/sink)|&#9312; |

+|[Lookup activity](control-flow-lookup-activity.md)|&#9312; &#9313;|

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+This Azure Files connector is supported for the following capabilities:

+| Supported capabilities|IR | Managed private endpoint|

+|| --| --|

+|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|Γ£ô <small> Exclude storage account V1|

+|[Lookup activity](control-flow-lookup-activity.md)|&#9312; &#9313;|Γ£ô <small> Exclude storage account V1|

+|[GetMetadata activity](control-flow-get-metadata-activity.md)|&#9312; &#9313;|Γ£ô <small> Exclude storage account V1|

+|[Delete activity](delete-activity.md)|&#9312; &#9313;|Γ£ô <small> Exclude storage account V1|

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+This Azure Cognitive Search connector is supported for the following capabilities:

+| Supported capabilities|IR | Managed private endpoint|

+|| --| --|

+|[Copy activity](copy-activity-overview.md) (-/sink)|&#9312; &#9313;|Γ£ô |

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+This Azure Synapse Analytics connector is supported for the following capabilities:

+| Supported capabilities|IR | Managed private endpoint|

+|| --| --|

+|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|Γ£ô |

+|[Mapping data flow](concepts-data-flow-overview.md) (source/sink)|&#9312; |Γ£ô |

+|[Lookup activity](control-flow-lookup-activity.md)|&#9312; &#9313;|Γ£ô |

+|[GetMetadata activity](control-flow-get-metadata-activity.md)|&#9312; &#9313;|Γ£ô |

+|[Script activity](transform-data-using-script.md)|&#9312; &#9313;|Γ£ô |

+|[Stored procedure activity](transform-data-using-stored-procedure.md)|&#9312; &#9313;|Γ£ô |

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+**Enable staging:** This enables loading into Azure Synapse Analytics SQL Pools using the copy command and is recommended for most Synapse sinks. The staging storage is configured in [Execute Data Flow activity](control-flow-execute-data-flow-activity.md).

+This Azure SQL Database connector is supported for the following capabilities:

+| Supported capabilities|IR | Managed private endpoint|

+|| --| --|

+|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|Γ£ô |

+|[Mapping data flow](concepts-data-flow-overview.md) (source/sink)|&#9312; |Γ£ô |

+|[Lookup activity](control-flow-lookup-activity.md)|&#9312; &#9313;|Γ£ô |

+|[GetMetadata activity](control-flow-get-metadata-activity.md)|&#9312; &#9313;|Γ£ô |

+|[Script activity](transform-data-using-script.md)|&#9312; &#9313;|Γ£ô |

+|[Stored procedure activity](transform-data-using-stored-procedure.md)|&#9312; &#9313;|Γ£ô |

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+This Azure SQL Managed Instance connector is supported for the following capabilities:

+| Supported capabilities|IR | Managed private endpoint|

+|| --| --|

+|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|Γ£ô <small> Public preview |

+|[Mapping data flow](concepts-data-flow-overview.md) (source/sink)|&#9312; |Γ£ô <small> Public preview |

+|[Lookup activity](control-flow-lookup-activity.md)|&#9312; &#9313;|Γ£ô <small> Public preview |

+|[GetMetadata activity](control-flow-get-metadata-activity.md)|&#9312; &#9313;|Γ£ô <small> Public preview |

+|[Script activity](transform-data-using-script.md)|&#9312; &#9313;|Γ£ô <small> Public preview |

+|[Stored procedure activity](transform-data-using-stored-procedure.md)|&#9312; &#9313;|Γ£ô <small> Public preview |

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+This Azure Table storage connector is supported for the following capabilities:

+| Supported capabilities|IR | Managed private endpoint|

+|| --| --|

+|[Copy activity](copy-activity-overview.md) (source/sink)|&#9312; &#9313;|Γ£ô <small> Exclude storage account V1|

+|[Lookup activity](control-flow-lookup-activity.md)|&#9312; &#9313;|Γ£ô <small> Exclude storage account V1|

+<small>*&#9312; Azure integration runtime &#9313; Self-hosted integration runtime*</small>

+If your data store is a managed cloud data service, you can use the Azure Integration Runtime. If the access is restricted to IPs that are approved in the firewall rules, you can add [Azure Integration Runtime IPs](azure-integration-runtime-ip-addresses.md) to the allowed list.

+The Snowflake account that is used for Source or Sink should have the necessary `USAGE` access on the Database and Read / Write access on Schema and the Tables/Views under it. In addition, it should also have `CREATE STAGE` on the schema to be able to create the External stage with SAS URI.

+The following Account properties values must be set

+| Property | Description | Required | Default

+| : | :-- | :- | :-

+| REQUIRE_STORAGE_INTEGRATION_FOR_STAGE_CREATION | Specifies whether to require a storage integration object as cloud credentials when creating a named external stage (using CREATE STAGE) to access a private cloud storage location. | FALSE | FALSE

+| REQUIRE_STORAGE_INTEGRATION_FOR_STAGE_OPERATION | Specifies whether to require using a named external stage that references a storage integration object as cloud credentials when loading data from or unloading data to a private cloud storage location. | FALSE | FALSE

+ACLs (and metadata attributes) aren't transferred when you copy data over [NFS](data-box-deploy-copy-data-via-nfs.md).

+The new comprehensive Container security plan combines Kubernetes protection and container registry image scanning, and removes the previous dependency on the (paid) Defender for Servers plan. The price for the service may change and is dependent on your container architecture and coverage. The cost may increase or decrease, depending on the number of images in your Container Registry, or the number of Kubernetes nodes among other reasons.

+Your price is dependent on your container architecture and coverage. Learn [how to enable and use](https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/microsoft-defender-for-cloud-price-estimation-dashboard/ba-p/3247622) the Price Estimation workbook.

+ :::image type="content" source="media/quickstart-onboard-gcp/create-connector.png" alt-text="Screenshot of the Create GCP connector page where you need to enter all relevant information." lightbox="media/quickstart-onboard-gcp/create-connector.png":::

+ (Optional) If you select **Organization**, a management project and an organization custom role will be created on your GCP project for the onboarding process. Auto-provisioning will be enabled for the onboarding of new projects.

+ | CSPM service account reader role <br> Microsoft Defender for Cloud identity federation <br> CSPM identity pool <br>*Microsoft Defender for Servers* service account (when the servers plan is enabled) <br>*Azure-Arc for servers onboarding* service account (when the Arc for servers auto-provisioning is enabled) | Microsoft Defender ContainersΓÇÖ service account role, <br> Microsoft Defender Data Collector service account role <br> Microsoft Defender for cloud identity pool |

+ The LA agent is currently configured in the subscription level, such that all the multicloud accounts and projects (from both AWS and GCP) under the same subscription will inherit the subscription settings with regard to the LA agent.

+If the origin uses Chunked Transfer Encoding (CTE) to send compressed data to the Azure Front Door POP, then response sizes greater than 8 MB aren't supported.

+- [Sample DSC resource modules](https://github.com/Azure/azure-policy/tree/master/samples/GuestConfiguration/package-samples/resource-modules)

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Kubernetes Service clusters should have Defender profile enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fa1840de2-8088-4ea8-b153-b4c723e9cb01) |Microsoft Defender for Containers provides cloud-native Kubernetes security capabilities including environment hardening, workload protection, and run-time protection. When you enable the SecurityProfile.AzureDefender on your Azure Kubernetes Service cluster, an agent is deployed to your cluster to collect security event data. Learn more about Microsoft Defender for Containers in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-introduction?tabs=defender-for-container-arch-aks](../../../defender-for-cloud/defender-for-containers-introduction.md?tabs=defender-for-container-arch-aks) |Audit, Disabled |[1.0.3](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_AKS_SecurityProfile_Audit.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Kubernetes Service clusters should have Defender profile enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fa1840de2-8088-4ea8-b153-b4c723e9cb01) |Microsoft Defender for Containers provides cloud-native Kubernetes security capabilities including environment hardening, workload protection, and run-time protection. When you enable the SecurityProfile.AzureDefender on your Azure Kubernetes Service cluster, an agent is deployed to your cluster to collect security event data. Learn more about Microsoft Defender for Containers in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-introduction?tabs=defender-for-container-arch-aks](../../../defender-for-cloud/defender-for-containers-introduction.md?tabs=defender-for-container-arch-aks) |Audit, Disabled |[1.0.3](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_AKS_SecurityProfile_Audit.json) |

+|[Kubernetes cluster containers should not share host process ID or host IPC namespace](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F47a1ee2f-2a2a-4576-bf2a-e0e36709c2b8) |Block pod containers from sharing the host process ID namespace and host IPC namespace in a Kubernetes cluster. This recommendation is part of CIS 5.2.2 and CIS 5.2.3 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/BlockHostNamespace.json) |

+|[Kubernetes cluster containers should only use allowed AppArmor profiles](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F511f5417-5d12-434d-ab2e-816901e72a5e) |Containers should only use allowed AppArmor profiles in a Kubernetes cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/EnforceAppArmorProfile.json) |

+|[Kubernetes cluster containers should only use allowed capabilities](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fc26596ff-4d70-4e6a-9a30-c2506bd2f80c) |Restrict the capabilities to reduce the attack surface of containers in a Kubernetes cluster. This recommendation is part of CIS 5.2.8 and CIS 5.2.9 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerAllowedCapabilities.json) |

+|[Kubernetes cluster containers should only use allowed images](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffebd0533-8e55-448f-b837-bd0e06f16469) |Use images from trusted registries to reduce the Kubernetes cluster's exposure risk to unknown vulnerabilities, security issues and malicious images. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerAllowedImages.json) |

+|[Kubernetes cluster containers should run with a read only root file system](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fdf49d893-a74c-421d-bc95-c663042e5b80) |Run containers with a read only root file system to protect from changes at run-time with malicious binaries being added to PATH in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ReadOnlyRootFileSystem.json) |

+|[Kubernetes cluster pod hostPath volumes should only use allowed host paths](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F098fc59e-46c7-4d99-9b16-64990e543d75) |Limit pod HostPath volume mounts to the allowed host paths in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/AllowedHostPaths.json) |

+|[Kubernetes cluster pods and containers should only run with approved user and group IDs](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff06ddb64-5fa3-4b77-b166-acb36f7f6042) |Control the user, primary group, supplemental group and file system group IDs that pods and containers can use to run in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/AllowedUsersGroups.json) |

+|[Kubernetes cluster pods should only use approved host network and port range](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F82985f06-dc18-4a48-bc1c-b9f4f0098cfe) |Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/HostNetworkPorts.json) |

+|[Kubernetes cluster should not allow privileged containers](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F95edb821-ddaf-4404-9732-666045e056b4) |Do not allow privileged containers creation in a Kubernetes cluster. This recommendation is part of CIS 5.2.1 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerNoPrivilege.json) |

+|[Kubernetes clusters should disable automounting API credentials](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F423dd1ba-798e-40e4-9c4d-b6902674b423) |Disable automounting API credentials to prevent a potentially compromised Pod resource to run API commands against Kubernetes clusters. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[3.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/BlockAutomountToken.json) |

+|[Kubernetes clusters should not allow container privilege escalation](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1c6e92c9-99f0-4e55-9cf2-0c234dc48f99) |Do not allow containers to run with privilege escalation to root in a Kubernetes cluster. This recommendation is part of CIS 5.2.5 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[6.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerNoPrivilegeEscalation.json) |

+|[Kubernetes clusters should not grant CAP_SYS_ADMIN security capabilities](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd2e7ea85-6b44-4317-a0be-1b951587f626) |To reduce the attack surface of your containers, restrict CAP_SYS_ADMIN Linux capabilities. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[3.3.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerDisallowedSysAdminCapability.json) |

+|[Kubernetes clusters should not use the default namespace](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F9f061a12-e40d-4183-a00e-171812443373) |Prevent usage of the default namespace in Kubernetes clusters to protect against unauthorized access for ConfigMap, Pod, Secret, Service, and ServiceAccount resource types. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[3.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/BlockDefaultNamespace.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Kubernetes cluster pods should only use approved host network and port range](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F82985f06-dc18-4a48-bc1c-b9f4f0098cfe) |Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/HostNetworkPorts.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Kubernetes cluster pods should only use approved host network and port range](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F82985f06-dc18-4a48-bc1c-b9f4f0098cfe) |Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/HostNetworkPorts.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Kubernetes cluster pods should only use approved host network and port range](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F82985f06-dc18-4a48-bc1c-b9f4f0098cfe) |Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/HostNetworkPorts.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Kubernetes cluster pods should only use approved host network and port range](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F82985f06-dc18-4a48-bc1c-b9f4f0098cfe) |Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/HostNetworkPorts.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Kubernetes cluster pods should only use approved host network and port range](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F82985f06-dc18-4a48-bc1c-b9f4f0098cfe) |Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/HostNetworkPorts.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Kubernetes cluster containers should not share host process ID or host IPC namespace](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F47a1ee2f-2a2a-4576-bf2a-e0e36709c2b8) |Block pod containers from sharing the host process ID namespace and host IPC namespace in a Kubernetes cluster. This recommendation is part of CIS 5.2.2 and CIS 5.2.3 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/BlockHostNamespace.json) |

+|[Kubernetes cluster containers should only use allowed AppArmor profiles](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F511f5417-5d12-434d-ab2e-816901e72a5e) |Containers should only use allowed AppArmor profiles in a Kubernetes cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/EnforceAppArmorProfile.json) |

+|[Kubernetes cluster containers should only use allowed capabilities](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fc26596ff-4d70-4e6a-9a30-c2506bd2f80c) |Restrict the capabilities to reduce the attack surface of containers in a Kubernetes cluster. This recommendation is part of CIS 5.2.8 and CIS 5.2.9 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerAllowedCapabilities.json) |

+|[Kubernetes cluster containers should only use allowed images](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffebd0533-8e55-448f-b837-bd0e06f16469) |Use images from trusted registries to reduce the Kubernetes cluster's exposure risk to unknown vulnerabilities, security issues and malicious images. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerAllowedImages.json) |

+|[Kubernetes cluster containers should run with a read only root file system](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fdf49d893-a74c-421d-bc95-c663042e5b80) |Run containers with a read only root file system to protect from changes at run-time with malicious binaries being added to PATH in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ReadOnlyRootFileSystem.json) |

+|[Kubernetes cluster pod hostPath volumes should only use allowed host paths](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F098fc59e-46c7-4d99-9b16-64990e543d75) |Limit pod HostPath volume mounts to the allowed host paths in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/AllowedHostPaths.json) |

+|[Kubernetes cluster pods and containers should only run with approved user and group IDs](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff06ddb64-5fa3-4b77-b166-acb36f7f6042) |Control the user, primary group, supplemental group and file system group IDs that pods and containers can use to run in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/AllowedUsersGroups.json) |

+|[Kubernetes cluster pods should only use approved host network and port range](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F82985f06-dc18-4a48-bc1c-b9f4f0098cfe) |Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/HostNetworkPorts.json) |

+|[Kubernetes cluster should not allow privileged containers](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F95edb821-ddaf-4404-9732-666045e056b4) |Do not allow privileged containers creation in a Kubernetes cluster. This recommendation is part of CIS 5.2.1 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerNoPrivilege.json) |

+|[Kubernetes clusters should not allow container privilege escalation](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1c6e92c9-99f0-4e55-9cf2-0c234dc48f99) |Do not allow containers to run with privilege escalation to root in a Kubernetes cluster. This recommendation is part of CIS 5.2.5 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[6.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerNoPrivilegeEscalation.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Kubernetes cluster containers should not share host process ID or host IPC namespace](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F47a1ee2f-2a2a-4576-bf2a-e0e36709c2b8) |Block pod containers from sharing the host process ID namespace and host IPC namespace in a Kubernetes cluster. This recommendation is part of CIS 5.2.2 and CIS 5.2.3 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/BlockHostNamespace.json) |

+|[Kubernetes cluster containers should only use allowed AppArmor profiles](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F511f5417-5d12-434d-ab2e-816901e72a5e) |Containers should only use allowed AppArmor profiles in a Kubernetes cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/EnforceAppArmorProfile.json) |

+|[Kubernetes cluster containers should only use allowed capabilities](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fc26596ff-4d70-4e6a-9a30-c2506bd2f80c) |Restrict the capabilities to reduce the attack surface of containers in a Kubernetes cluster. This recommendation is part of CIS 5.2.8 and CIS 5.2.9 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerAllowedCapabilities.json) |

+|[Kubernetes cluster containers should only use allowed images](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffebd0533-8e55-448f-b837-bd0e06f16469) |Use images from trusted registries to reduce the Kubernetes cluster's exposure risk to unknown vulnerabilities, security issues and malicious images. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerAllowedImages.json) |

+|[Kubernetes cluster containers should run with a read only root file system](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fdf49d893-a74c-421d-bc95-c663042e5b80) |Run containers with a read only root file system to protect from changes at run-time with malicious binaries being added to PATH in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ReadOnlyRootFileSystem.json) |

+|[Kubernetes cluster pod hostPath volumes should only use allowed host paths](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F098fc59e-46c7-4d99-9b16-64990e543d75) |Limit pod HostPath volume mounts to the allowed host paths in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/AllowedHostPaths.json) |

+|[Kubernetes cluster pods and containers should only run with approved user and group IDs](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff06ddb64-5fa3-4b77-b166-acb36f7f6042) |Control the user, primary group, supplemental group and file system group IDs that pods and containers can use to run in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/AllowedUsersGroups.json) |

+|[Kubernetes cluster pods should only use approved host network and port range](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F82985f06-dc18-4a48-bc1c-b9f4f0098cfe) |Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/HostNetworkPorts.json) |

+|[Kubernetes cluster should not allow privileged containers](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F95edb821-ddaf-4404-9732-666045e056b4) |Do not allow privileged containers creation in a Kubernetes cluster. This recommendation is part of CIS 5.2.1 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerNoPrivilege.json) |

+|[Kubernetes clusters should not allow container privilege escalation](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1c6e92c9-99f0-4e55-9cf2-0c234dc48f99) |Do not allow containers to run with privilege escalation to root in a Kubernetes cluster. This recommendation is part of CIS 5.2.5 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[6.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerNoPrivilegeEscalation.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Kubernetes cluster containers should not share host process ID or host IPC namespace](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F47a1ee2f-2a2a-4576-bf2a-e0e36709c2b8) |Block pod containers from sharing the host process ID namespace and host IPC namespace in a Kubernetes cluster. This recommendation is part of CIS 5.2.2 and CIS 5.2.3 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/BlockHostNamespace.json) |

+|[Kubernetes cluster containers should only use allowed AppArmor profiles](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F511f5417-5d12-434d-ab2e-816901e72a5e) |Containers should only use allowed AppArmor profiles in a Kubernetes cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/EnforceAppArmorProfile.json) |

+|[Kubernetes cluster containers should only use allowed capabilities](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fc26596ff-4d70-4e6a-9a30-c2506bd2f80c) |Restrict the capabilities to reduce the attack surface of containers in a Kubernetes cluster. This recommendation is part of CIS 5.2.8 and CIS 5.2.9 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerAllowedCapabilities.json) |

+|[Kubernetes cluster containers should only use allowed images](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffebd0533-8e55-448f-b837-bd0e06f16469) |Use images from trusted registries to reduce the Kubernetes cluster's exposure risk to unknown vulnerabilities, security issues and malicious images. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerAllowedImages.json) |

+|[Kubernetes cluster containers should run with a read only root file system](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fdf49d893-a74c-421d-bc95-c663042e5b80) |Run containers with a read only root file system to protect from changes at run-time with malicious binaries being added to PATH in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ReadOnlyRootFileSystem.json) |

+|[Kubernetes cluster pod hostPath volumes should only use allowed host paths](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F098fc59e-46c7-4d99-9b16-64990e543d75) |Limit pod HostPath volume mounts to the allowed host paths in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/AllowedHostPaths.json) |

+|[Kubernetes cluster pods and containers should only run with approved user and group IDs](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff06ddb64-5fa3-4b77-b166-acb36f7f6042) |Control the user, primary group, supplemental group and file system group IDs that pods and containers can use to run in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/AllowedUsersGroups.json) |

+|[Kubernetes cluster pods should only use approved host network and port range](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F82985f06-dc18-4a48-bc1c-b9f4f0098cfe) |Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/HostNetworkPorts.json) |

+|[Kubernetes cluster should not allow privileged containers](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F95edb821-ddaf-4404-9732-666045e056b4) |Do not allow privileged containers creation in a Kubernetes cluster. This recommendation is part of CIS 5.2.1 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerNoPrivilege.json) |

+|[Kubernetes clusters should disable automounting API credentials](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F423dd1ba-798e-40e4-9c4d-b6902674b423) |Disable automounting API credentials to prevent a potentially compromised Pod resource to run API commands against Kubernetes clusters. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[3.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/BlockAutomountToken.json) |

+|[Kubernetes clusters should not allow container privilege escalation](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1c6e92c9-99f0-4e55-9cf2-0c234dc48f99) |Do not allow containers to run with privilege escalation to root in a Kubernetes cluster. This recommendation is part of CIS 5.2.5 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[6.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerNoPrivilegeEscalation.json) |

+|[Kubernetes clusters should not grant CAP_SYS_ADMIN security capabilities](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd2e7ea85-6b44-4317-a0be-1b951587f626) |To reduce the attack surface of your containers, restrict CAP_SYS_ADMIN Linux capabilities. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[3.3.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerDisallowedSysAdminCapability.json) |

+|[Kubernetes clusters should not use the default namespace](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F9f061a12-e40d-4183-a00e-171812443373) |Prevent usage of the default namespace in Kubernetes clusters to protect against unauthorized access for ConfigMap, Pod, Secret, Service, and ServiceAccount resource types. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[3.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/BlockDefaultNamespace.json) |

+### Ensure server parameter 'connection_throttling' is set to 'ON' for PostgreSQL Database Server

+**ID**: CIS Microsoft Azure Foundations Benchmark recommendation 4.17

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[1.1.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Kubernetes cluster containers should not share host process ID or host IPC namespace](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F47a1ee2f-2a2a-4576-bf2a-e0e36709c2b8) |Block pod containers from sharing the host process ID namespace and host IPC namespace in a Kubernetes cluster. This recommendation is part of CIS 5.2.2 and CIS 5.2.3 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/BlockHostNamespace.json) |

+|[Kubernetes cluster containers should only use allowed AppArmor profiles](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F511f5417-5d12-434d-ab2e-816901e72a5e) |Containers should only use allowed AppArmor profiles in a Kubernetes cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/EnforceAppArmorProfile.json) |

+|[Kubernetes cluster containers should only use allowed capabilities](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fc26596ff-4d70-4e6a-9a30-c2506bd2f80c) |Restrict the capabilities to reduce the attack surface of containers in a Kubernetes cluster. This recommendation is part of CIS 5.2.8 and CIS 5.2.9 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerAllowedCapabilities.json) |

+|[Kubernetes cluster containers should only use allowed images](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffebd0533-8e55-448f-b837-bd0e06f16469) |Use images from trusted registries to reduce the Kubernetes cluster's exposure risk to unknown vulnerabilities, security issues and malicious images. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerAllowedImages.json) |

+|[Kubernetes cluster containers should run with a read only root file system](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fdf49d893-a74c-421d-bc95-c663042e5b80) |Run containers with a read only root file system to protect from changes at run-time with malicious binaries being added to PATH in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ReadOnlyRootFileSystem.json) |

+|[Kubernetes cluster pod hostPath volumes should only use allowed host paths](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F098fc59e-46c7-4d99-9b16-64990e543d75) |Limit pod HostPath volume mounts to the allowed host paths in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/AllowedHostPaths.json) |

+|[Kubernetes cluster pods and containers should only run with approved user and group IDs](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff06ddb64-5fa3-4b77-b166-acb36f7f6042) |Control the user, primary group, supplemental group and file system group IDs that pods and containers can use to run in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/AllowedUsersGroups.json) |

+|[Kubernetes cluster pods should only use approved host network and port range](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F82985f06-dc18-4a48-bc1c-b9f4f0098cfe) |Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/HostNetworkPorts.json) |

+|[Kubernetes cluster should not allow privileged containers](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F95edb821-ddaf-4404-9732-666045e056b4) |Do not allow privileged containers creation in a Kubernetes cluster. This recommendation is part of CIS 5.2.1 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerNoPrivilege.json) |

+|[Kubernetes clusters should not allow container privilege escalation](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1c6e92c9-99f0-4e55-9cf2-0c234dc48f99) |Do not allow containers to run with privilege escalation to root in a Kubernetes cluster. This recommendation is part of CIS 5.2.5 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[6.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerNoPrivilegeEscalation.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[1.1.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[1.1.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[1.1.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Kubernetes cluster containers should not share host process ID or host IPC namespace](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F47a1ee2f-2a2a-4576-bf2a-e0e36709c2b8) |Block pod containers from sharing the host process ID namespace and host IPC namespace in a Kubernetes cluster. This recommendation is part of CIS 5.2.2 and CIS 5.2.3 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/BlockHostNamespace.json) |

+|[Kubernetes cluster containers should only use allowed AppArmor profiles](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F511f5417-5d12-434d-ab2e-816901e72a5e) |Containers should only use allowed AppArmor profiles in a Kubernetes cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/EnforceAppArmorProfile.json) |

+|[Kubernetes cluster containers should only use allowed capabilities](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fc26596ff-4d70-4e6a-9a30-c2506bd2f80c) |Restrict the capabilities to reduce the attack surface of containers in a Kubernetes cluster. This recommendation is part of CIS 5.2.8 and CIS 5.2.9 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerAllowedCapabilities.json) |

+|[Kubernetes cluster containers should only use allowed images](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffebd0533-8e55-448f-b837-bd0e06f16469) |Use images from trusted registries to reduce the Kubernetes cluster's exposure risk to unknown vulnerabilities, security issues and malicious images. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerAllowedImages.json) |

+|[Kubernetes cluster containers should run with a read only root file system](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fdf49d893-a74c-421d-bc95-c663042e5b80) |Run containers with a read only root file system to protect from changes at run-time with malicious binaries being added to PATH in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ReadOnlyRootFileSystem.json) |

+|[Kubernetes cluster pod hostPath volumes should only use allowed host paths](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F098fc59e-46c7-4d99-9b16-64990e543d75) |Limit pod HostPath volume mounts to the allowed host paths in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/AllowedHostPaths.json) |

+|[Kubernetes cluster pods and containers should only run with approved user and group IDs](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff06ddb64-5fa3-4b77-b166-acb36f7f6042) |Control the user, primary group, supplemental group and file system group IDs that pods and containers can use to run in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/AllowedUsersGroups.json) |

+|[Kubernetes cluster pods should only use approved host network and port range](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F82985f06-dc18-4a48-bc1c-b9f4f0098cfe) |Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/HostNetworkPorts.json) |

+|[Kubernetes cluster should not allow privileged containers](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F95edb821-ddaf-4404-9732-666045e056b4) |Do not allow privileged containers creation in a Kubernetes cluster. This recommendation is part of CIS 5.2.1 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerNoPrivilege.json) |

+|[Kubernetes clusters should not allow container privilege escalation](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1c6e92c9-99f0-4e55-9cf2-0c234dc48f99) |Do not allow containers to run with privilege escalation to root in a Kubernetes cluster. This recommendation is part of CIS 5.2.5 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[6.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerNoPrivilegeEscalation.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[1.1.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[1.1.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[1.1.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Kubernetes cluster containers should not share host process ID or host IPC namespace](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F47a1ee2f-2a2a-4576-bf2a-e0e36709c2b8) |Block pod containers from sharing the host process ID namespace and host IPC namespace in a Kubernetes cluster. This recommendation is part of CIS 5.2.2 and CIS 5.2.3 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/BlockHostNamespace.json) |

+|[Kubernetes cluster containers should only use allowed AppArmor profiles](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F511f5417-5d12-434d-ab2e-816901e72a5e) |Containers should only use allowed AppArmor profiles in a Kubernetes cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/EnforceAppArmorProfile.json) |

+|[Kubernetes cluster containers should only use allowed capabilities](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fc26596ff-4d70-4e6a-9a30-c2506bd2f80c) |Restrict the capabilities to reduce the attack surface of containers in a Kubernetes cluster. This recommendation is part of CIS 5.2.8 and CIS 5.2.9 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerAllowedCapabilities.json) |

+|[Kubernetes cluster containers should only use allowed images](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffebd0533-8e55-448f-b837-bd0e06f16469) |Use images from trusted registries to reduce the Kubernetes cluster's exposure risk to unknown vulnerabilities, security issues and malicious images. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerAllowedImages.json) |

+|[Kubernetes cluster containers should run with a read only root file system](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fdf49d893-a74c-421d-bc95-c663042e5b80) |Run containers with a read only root file system to protect from changes at run-time with malicious binaries being added to PATH in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ReadOnlyRootFileSystem.json) |

+|[Kubernetes cluster pod hostPath volumes should only use allowed host paths](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F098fc59e-46c7-4d99-9b16-64990e543d75) |Limit pod HostPath volume mounts to the allowed host paths in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/AllowedHostPaths.json) |

+|[Kubernetes cluster pods and containers should only run with approved user and group IDs](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff06ddb64-5fa3-4b77-b166-acb36f7f6042) |Control the user, primary group, supplemental group and file system group IDs that pods and containers can use to run in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/AllowedUsersGroups.json) |

+|[Kubernetes cluster pods should only use approved host network and port range](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F82985f06-dc18-4a48-bc1c-b9f4f0098cfe) |Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/HostNetworkPorts.json) |

+|[Kubernetes cluster should not allow privileged containers](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F95edb821-ddaf-4404-9732-666045e056b4) |Do not allow privileged containers creation in a Kubernetes cluster. This recommendation is part of CIS 5.2.1 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerNoPrivilege.json) |

+|[Kubernetes clusters should not allow container privilege escalation](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1c6e92c9-99f0-4e55-9cf2-0c234dc48f99) |Do not allow containers to run with privilege escalation to root in a Kubernetes cluster. This recommendation is part of CIS 5.2.5 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[6.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Kubernetes/ContainerNoPrivilegeEscalation.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[1.1.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[1.1.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Azure%20Government/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.us/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure SignalR Service should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F53503636-bcc9-4748-9663-5348217f160f) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Azure SignalR Service resource instead of the entire service, you'll reduce your data leakage risks. Learn more about private links at: [https://aka.ms/asrs/privatelink](../../../azure-signalr/howto-private-endpoints.md). |Audit, Deny, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/SignalR/SignalR_PrivateEndpointEnabled_Audit_v2.json) |

+|[Azure Web PubSub Service should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F52630df9-ca7e-442b-853b-c6ce548b31a2) |Azure Private Link lets you connect your virtual networks to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Azure Web PubSub Service, you can reduce data leakage risks. Learn more about private links at: [https://aka.ms/awps/privatelink](https://aka.ms/awps/privatelink). |Audit, Deny, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Web%20PubSub/WebPubSub_PrivateEndpointEnabled_Audit_v2.json) |

+|[Azure SignalR Service should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F53503636-bcc9-4748-9663-5348217f160f) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Azure SignalR Service resource instead of the entire service, you'll reduce your data leakage risks. Learn more about private links at: [https://aka.ms/asrs/privatelink](../../../azure-signalr/howto-private-endpoints.md). |Audit, Deny, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/SignalR/SignalR_PrivateEndpointEnabled_Audit_v2.json) |

+|[Azure Web PubSub Service should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F52630df9-ca7e-442b-853b-c6ce548b31a2) |Azure Private Link lets you connect your virtual networks to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Azure Web PubSub Service, you can reduce data leakage risks. Learn more about private links at: [https://aka.ms/awps/privatelink](https://aka.ms/awps/privatelink). |Audit, Deny, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Web%20PubSub/WebPubSub_PrivateEndpointEnabled_Audit_v2.json) |

+|[Azure SignalR Service should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F53503636-bcc9-4748-9663-5348217f160f) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Azure SignalR Service resource instead of the entire service, you'll reduce your data leakage risks. Learn more about private links at: [https://aka.ms/asrs/privatelink](../../../azure-signalr/howto-private-endpoints.md). |Audit, Deny, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/SignalR/SignalR_PrivateEndpointEnabled_Audit_v2.json) |

+|[Azure Web PubSub Service should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F52630df9-ca7e-442b-853b-c6ce548b31a2) |Azure Private Link lets you connect your virtual networks to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Azure Web PubSub Service, you can reduce data leakage risks. Learn more about private links at: [https://aka.ms/awps/privatelink](https://aka.ms/awps/privatelink). |Audit, Deny, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Web%20PubSub/WebPubSub_PrivateEndpointEnabled_Audit_v2.json) |

+|[Azure SignalR Service should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F53503636-bcc9-4748-9663-5348217f160f) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Azure SignalR Service resource instead of the entire service, you'll reduce your data leakage risks. Learn more about private links at: [https://aka.ms/asrs/privatelink](../../../azure-signalr/howto-private-endpoints.md). |Audit, Deny, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/SignalR/SignalR_PrivateEndpointEnabled_Audit_v2.json) |

+|[Azure Web PubSub Service should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F52630df9-ca7e-442b-853b-c6ce548b31a2) |Azure Private Link lets you connect your virtual networks to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Azure Web PubSub Service, you can reduce data leakage risks. Learn more about private links at: [https://aka.ms/awps/privatelink](https://aka.ms/awps/privatelink). |Audit, Deny, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Web%20PubSub/WebPubSub_PrivateEndpointEnabled_Audit_v2.json) |

+|[Azure SignalR Service should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F53503636-bcc9-4748-9663-5348217f160f) |Azure Private Link lets you connect your virtual network to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Azure SignalR Service resource instead of the entire service, you'll reduce your data leakage risks. Learn more about private links at: [https://aka.ms/asrs/privatelink](../../../azure-signalr/howto-private-endpoints.md). |Audit, Deny, Disabled |[1.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/SignalR/SignalR_PrivateEndpointEnabled_Audit_v2.json) |

+|[Azure Web PubSub Service should use private link](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F52630df9-ca7e-442b-853b-c6ce548b31a2) |Azure Private Link lets you connect your virtual networks to Azure services without a public IP address at the source or destination. The private link platform handles the connectivity between the consumer and services over the Azure backbone network. By mapping private endpoints to your Azure Web PubSub Service, you can reduce data leakage risks. Learn more about private links at: [https://aka.ms/awps/privatelink](https://aka.ms/awps/privatelink). |Audit, Deny, Disabled |[1.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Web%20PubSub/WebPubSub_PrivateEndpointEnabled_Audit_v2.json) |

+- Learn how to [remediate non-compliant resources](../how-to/remediate-resources.md).

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Kubernetes cluster containers should not share host process ID or host IPC namespace](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F47a1ee2f-2a2a-4576-bf2a-e0e36709c2b8) |Block pod containers from sharing the host process ID namespace and host IPC namespace in a Kubernetes cluster. This recommendation is part of CIS 5.2.2 and CIS 5.2.3 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/BlockHostNamespace.json) |

+|[Kubernetes cluster containers should only use allowed AppArmor profiles](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F511f5417-5d12-434d-ab2e-816901e72a5e) |Containers should only use allowed AppArmor profiles in a Kubernetes cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/EnforceAppArmorProfile.json) |

+|[Kubernetes cluster containers should only use allowed capabilities](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fc26596ff-4d70-4e6a-9a30-c2506bd2f80c) |Restrict the capabilities to reduce the attack surface of containers in a Kubernetes cluster. This recommendation is part of CIS 5.2.8 and CIS 5.2.9 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerAllowedCapabilities.json) |

+|[Kubernetes cluster containers should only use allowed images](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ffebd0533-8e55-448f-b837-bd0e06f16469) |Use images from trusted registries to reduce the Kubernetes cluster's exposure risk to unknown vulnerabilities, security issues and malicious images. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerAllowedImages.json) |

+|[Kubernetes cluster containers should run with a read only root file system](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fdf49d893-a74c-421d-bc95-c663042e5b80) |Run containers with a read only root file system to protect from changes at run-time with malicious binaries being added to PATH in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ReadOnlyRootFileSystem.json) |

+|[Kubernetes cluster pod hostPath volumes should only use allowed host paths](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F098fc59e-46c7-4d99-9b16-64990e543d75) |Limit pod HostPath volume mounts to the allowed host paths in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/AllowedHostPaths.json) |

+|[Kubernetes cluster pods and containers should only run with approved user and group IDs](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff06ddb64-5fa3-4b77-b166-acb36f7f6042) |Control the user, primary group, supplemental group and file system group IDs that pods and containers can use to run in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/AllowedUsersGroups.json) |

+|[Kubernetes cluster pods should only use approved host network and port range](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F82985f06-dc18-4a48-bc1c-b9f4f0098cfe) |Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/HostNetworkPorts.json) |

+|[Kubernetes cluster should not allow privileged containers](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F95edb821-ddaf-4404-9732-666045e056b4) |Do not allow privileged containers creation in a Kubernetes cluster. This recommendation is part of CIS 5.2.1 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerNoPrivilege.json) |

+|[Kubernetes clusters should not allow container privilege escalation](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1c6e92c9-99f0-4e55-9cf2-0c234dc48f99) |Do not allow containers to run with privilege escalation to root in a Kubernetes cluster. This recommendation is part of CIS 5.2.5 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[6.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerNoPrivilegeEscalation.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Key Vault should have firewall enabled](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F55615ac9-af46-4a59-874e-391cc3dfb490) |Enable the key vault firewall so that the key vault is not accessible by default to any public IPs. You can then configure specific IP ranges to limit access to those networks. Learn more at: [https://docs.microsoft.com/azure/key-vault/general/network-security](../../../key-vault/general/network-security.md) |Audit, Deny, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Key%20Vault/AzureKeyVaultFirewallEnabled_Audit.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Azure Arc enabled Kubernetes clusters should have Microsoft Defender for Cloud extension installed](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F8dfab9c4-fe7b-49ad-85e4-1e9be085358f) |Microsoft Defender for Cloud extension for Azure Arc provides threat protection for your Arc enabled Kubernetes clusters. The extension collects data from all nodes in the cluster and sends it to the Azure Defender for Kubernetes backend in the cloud for further analysis. Learn more in [https://docs.microsoft.com/azure/defender-for-cloud/defender-for-containers-enable?pivots=defender-for-container-arc](../../../defender-for-cloud/defender-for-containers-enable.md?pivots=defender-for-container-arc). |AuditIfNotExists, Disabled |[5.0.2](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ASC_Azure_Defender_Kubernetes_Arc_Extension_Audit.json) |

+|[Deploy - Configure Log Analytics extension to be enabled on Windows virtual machine scale sets](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F3c1b3629-c8f8-4bf6-862c-037cb9094038) |Deploy Log Analytics extension for Windows virtual machine scale sets if the virtual machine image is in the list defined and the extension is not installed. If your scale set upgradePolicy is set to Manual, you need to apply the extension to all the virtual machine in the set by updating them. |DeployIfNotExists, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/LogAnalyticsExtension_Windows_VMSS_Deploy.json) |

+|[Container registries should not allow unrestricted network access](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd0793b48-0edc-4296-a390-4c75d1bdfd71) |Azure container registries by default accept connections over the internet from hosts on any network. To protect your registries from potential threats, allow access from only specific private endpoints, public IP addresses or address ranges. If your registry doesn't have network rules configured, it will appear in the unhealthy resources. Learn more about Container Registry network rules here: [https://aka.ms/acr/privatelink,](https://aka.ms/acr/privatelink,) [https://aka.ms/acr/portal/public-network](../../../container-registry/container-registry-access-selected-networks.md) and [https://aka.ms/acr/vnet](../../../container-registry/container-registry-vnet.md). |Audit, Deny, Disabled |[2.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Container%20Registry/ACR_NetworkRulesExist_AuditDeny.json) |

+|[Deploy - Configure Log Analytics extension to be enabled on Windows virtual machine scale sets](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F3c1b3629-c8f8-4bf6-862c-037cb9094038) |Deploy Log Analytics extension for Windows virtual machine scale sets if the virtual machine image is in the list defined and the extension is not installed. If your scale set upgradePolicy is set to Manual, you need to apply the extension to all the virtual machine in the set by updating them. |DeployIfNotExists, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/LogAnalyticsExtension_Windows_VMSS_Deploy.json) |

+|[Kubernetes cluster containers should only use allowed capabilities](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fc26596ff-4d70-4e6a-9a30-c2506bd2f80c) |Restrict the capabilities to reduce the attack surface of containers in a Kubernetes cluster. This recommendation is part of CIS 5.2.8 and CIS 5.2.9 which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerAllowedCapabilities.json) |

+|[Kubernetes cluster containers should run with a read only root file system](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fdf49d893-a74c-421d-bc95-c663042e5b80) |Run containers with a read only root file system to protect from changes at run-time with malicious binaries being added to PATH in a Kubernetes cluster. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ReadOnlyRootFileSystem.json) |

+|[Kubernetes cluster pods and containers should only run with approved user and group IDs](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Ff06ddb64-5fa3-4b77-b166-acb36f7f6042) |Control the user, primary group, supplemental group and file system group IDs that pods and containers can use to run in a Kubernetes Cluster. This recommendation is part of Pod Security Policies which are intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[5.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/AllowedUsersGroups.json) |

+|[Kubernetes cluster should not allow privileged containers](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F95edb821-ddaf-4404-9732-666045e056b4) |Do not allow privileged containers creation in a Kubernetes cluster. This recommendation is part of CIS 5.2.1 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[8.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerNoPrivilege.json) |

+|[Kubernetes clusters should not allow container privilege escalation](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F1c6e92c9-99f0-4e55-9cf2-0c234dc48f99) |Do not allow containers to run with privilege escalation to root in a Kubernetes cluster. This recommendation is part of CIS 5.2.5 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[6.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/ContainerNoPrivilegeEscalation.json) |

+|[Deploy - Configure Log Analytics extension to be enabled on Windows virtual machines](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F0868462e-646c-4fe3-9ced-a733534b6a2c) |Deploy Log Analytics extension for Windows virtual machines if the virtual machine image is in the list defined and the extension is not installed. |DeployIfNotExists, Disabled |[3.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Monitoring/LogAnalyticsExtension_Windows_VM_Deploy.json) |

+|[Configure backup on virtual machines without a given tag to an existing recovery services vault in the same location](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F09ce66bc-1220-4153-8104-e3f51c936913) |Enforce backup for all virtual machines by backing them up to an existing central recovery services vault in the same location and subscription as the virtual machine. Doing this is useful when there is a central team in your organization managing backups for all resources in a subscription. You can optionally exclude virtual machines containing a specified tag to control the scope of assignment. See [https://aka.ms/AzureVMCentralBackupExcludeTag](/azure/backup/backup-azure-auto-enable-backup#policy-1configure-backup-on-vms-without-a-given-tag-to-an-existing-recovery-services-vault-in-the-same-location). |auditIfNotExists, AuditIfNotExists, deployIfNotExists, DeployIfNotExists, disabled, Disabled |[9.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Backup/VirtualMachineBackup_Backup_DeployIfNotExists.json) |

+|[Configure backup on virtual machines without a given tag to an existing recovery services vault in the same location](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F09ce66bc-1220-4153-8104-e3f51c936913) |Enforce backup for all virtual machines by backing them up to an existing central recovery services vault in the same location and subscription as the virtual machine. Doing this is useful when there is a central team in your organization managing backups for all resources in a subscription. You can optionally exclude virtual machines containing a specified tag to control the scope of assignment. See [https://aka.ms/AzureVMCentralBackupExcludeTag](/azure/backup/backup-azure-auto-enable-backup#policy-1configure-backup-on-vms-without-a-given-tag-to-an-existing-recovery-services-vault-in-the-same-location). |auditIfNotExists, AuditIfNotExists, deployIfNotExists, DeployIfNotExists, disabled, Disabled |[9.0.0](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Backup/VirtualMachineBackup_Backup_DeployIfNotExists.json) |

+|[Kubernetes cluster services should only use allowed external IPs](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fd46c275d-1680-448d-b2ec-e495a3b6cc89) |Use allowed external IPs to avoid the potential attack (CVE-2020-8554) in a Kubernetes cluster. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.0.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/AllowedExternalIPs.json) |

+|[Kubernetes cluster pods should only use approved host network and port range](https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2F82985f06-dc18-4a48-bc1c-b9f4f0098cfe) |Restrict pod access to the host network and the allowable host port range in a Kubernetes cluster. This recommendation is part of CIS 5.2.4 which is intended to improve the security of your Kubernetes environments. This policy is generally available for Kubernetes Service (AKS), and preview for AKS Engine and Azure Arc enabled Kubernetes. For more information, see [https://aka.ms/kubepolicydoc](../concepts/policy-for-kubernetes.md). |audit, Audit, deny, Deny, disabled, Disabled |[4.2.1](https://github.com/Azure/azure-policy/blob/master/built-in-policies/policyDefinitions/Kubernetes/HostNetworkPorts.json) |

+|H2O SparklingWater for HDInsight |Spark |H2O Sparkling Water supports the following distributed algorithms: GLM, Naïve Bayes, Distributed Random Forest, Gradient Boosting Machine, Deep Neural Networks, Deep learning, K-means, PCA, Generalized Low Rank Models, Anomaly Detection, Autoencoders. |

+Azure HDInsight is a managed, full-spectrum, open-source analytics service in the cloud for enterprises. With HDInsight, you can use open-source frameworks such as Hadoop, Apache Spark, Apache Hive, LLAP, Apache Kafka, Apache Storm, and more, in your Azure environment.

+Azure HDInsight is a cloud distribution of Hadoop components. Azure HDInsight makes it easy, fast, and cost-effective to process massive amounts of data in a customizable environment. You can use the most popular open-source frameworks such as Hadoop, Spark, Hive, LLAP, Kafka, Storm and more. With these frameworks, you can enable a broad range of scenarios such as extract, transform, and load (ETL), data warehousing, machine learning, and IoT.

+|Productivity | Azure HDInsight enables you to use rich productive tools for Hadoop and Spark with your preferred development environments. These development environments include Visual Studio, VSCode, Eclipse, and IntelliJ for Scala, Python, Java, and .NET support. Data scientists can also collaborate using popular notebooks such as Jupyter and Zeppelin. |

+Azure HDInsight can be used for various scenarios in [big data](#what-is-big-data) processing. It can be historical data (data that's already collected and stored) or real-time data (data that's directly streamed from the source). The scenarios for processing such data can be summarized in the following categories:

+You can use HDInsight to extend your existing on-premises [big data](#what-is-big-data) infrastructure to Azure to apply the advanced analytics capabilities of the cloud.

+|Java virtual machine (JVM) languages | Many languages other than Java can run on a Java virtual machine (JVM). However, if you run some of these languages, you might have to install more components on the cluster. The following JVM-based languages are supported on HDInsight clusters: <ul><li>Clojure</li><li>Jython (Python for Java)</li><li>Scala</li></ul> |

+Spark, Hadoop, LLAP, and Storm don't store customer data, so these services automatically satisfy in-region data residency requirements including those specified in the [Trust Center](https://azuredatacentermap.azurewebsites.net/).

+ - Korea Central

+

+> [!NOTE]

+> Azure IoT solutions depend on services which may have different log retention periods. To help resolve your issue, please open a support request as soon as possible to help with troubleshooting.

+If you use the portal, you can create a storage account and container during configuration. Otherwise, to create a storage account, see [Create a storage account](../storage/common/storage-account-create.md) in the Azure storage documentation. Once you have a storage account, you can see how to create a blob container in the [Azure blob storage quickstarts](../storage/blobs/storage-quickstart-blobs-portal.md). By default, Azure IoT Hub uses key-based authentication to connect and authorize with Azure Storage. You can also configure user-assigned or system-assigned managed identities to authenticate Azure IoT Hub with Azure Storage. Managed identities provide Azure services with an automatically managed identity in Azure AD in a secure manner. To learn how to configure managed identities, see [Configure file upload with managed identities](iot-hub-managed-identity.md#configure-file-upload-with-managed-identities).

+File upload is subject to [Azure storage's firewall settings](../storage/common/storage-network-security.md). Based on your authentication configuration, you will need to ensure your devices can communicate with Azure storage.

+## July 11, 2022

+[Data Science VM ΓÇô Ubuntu 18.04](https://azuremarketplace.microsoft.com/marketplace/apps/microsoft-dsvm.ubuntu-1804?tab=overview) and [Data Science VM ΓÇô Ubuntu 20.04](https://azuremarketplace.microsoft.com/marketplace/apps/microsoft-dsvm.ubuntu-2004?tab=Overview)

+Version `22.07.08`

+Main changes:

+- Minor bug fixes.

+> Make sure to [Allow session level packages](../synapse-analytics/spark/apache-spark-manage-session-packages.md#session-scoped-python-packages) is enabled in the linked Synapse workspace.

+For more information about `run_config.spark.configuration` and general Spark configuration, see [SparkConfiguration Class](/python/api/azureml-core/azureml.core.runconfig.sparkconfiguration) and [Apache Spark's configuration documentation](https://spark.apache.org/docs/latest/configuration.html).

+| Attached Compute (Kubernetes cluster) | [Configure and attach Kubernetes cluster anywhere (preview)](how-to-attach-kubernetes-anywhere.md). |

+1. In the component palette to the left of the canvas, expand the **Component** section and find the **Select Columns in Dataset** component.

+1. In the component palette to the left of the canvas, expand the section **Component**, and find the **Clean Missing Data** component.

+1. In the component palette, expand the section **Component** and find the **Split Data** component.

+1. In the component palette, expand **Components**.

+1. Double click to open the component details, select **Edit column** selector.

+When you use the downloaded template to create the appliance, you can add components (antivirus, for example) to the template. Ensure that you have allowed access to the correct [URLs](migrate-appliance.md#public-cloud-urls) through Azure Firewall and that the *%ProgramData%\Microsoft Azure* folder is excluded from antivirus scanning.

+ - If your Linux servers support the older version of RSA key, you can generate the key using the `$ ssh-keygen -m PEM -t rsa -b 4096` command.

+- [Review](/azure/site-recovery/migrate-tutorial-windows-server-2008#limitations-and-known-issues) the limitations related to migrating Windows Server 2008 servers to Azure.

+The data and log files are hosted in [zone-redundant storage (ZRS)](../../storage/common/storage-redundancy.md#redundancy-in-the-primary-region). The log files are replicated to the standby server via the storage-level replication available with ZRS and applied to stand by server continuously.

+If there's a failover:

+The data and log files are hosted in [locally redundant storage (LRS)](../../storage/common/storage-redundancy.md#locally-redundant-storage). The log files are replicated to the standby server via the storage-level replication available with LRS and applied to stand by server continuously.

+|**Business Critical** |

+| Resource | Worker node | Coordinator node |

+|--|--|--|

+| Compute, vCores | 4, 8, 16, 32, 64, 96, 104 | 4, 8, 16, 32, 64, 96 |

+| Memory per vCore, GiB | 8 | 4 |

+| Storage size, TiB | 0.5, 1, 2 | 0.5, 1, 2 |

+| Storage type | General purpose (SSD) | General purpose (SSD) |

+| IOPS | Up to 3 IOPS/GiB | Up to 3 IOPS/GiB |

+| 64 | 432 or 512 | 256 |

+| 96 | 672 | 384 |

+| 104 | 672 | n/a |

+When a server is dropped, the database server backup will be retained for five days in the service. The database backup can be accessed and restored only from the Azure subscription where the server originally resided. The following recommended steps can be followed to recover a dropped PostgreSQL server resource within five days from the time of server deletion. The recommended steps will work only if the backup for the server is still available and not deleted from the system.

+3. Scroll below on Request Body section and paste the following replacing the "Dropped server Location"(e.g. CentralUS, EastUS etc.), "submissionTimestamp", and "resourceId". For "restorePointInTime", specify a value of "submissionTimestamp" minus **15 minutes** to ensure the command doesn't error out.

+ For example, if the current time is 2020-11-02T23:59:59.0000000Z, we recommend a minimum of 15 minutes prior restore point in time 2020-11-02T23:44:59.0000000Z. See below example and ensure that you're changing three parameters (location,restorePointInTime,sourceServerId) as per your restore requirements.

+- If you're trying to restore a server within five days, and still receive an error after accurately following the steps discussed earlier, open a support incident for assistance. If you're trying to restore a dropped server after five days, an error is expected since the backup file cannot be found. Don't open a support ticket in this scenario. The support team cannot provide any assistance if the backup is deleted from the system.

+1. In the **Load balancer** page, select **Create**.

+1. In the **Basics** tab of the **Create load balancer** page, enter, or select the following information:

+ | Setting | Value |

+ |-|--|

+ | **Project details** | |

+ | Subscription | Select your subscription. |

+ | Resource group | Select **CreatePrivLinkService-rg**. |

+ | **Instance details** | |

+ | Name | Enter **myLoadBalancer** |

+ | Region | Select **(US) East US 2**. |

+ | SKU | Leave the default **Standard**. |

+ | Type | Select **Internal**. |

+ | Tier | Select **Regional**. |

+

+1. Select **Next: Frontend IP configuration** at the bottom of the page.

+1. In **Frontend IP configuration**, select **+ Add a frontend IP**.

+1. Enter **LoadBalancerFrontend** in **Name**.

+1. Select **myBackendSubnet** in **Subnet**.

+1. Select **Dynamic** for **Assignment**.

+1. Select **Zone-redundant** in **Availability zone**.

+1. Select **Add**.

+1. Select **Next: Backend pools** at the bottom of the page.

+1. In the **Backend pools** tab, select **+ Add a backend pool**.

+1. Enter **myBackendPool** for **Name** in **Add backend pool**.

+1. Select **NIC** or **IP Address** for **Backend Pool Configuration**.

+1. Select **Save**.

+1. Select the **Next: Inbound rules** button at the bottom of the page.

+1. In **Load balancing rule** in the **Inbound rules** tab, select **+ Add a load balancing rule**.

+1. In **Add load balancing rule**, enter or select the following information:

+ | HA Ports | Check box. |

+1. Select **Add**.

+1. Select the blue **Review + create** button at the bottom of the page.

+1. Select **Create**.

+1. Search for **Private Link** in the **Search the Marketplace** box.

+1. Select **Create**.

+1. In **Overview** under **Private Link Center**, select the blue **Create private link service** button.

+1. In the **Basics** tab under **Create private link service**, enter, or select the following information:

+1. Select the **Outbound settings** tab or select **Next: Outbound settings** at the bottom of the page.

+1. In the **Outbound settings** tab, enter or select the following information:

+1. Select the **Access security** tab or select **Next: Access security** at the bottom of the page.

+1. Leave the default of **Role-based access control only** in the **Access security** tab.

+1. Select the **Tags** tab or select **Next: Tags** at the bottom of the page.

+1. Select the **Review + create** tab or select **Next: Review + create** at the bottom of the page.

+1. Select **Create** in the **Review + create** tab.

+1. In **Create virtual network**, enter or select this information in the **Basics** tab:

+1. Select the **IP Addresses** tab or select the **Next: IP Addresses** button at the bottom of the page.

+1. In the **IP Addresses** tab, enter this information:

+1. Under **Subnet name**, select the word **default**.

+1. In **Edit subnet**, enter this information:

+1. Select **Save**.

+1. Select the **Review + create** tab or select the **Review + create** button.

+1. Select **Create**.

+1. Select **Create**.

+1. In **Private Link Center**, select **Private endpoints** in the left-hand menu.

+1. In **Private endpoints**, select **+ Add**.

+1. In the **Basics** tab of **Create a private endpoint**, enter, or select this information:

+1. Select the **Next: Resource** button at the bottom of the page.

+1. In **Resource**, enter or select this information:

+1. Select the **Next: Virtual Network** button at the bottom of the screen.

+1. In **Configuration**, enter or select this information:

+1. Select **Next** until the **Review + create** tab then select **Create**.

+- West US 3

+- Canada Central

+- West Europe

+- France Central

+For an overview of how data sharing works, watch this short [demo](https://aka.ms/purview-data-share/overview-demo).

+* Pending share invitation is sent to your email alias or an email distribution group instead of your Azure sign-in email. Contact your data provider and ensure that they've sent the invitation to your Azure sign-in e-mail address..

+* You're accessing shared data using an analytics tool which uses a storage API version prior to February 2020. You can access shared data from Azure Synapse Analytics Spark and Databricks. You won't be able to access shared data using Azure Data Factory, Power BI or AzCopy.

+* YouΓÇÖre accessing shared data using ACLs. ACL is not supported for accessing shared data. You can use RBAC instead.

+For an overview of how data sharing works, watch this short [demo](https://aka.ms/purview-data-share/overview-demo).

+1. Select **Add Recipient**. Enter the Azure log in email address of who you want to share data with. Select **Create and Share**. Optionally, you can specify an **Expiration date** for when to terminate the share. You can share the same data with multiple recipients by clicking on **Add Recipient** multiple times.

+- Payload is currently limited to 2MB and 300 columns when scanning an asset.

+ - Tables including the columns, foreign keys and unique constraints

+This article provides a reference of log and metric data collected to analyze the performance and availability of Azure Cognitive Search. See [Monitoring Azure Cognitive Search](monitor-azure-cognitive-search.md) for an overview.

+Common entries include references to API keys - generic informational notifications like *Get Admin Key* and *Get Query keys*. These activities indicate requests that were made using the admin key (create or delete objects) or query key, but do not show the request itself. For information of this grain, you must configure resource logging.

+[Azure Monitor](../azure-monitor/overview.md) is enabled with every subscription to provide monitoring capabilities over all Azure resources, including Cognitive Search. When you sign up for search, Azure Monitor collects [**activity logs**](/azure/azure-monitor/agents/data-sources#azure-activity-log) and [**metrics**](/azure/azure-monitor/essentials/data-platform-metrics) as soon as you start using the service.

+Optionally, you can enable diagnostic settings to collect [**resource logs**](../azure-monitor/essentials/resource-logs.md). Resource logs contain detailed information about search service operations that's useful for deeper analysis and investigation.

+This article explains how monitoring works for Azure Cognitive Search. It also describes the system APIs that return information about your service.

+> [!NOTE]

+> Cognitive Search doesn't monitor individual user access to content on the search service. If you require this level of monitoring, you'll need to implement it in your client application.

+In the search service pages in Azure portal, you can find the current status of operations and capacity.

+> Because portal pages are refreshed every few minutes, the numbers reported are approximate, intended to give you a general sense of how well your system is handling requests. Actual metrics, such as queries per second (QPS) may be higher or lower than the number shown on the page. If precision is a requirement, consider using APIs.

+Cognitive Search REST APIs provide the **Usage** data that's visible in the portal. This information is retrieved from your search service, which you can obtain programmatically:

+## Monitor activity logs

+In Azure Cognitive Search, [**activity logs**](/azure/azure-monitor/agents/data-sources#azure-activity-log) reflect control plane activity, such as service and capacity updates, or API key usage or management. Activity logs are collected [free of charge](/azure/azure-monitor/usage-estimated-costs#pricing-model), with no configuration required. Data retention is 90 days, but you can configure durable storage for longer retention.

+1. In the Azure portal, find your search service. From the menu on the left, select **Activity logs** to view the logs for your search service.

+1. Entries will often include **Get Admin Key**, one entry for every call that [provided an admin API key](search-security-api-keys.md) on the request. There are no details about the call itself, just a notification that the admin key was used. For insights into content (or data plane) operations, you'll need to enable diagnostic settings and collect resource logs.

+1. See [Azure Monitor activity log](/azure/azure-monitor/essentials/activity-log) for general guidance on working with activity logs.

+1. See [Management REST API reference](/rest/api/searchmanagement/) for control plane activity that might appear in the log.

+The following screenshot shows the activity log signals that can be configured in an alert. These signals represent the entries you might see in the activity log.

+## Monitor metrics

+In Azure Cognitive Search, [**platform metrics**](/azure/azure-monitor/essentials/data-platform-metrics) measure query performance, indexing volume, and skillset invocation.

+Metrics are collected [free of charge](/azure/azure-monitor/usage-estimated-costs#pricing-model), with no configuration required. Platform metrics are stored for 93 days. However, in the portal you can only query a maximum of 30 days' worth of metrics data on any single chart. This limitation doesn't apply to log-based metrics.

+1. In the Azure portal, find your search service. From the menu on the left, under Monitoring, select **Metrics** to open metrics explorer.

+1. See [Tutorial: Analyze metrics for an Azure resource](/azure/azure-monitor/essentials/tutorial-metrics) for general guidance on using metrics explorer.

+1. See [Microsoft.Search/searchServices (Azure Monitor)](/azure/azure-monitor/essentials/metrics-supported#microsoftsearchsearchservices) for the platform metrics of Azure Cognitive Search.

+1. See [Monitoring data reference](monitor-azure-cognitive-search-data-reference.md) for supplemental descriptions and dimensions.

+1. See [Monitor queries](search-monitor-queries.md) for details about the query metrics.

+## Set up alerts

+Alerts help you to identify and address issues before they become a problem for application users. You can set alerts on [metrics](../azure-monitor/alerts/alerts-metric-overview.md), [resource logs](../azure-monitor/alerts/alerts-unified-log.md), and [activity logs](../azure-monitor/alerts/activity-log-alerts.md). Alerts are billable (see the [Pricing model](/azure/azure-monitor/usage-estimated-costs#pricing-model) for details).

+1. In the Azure portal, find your search service. From the menu on the left, under Monitoring, select **Alerts** to open metrics explorer.

+1. See [Tutorial: Create a metric alert for an Azure resource](/azure/azure-monitor/alerts/tutorial-metric-alert) for general guidance on setting up alerts from metrics explorer.

+The following table describes several rules. On a search service, throttling or query latency that exceeds a given threshold are the most commonly used alerts, but you might also want to be notified if a search service is deleted.

+| Alert type | Condition | Description |

+|:|:|:|

+| Search Latency (metric alert) | Whenever the average search latency is greater than a user-specified threshold (in seconds) | Send an SMS alert when average query response time exceeds the threshold. |

+| Throttled search queries percentage (metric alert) | Whenever the total throttled search queries percentage is greater than or equal to a user-specified threshold | Send an SMS alert when dropped queries begin to exceed the threshold.|

+| Delete Search Service (activity log alert) | Whenever the Activity Log has an event with Category='Administrative', Signal name='Delete Search Service (searchServices)', Level='critical' | Send an email if a search service is deleted in the subscription. |

+> Currently, there are no storage-related alerts (storage consumption data isn't aggregated or logged into the **AzureMetrics** table). To get storage alerts, you could [build a custom solution](../azure-monitor/insights/solutions.md) that emits resource-related notifications, where your code checks for storage size and handles the response.

+## Enable resource logging

+In Azure Cognitive Search, [**resource logs**](../azure-monitor/essentials/resource-logs.md) capture indexing and query operations on the search service itself.

+Resource Logs aren't collected and stored until you create a diagnostic setting. A diagnostic setting specifies data collection and storage. You can create multiple settings if you want to keep metrics and log data separate, or if you want more than one of each type of destination.

+Resource logging is billable (see the [Pricing model](../azure-monitor/usage-estimated-costs.md#pricing-model) for details), starting when you create a diagnostic setting. See [Diagnostic settings in Azure Monitor](../azure-monitor/essentials/diagnostic-settings.md) for general guidance.

+1. In the Azure portal, find your search service. From the menu on the left, under Monitoring, select **Diagnostic settings**.

+1. Select **+ Add diagnostic setting**.

+1. Give the diagnostic setting a name. Use granular and descriptive names if you're creating more than one setting.

+1. Select the logs and metrics that are in scope for this setting. Selections include "allLogs", "OperationLogs", "AllMetrics". You can exclude activity logs by selecting the "OperationLogs" category.

+ + See [Microsoft.Search/searchServices (in Supported categories for Azure Monitor resource logs)](../azure-monitor/essentials/resource-logs-categories.md#microsoftsearchsearchservices)

+ + See [Microsoft.Search/searchServices (in Supported metrics)](../azure-monitor/essentials/metrics-supported.md#microsoftsearchsearchservices)

+ + See [Azure Cognitive Search monitoring data reference](monitor-azure-cognitive-search-data-reference.md) for the extended schema

+1. Select **Send to Log Analytics workspace**. Kusto queries and data exploration will target the workspace.

+1. Optionally, select [other destinations](../azure-monitor/essentials/diagnostic-settings.md#destinations).

+1. Select **Save**.

+Once the workspace contains data, you can run log queries:

+## Sample Kusto queries

+> When you select **Logs** from the Azure Cognitive Search menu, Log Analytics is opened with the query scope set to the current search service. This means that log queries will only include data from that resource. If you want to query over multiple search services or combine data from other Azure services, select **Logs** from the **Azure Monitor** menu. See [Log query scope and time range in Azure Monitor Log Analytics](../azure-monitor/logs/scope.md) for details.

+Kusto is the query language used for Log Analytics. Below are some queries to get you started. See the [**Azure Cognitive Search monitoring data reference**](monitor-azure-cognitive-search-data-reference.md) for descriptions of schema elements used in a query. See [Analyze performance in Azure Cognitive Search](search-performance-analysis.md) for more examples and guidance specific to search service.

+### List metrics by name

+### List operations by name

+### Long-running queries

+This Kusto query against AzureDiagnostics returns `Query.Search` operations, sorted by duration (in milliseconds). For more examples of `Query.Search` queries, see [Analyze performance in Azure Cognitive Search](search-performance-analysis.md).

+### Indexer status

+This Kusto query returns the status of indexer operations. Results include the operation name, description of the request (which includes the name of the indexer), result status (Success or Failure), and the [HTTP status code](/rest/api/searchservice/http-status-codes). For more information about indexer execution, see [Monitor indexer status](search-howto-monitor-indexers.md).

+The monitoring framework for Azure Cognitive Search is provided by [Azure Monitor](../azure-monitor/overview.md). If you're not familiar with this service, start with [Monitoring Azure resources with Azure Monitor](../azure-monitor/essentials/monitor-azure-resource.md) to review the main concepts. You can also review the following articles for Azure Cognitive Search:

+Warnings are common with some types of indexers, and do not always indicate a problem. For example indexers that use Cognitive Services can report warnings when image or PDF files don't contain any text to process.

+| Skills-based indexing | 2 hours | Indeterminate | Typically runs on an internally managed, multi-tenant content processing cluster, depending on how complex the skillset is. A simple skill might execute on your search service if the service has capacity. Otherwise, skills-based indexer jobs execute off-service. Because the content processing cluster is multi-tenant, nodes are added to meet demand. If you experience a delay in on-demand or scheduled execution, it's probably because the system is either adding nodes or waiting for one to become available.|

+¹ For optimum processing, a search service determines the internal execution environment for the indexer operation. The execution environment is either the search service or a multi-tenant environment that's managed and secured by Microsoft at no extra cost. You cannot control or configure which environment is used. Using an internally managed cluster for skillset processing leaves more service-specific resources available for routine operations like queries and text indexing.

+The [Reset Documents API](/rest/api/searchservice/preview-api/reset-documents) accepts a list of document keys so that you can refresh specific documents. If specified, the reset parameters become the sole determinant of what gets processed, regardless of other changes in the underlying data. For example, if 20 blobs were added or updated since the last indexer run, but you only reset one document, only that document is processed.

+When you're testing this API for the first time, the following APIs can help you validate and test the behaviors:

+After you reset and rerun indexer jobs, you can monitor status from the search service, or obtain detailed information through resource logging.

+For indexers that run on a schedule, you can monitor operations by retrieving status from the search service, or obtain detailed information by enabling resource logging.

+³ Azure Functions (preview) refers to Functions under a Consumption, Premium and Dedicated [App Service plan](../app-service/overview-hosting-plans.md). The [App Service Environment (ASE)](../app-service/environment/overview.md) and [Azure Kubernetes Service (AKS)](../aks/intro-kubernetes.md) are not supported at this time.

+Indexers don't have dedicated processing resources. Based on this, indexers' status may show as idle before running (depending on other jobs in the queue) and run times may not be predictable. Other factors define indexer performance as well, such as document size, document complexity, image analysis, among others.

+Metrics reported out to portal pages are pulled from internal logs on a rolling 30-day cycle. For user-controlled log retention and more events, you will need [Azure Monitor](../azure-monitor/index.yml) and a supported approach for retaining log data. For more information about setting up resource logging for a search service, see [Collect and analyze log data](monitor-azure-cognitive-search.md).

+* Enable [resource logging](monitor-azure-cognitive-search.md) to monitor query and indexing workloads

+ 1. Create or identify an existing [Azure Storage account](../storage/common/storage-account-create.md) where you can archive the logs.

+ 1. Navigate to your Azure Cognitive Search service in the Azure portal.

+ 1. Under the Monitoring section on the left column, select **Diagnostic settings**.

+ 1. Select **+ Add diagnostic setting**.

+ 1. Check **Archive to a storage account**, provide your Storage account information, and check **OperationLogs** and **AllMetrics**.

+ 1. Select **Save**.

+This article explains how to measure query performance and volume using metrics and resource logging. It also explains how to get the query strings entered by application users.

+The Azure portal shows basic metrics about query latency, query load (QPS), and throttling. Historical data that feeds into these metrics can be accessed in the portal for 30 days. For longer retention, or to report on operational data and query strings, you must enable a [diagnostic setting](monitor-azure-cognitive-search.md) that specifies a storage option for persisting logged operations and metrics.

+> [!TIP]

+## Use resource logging

+The most important tool that an administrator has in diagnosing potential performance issues is [diagnostics logging](monitor-azure-cognitive-search.md) that collects operational data and metrics about your search service. Resource logging is enabled through [Azure Monitor](../azure-monitor/overview.md). There are costs associated with using Azure Monitor and storing data, but if you enable it for your service, it can be instrumental in investigating performance issues.

+There are multiple opportunities for latency to occur, whether during a network transfer, or during processing of content in the app services layer, or on a search service. A key benefit of resource logging is that activities are logged from the search service perspective, which means that the log can help you determine whether performance issues are due to problems with the query or indexing, or some other point of failure.

+## Data residency

+Azure Cognitive Search won't store data outside of your specified region without your authorization. Specifically, the following features write to an Azure Storage resource: [enrichment cache](cognitive-search-incremental-indexing-conceptual.md), [debug session](cognitive-search-debug-session.md), [knowledge store](knowledge-store-concept-intro.md).

+The storage account is one that you provide, and it could be in any region. If you put storage and search in the same region, and you also need network security, be aware of the [IP firewall restrictions](search-indexer-howto-access-ip-restricted.md) that prevent service connections in this scenario. When network security is a requirement, consider using the [trusted service exception](search-indexer-howto-access-trusted-service-exception.md) as a firewall alternative.

+Availability Zones don't impact the [Azure Cognitive Search Service Level Agreement](https://azure.microsoft.com/support/legal/sla/search/v1_0/). You still need three or more replicas for query high availability.

+Azure Cognitive Search doesn't provide an automated method of replicating search indexes across geographic regions, but there are some techniques that can make this process simple to implement and manage. These techniques are outlined in the next few sections.

+If you're already using indexer on one service, you can configure a second indexer on a second service to use the same data source object, pulling data from the same location. Each service in each region has its own indexer and a target index (your search index isn't shared, which means data is duplicated), but each indexer references the same data source.

+If you're using the Azure Cognitive Search REST API to [push content to your search index](tutorial-optimize-indexing-push-api.md), you can keep your various search services in sync by pushing changes to all search services whenever an update is required. In your code, make sure to handle cases where an update to one search service fails but succeeds for other search services.

+[Azure Traffic Manager](../traffic-manager/traffic-manager-overview.md) allows you to route requests to multiple geo-located websites that are then backed by multiple search services. One advantage of the Traffic Manager is that it can probe Azure Cognitive Search to confirm availability and route users to alternate search services if a service is down. In addition, if you're routing search requests through Azure Web Sites, Azure Traffic Manager can help you load balance cases where the web site is up, but search isn't. Here's an example of an architecture that leverages Traffic Manager.

+If you don't use indexers, you would use your application code to push objects and data to different search services in parallel. For more information, see [Keep data synchronized across multiple services](#data-sync).

+Because Azure Cognitive Search isn't a primary data storage solution, Microsoft doesn't provide a formal mechanism for self-service backup and restore. However, you can use the **index-backup-restore** sample code in this [Azure Cognitive Search .NET sample repo](https://github.com/Azure-Samples/azure-search-dotnet-samples) to back up your index definition and snapshot to a series of JSON files, and then use these files to restore the index, if needed. This tool can also move indexes between service tiers.

+Internal requests are secured and managed by Microsoft. You can't configure or control these connections. If you're locking down network access, no action on your part is required because internal traffic isn't customer-configurable.

+In Azure Cognitive Search, an individual index is generally not a securable object. As noted previously for key-based authentication, access to an index will include read or write permissions based on which API key you provide on the request, along with the context of an operation. In a query request, there's no concept of joining indexes or accessing multiple indexes simultaneously so all requests target a single index by definition. As such, construction of the query request itself (a key plus a single target index) defines the security boundary.

+However, if you're using Azure roles, you can [set permissions on individual indexes](search-security-rbac.md#grant-access-to-a-single-index) as long as it's done programmatically.

+> [!NOTE]

+## Data residency

+Azure Cognitive Search won't store data outside of your specified region without your authorization. Specifically, the following features write to an Azure Storage resource: [enrichment cache](cognitive-search-incremental-indexing-conceptual.md), [debug session](cognitive-search-debug-session.md), [knowledge store](knowledge-store-concept-intro.md).

+The storage account is one that you provide, and it could be in any region. If you put storage and search in the same region, and you also need network security, be aware of the [IP firewall restrictions](search-indexer-howto-access-ip-restricted.md) that prevent service connections in this scenario. When network security is a requirement, consider using the [trusted service exception](search-indexer-howto-access-trusted-service-exception.md) as a firewall alternative.

+### Activity and resource logs

+For Azure Cognitive Search, there's currently one built-in definition. It's for resource logging. With this built-in, you can assign a policy that identifies any search service that is missing resource logging, and then turns it on. For more information, see [Azure Policy Regulatory Compliance controls for Azure Cognitive Search](security-controls-policy.md).

+will scan for search services that do not have [resource logging](monitor-azure-cognitive-search.md), and

+provides centralized protection of your web applications from common exploits and vulnerabilities. The WAF is based on rules from the [OWASP core rule sets](https://owasp.org/www-project-modsecurity-core-rule-set/) 3.0 or 2.2.9.

+Consider reviewing the [<span class="underline">OWASP Top 10 Application Security Risks</span>](https://owasp.org/www-project-top-ten/).

+(OWASP)](https://www.owasp.org/) page on [using

+vulnerabilities](https://owasp.org/www-project-top-ten/2017/A9_2017-Using_Components_with_Known_Vulnerabilities)

+You scan your application and its dependent libraries to identify any known vulnerable components. Products that are available to perform this scan include [OWASP Dependency Check](https://owasp.org/www-project-dependency-check/),[Snyk](https://snyk.io/), and [Black Duck](https://www.blackducksoftware.com/).

+You can build a picture of the attack surface by scanning the application. Microsoft offers an attack surface analysis tool called [Attack Surface Analyzer](https://www.microsoft.com/download/details.aspx?id=58105). You can choose from many commercial dynamic testing and vulnerability scanning tools or services, including [OWASP Zed Attack Proxy Project](https://owasp.org/www-project-zap/), [Arachni](http://arachni-scanner.com/), [Skipfish](https://code.google.com/p/skipfish/), and [w3af](http://w3af.sourceforge.net/). These scanning tools crawl your app and map the parts of the application that are accessible over the web. You can also search the Azure Marketplace for similar [developer tools](https://azuremarketplace.microsoft.com/marketplace/apps/category/developer-tools?page=1).

+#If you have Az.ConnectedMachine installed, please make sure the version is at least 0.4.0

+$setting = @{"AntimalwareEnabled"=$true}

+$setting2 = @{

+"AntimalwareEnabled"=$true;

+"RealtimeProtectionEnabled"=$true;

+"ScheduledScanSettings"= @{

+ "isEnabled"=$true;

+ "day"=0;

+ "time"=120;

+ "scanType"="Quick"

+ };

+"Exclusions"= @{

+ "Extensions"=".ext1, .ext2";

+ "Paths"="";

+ "Processes"="sampl1e1.exe, sample2.exe"

+ };

+"SignatureUpdates"= @{

+ "FileSharesSources"=ΓÇ£ΓÇ¥;

+ "FallbackOrderΓÇ¥=ΓÇ£ΓÇ¥;

+ "ScheduleDay"=0;

+ "UpdateInterval"=0;

+ };

+"CloudProtection"=$true

+}

+New-AzConnectedMachineExtension -Name "IaaSAntimalware" -ResourceGroupName $resourceGroupName -MachineName $machineName -Location $location -SubscriptionId $subscriptionid -Publisher ΓÇ£Microsoft.Azure.SecurityΓÇ¥ -Settings $setting -ExtensionType ΓÇ£IaaSAntimalwareΓÇ¥

+The web application firewall (WAF) in [Azure Application Gateway](../../application-gateway/features.md#web-application-firewall) helps protect web applications from common web-based attacks like SQL injection, cross-site scripting attacks, and session hijacking. It comes preconfigured with protection from threats identified by the [Open Web Application Security Project (OWASP) as the top 10 common vulnerabilities](https://owasp.org/www-project-top-ten/).

+[Web application firewall (WAF)](../../web-application-firewall/afds/afds-overview.md) is a feature of Application Gateway that provides centralized protection of your web applications from common exploits and vulnerabilities. WAF is based on rules from the [Open Web Application Security Project (OWASP) core rule sets](https://owasp.org/www-project-modsecurity-core-rule-set/) 3.0 or 2.2.9.

+Web application firewall is based on rules from the [OWASP core rule sets](https://owasp.org/www-project-modsecurity-core-rule-set/) 3.0 or 2.2.9. Web applications are increasingly targets of malicious attacks that exploit common known vulnerabilities. Common among these exploits are SQL injection attacks, cross site scripting attacks to name a few. Preventing such attacks in application code can be challenging and may require rigorous maintenance, patching and monitoring at multiple layers of the application topology. A centralized web application firewall helps make security management much simpler and gives better assurance to application administrators against threats or intrusions. A WAF solution can also react to a security threat faster by patching a known vulnerability at a central location versus securing each of individual web applications. Existing application gateways can be converted to a web application firewall enabled application gateway easily.

+- The `_Im_Dns` or `imDns`normalized parsers are used instead of the Infoblox Parser.

+ Title: Export and transform historical log data from Microsoft Sentinel for big data analytics

+description: Learn how to export and transform large datasets from an Azure Log Analytics workspace to do security analytics.

+# Export and transform historical log data from Microsoft Sentinel for big data analytics

+Make your large datasets available for advanced analytics and machine learning by exporting and transforming the data from your Log Analytics workspace. Microsoft Sentinel allows you to orchestrate the export, transformation, and storage of large datasets from your Log Analytics workspace by using a notebook. The notebook steps you through a one-time export and transformation of historical data from your Log Analytics workspace to Azure Data Lake Storage Gen2 Storage.

+The following diagram shows how large datasets are exported, transformed, and stored for big data analytics by using the Log Analytics continuous data export and the one-time historical data export.

+This topic covers how to do a one-time export and transformation of your historical data. We recommend that you set up a continuous log export rule before you export historical logs. For more information, see [Set up continuous data export from Log Analytics](../azure-monitor/logs/logs-data-export.md).

+## Prerequisites

+Before you get started, make sure you have the appropriate roles and permissions, and that you've completed the tasks in the following list. The historical data export notebook uses Azure Synapse to work with data at scale.

+- [Review the required roles and permissions](notebooks-with-synapse.md#prerequisites)

+- [Connect to an Azure Machine Learning workspace](notebooks-with-synapse.md#connect-to-an-azure-machine-learning-workspace)

+- [Create an Azure Synapse workspace](notebooks-with-synapse.md#create-an-azure-synapse-workspace) that's linked to [Azure Data Lake Storage Gen2 storage](../storage/blobs/create-data-lake-storage-account.md)

+- [Configure your Azure Synapse Analytics integration](notebooks-with-synapse.md#configure-your-azure-synapse-analytics-integration)

+We recommend that you set up a continuous log export rule before you export historical logs. This step is to make sure there's no gap in the exported logs. We also recommend that data is exported to Azure Data Lake Storage Gen2 to take advantage of hierarchical namespaces. For more information, see:

+- [Set up continuous data export from Log Analytics](../azure-monitor/logs/logs-data-export.md)

+- [Azure Data Lake Storage Gen2 hierarchical namespace](../storage/blobs/data-lake-storage-namespace.md)

+## Launch the notebook

+Find the notebook template to save a copy to your Azure Machine Learning workspace.

+1. In Microsoft Sentinel, select **Notebooks**.

+1. Select the **Templates** tab.

+1. Enter **Export** in the search bar to find the notebook.

+1. Select the **Azure Synapse - Export Historical Log Data** notebook.

+ :::image type="content" source="media/notebooks-with-synapse-export-data/search-export-historical-log-data-template.png" alt-text="Screenshot of notebooks page with template tab selected and search result for Synapse notebook.":::

+1. Select **Create from template** at the bottom right-hand side of the page.

+1. In the **Clone notebook** pane, change the notebook name as appropriate.

+1. Select your Azure Machine Learning workspace.

+1. Select **Save**.

+1. After your notebook is deployed, select **Launch Notebook**. The notebook opens in your Azure Machine Learning workspace, from inside Microsoft Sentinel.

+1. At the top of the page in your Azure Machine Learning workspace, select a **Compute** instance to use for your notebook server.

+ - If you don't have a compute instance, [create a new one](../machine-learning/how-to-create-manage-compute-instance.md?tabs=#create).

+ - If you're creating a new compute instance in order to test your notebooks, create your compute instance with the **General Purpose** category.

+ - If your compute instance is stopped, make sure to start it. For more information, see [Run a notebook in the Azure Machine Learning studio](../machine-learning/how-to-run-jupyter-notebooks.md).

+ - Only you can see and use the compute instances you create. Your user files are stored separately from the VM and are shared among all compute instances in the workspace.

+ - The kernel is shown at the top right of your Azure Machine Learning window. If the kernel you need isn't selected, select a different version from the dropdown list.

+When your notebook server is created and started, you can start running your notebook cells. For more information, see [Run a notebook or Python script](../machine-learning/how-to-run-jupyter-notebooks.md#run-a-notebook-or-python-script).

+If your notebook hangs or you want to start over, restart the kernel and rerun the notebook cells from the beginning. If you restart the kernel, variables and other state are deleted. Rerun any initialization and authentication cells after you restart. To start over, go to the select **Kernel operations** > **Restart kernel**.

+## Configure the data to export

+Follow the step-by-step instructions in the notebook to export a subset of data from your Log Analytics workspace. Currently, data can only be exported from one table at a time.

+To get started, specify the subset of logs you want to export. Use a table name or a specific query in Kusto Query Language. Run some exploratory queries in your log analytics workspace to determine which subset of columns or rows you want to export.

+## Set the time range

+Before you run the data export, use the notebook to determine the size of data to be exported and the number of blobs that will be written. This step allows you to gauge the costs associated with the data export.

+Set the time range from which you want to export data. Initially, run the cell with only a few days of data to make sure that the cell output contains the expected set of columns and rows. Specify an end datetime and the number of days before that end datetime to start the query. If you set up a continuous data export rule, set the end datetime to the time when the continuous export was started. To get that time, check the creation time of the export storage container.

+The notebook uses batched, asynchronous calls to the Log Analytics REST API to retrieve data. Due to throttling and rate-limiting, you might need to adjust the default value of the query batch size. Review the detailed notes in the notebook on how to set that value.

+## Write data to Azure Data Lake storage

+After you run the queries, you can persist the data to Azure Data Lake Gen2 storage. Fill in the details of your storage account in the notebook cell. Any Azure storage account can be used here, but the hierarchical namespace used by Azure Data Lake Gen2 makes moving and repartitioning log data in downstream tasks much more efficient.

+You can view and rotate access keys for your storage account by going to the **Access Keys** page in Azure Storage. Always store and retrieve your keys securely by using a service like Azure Key Vault. Never stored keys as plaintext. You can use other Azure authentication methods like shared access signature (SAS tokens). For more information, see [Authorize requests to Azure Storage](/rest/api/storageservices/authorize-requests-to-azure-storage).

+## Partition data by using Apache Spark

+You might want to partition the data to allow for more performant data reads. The last section of the notebook repartitions the exported data by timestamp. The data rows are split across multiple files in multiple directories with rows of data grouped by timestamp. The notebook uses the directory structure `{base_path}/y=<year>/m=<month>/d=<day>/h=<hour>/m=<5-minute-interval>` for partitions.

+Encoding the timestamp values in the file path provides two key benefits:

+- The continuously exported and historical log data can be read in a unified way by any notebook or data pipeline that consume this data.

+- We can minimize the number of required file reads when loading data from a specific time range in downstream tasks.

+For a year's worth of historical log data, we might write files for over 100,000 separate partitions. So we rely on the multi-executor parallelism in Spark to do these writes efficiently.

+### Start Spark session

+In order to run code on a Synapse Spark pool, specify the name of the linked Azure Synapse workspace and Synapse Spark pool to use.

+ For `linkedservice`, get the Spark pool name by going to **Linked Services** in the left-hand side menu in Azure Machine Learning studio.

+Start the Spark session by running the cell in the **Start Spark Session** notebook section.

+### Repartition data by using PySpark

+After you start the Spark session, run the code in a notebook cell on the Spark pool by using the `%%synapse` cell magic at the start of the cell.

+If you encounter **UsageError: Line magic function `%synapse` not found**, make sure that you ran the notebook setup cells at the top of the notebook, and that the **azureml-synapse** package was installed successfully.

+The last few cells of the notebook write the historical logs to the same location as the continuously exported data, in the same format and with the same partition scheme.

+You're now able to process, transform and analyze security log data at scale by using Microsoft Sentinel and Azure Synapse notebooks. Get started by cloning a guided hunting notebook from the **Templates** tab in Microsoft Sentinel.

+## Next steps

+[Identify network beaconing on firewall logs by using a notebook in Microsoft Sentinel and Azure Synapse Analytics](notebooks-with-synapse-hunt.md)

+For more information, see:

+- [Blog post: Export Historical Log Data from Microsoft Sentinel](https://techcommunity.microsoft.com/t5/microsoft-sentinel-blog/export-historical-log-data-from-microsoft-sentinel/ba-p/3413418)

+- [Use Jupyter notebooks to hunt for security threats](notebooks.md)

+- [Tutorial: Get started with Jupyter notebooks and MSTICPy in Microsoft Sentinel](notebook-get-started.md)

+- [Link Azure Synapse Analytics and Azure Machine Learning workspaces and attach Apache Spark pools(preview)](../machine-learning/how-to-link-synapse-ml-workspaces.md)

+- [Create your first Microsoft Sentinel notebook](https://techcommunity.microsoft.com/t5/microsoft-sentinel-blog/creating-your-first-microsoft-sentinel-notebook/ba-p/2977745) (Blog series)

+ Title: Hunt on large firewall logs by using a notebook in Microsoft Sentinel and Azure Synapse Analytics

+description: Learn how to run big data queries in Azure Synapse Analytics with a sample notebook in Microsoft Sentinel.

+# Identify network beaconing on firewall logs by using a notebook in Microsoft Sentinel and Azure Synapse Analytics

+Get started with big data hunting in Microsoft Sentinel by using a built-in notebook that uses Azure Synapse Analytics. Use the notebook as a template for a real-world, sample security scenario.

+## Prerequisites

+If you haven't already, you'll need to complete the following tasks:

+- [Review the required roles and permissions](notebooks-with-synapse.md#prerequisites)

+- [Connect to an Azure Machine Learning workspace](notebooks-with-synapse.md#connect-to-an-azure-machine-learning-workspace)

+- [Create an Azure Synapse workspace](notebooks-with-synapse.md#create-an-azure-synapse-workspace)

+- [Configure your Azure Synapse Analytics integration](notebooks-with-synapse.md#configure-your-azure-synapse-analytics-integration)

+To hunt on large datasets, also consider the following optional tasks:

+- [Set up continuous data export from Log Analytics](../azure-monitor/logs/logs-data-export.md)

+- [Export historical log data from Microsoft Sentinel for big data analytics](notebooks-with-synapse-export-data.md)

+## Hunt by using a notebook with a sample security scenario

+Get started with hunting by using the built-in notebook **Azure Synapse - Detect potential network beaconing using Apache Spark**. Use this built-in notebook as a template and modify it for your organization's needs.

+### Launch a notebook

+Find a notebook template to save a copy to your Azure Machine Learning workspace.

+1. In Microsoft Sentinel, select **Notebooks**.

+1. Select the **Templates** tab.

+1. Enter **Synapse** in the search bar to find the notebook.

+1. Select the **Azure Synapse - Detect potential network beaconing using Apache Spark** notebook.

+1. Select **Create from template** at the bottom right-hand side of the page.

+1. In the **Clone notebook** pane, change the notebook name as appropriate.

+1. Select your Azure Machine Learning workspace.

+1. Select **Save**.

+1. After your notebook is deployed, select **Launch Notebook**.

+ The notebook opens in your Azure Machine Learning workspace, from inside Microsoft Sentinel. For more information, see [Launch a notebook in your Azure Machine Learning workspace](notebooks-hunt.md#launch-a-notebook-in-your-azure-ml-workspace).

+1. At the top of the page in your Azure Machine Learning workspace, select a **Compute** instance to use for your notebook server.

+ - If you don't have a compute instance, [create a new one](../machine-learning/how-to-create-manage-compute-instance.md?tabs=#create).

+ - If you're creating a new compute instance in order to test your notebooks, create your compute instance with the **General Purpose** category.

+ - If your compute instance is stopped, make sure to start it. For more information, see [Run a notebook in the Azure Machine Learning studio](../machine-learning/how-to-run-jupyter-notebooks.md).

+ - Only you can see and use the compute instances you create. Your user files are stored separately from the VM and are shared among all compute instances in the workspace.

+ - The kernel is shown at the top right of your Azure Machine Learning window. If the kernel you need isn't selected, select a different version from the dropdown list.

+When your notebook server is created and started, you can start running your notebook cells. For more information, see [Run a notebook or Python script](../machine-learning/how-to-run-jupyter-notebooks.md#run-a-notebook-or-python-script).

+If your notebook hangs or you want to start over, restart the kernel and rerun the notebook cells from the beginning. If you restart the kernel, variables and other state are deleted. Rerun any initialization and authentication cells after you restart. To start over, select **Kernel operations** > **Restart kernel**.

+### Run hunting queries by using the notebook

+Review and run the cells in the notebook to start hunting.

+1. Run the cells in the notebook's initial steps to load the required Python libraries and functions and to authenticate to Azure resources.

+1. When you get to the cell labeled **Start a Spark Session**, run the cell to start using your Azure Synapse session. Use your Apache Spark pool as the compute for your data preparation and data wrangle tasks instead of using your Azure Machine Learning compute.

+1. Run the subsequent cells to configure and run your queries on the data that's now stored in your Azure Data Lake Storage. For example, [update your look back period](notebooks-with-synapse.md#define-your-data-look-back-period) to include data from a specific time range.

+1. When you're done with your query, export the results from Azure Data Lake Storage back into your Log Analytics workspace.

+ The following code, shown in the **Export results from ADLS** step saves your query results as a single JSON file. Define your directory name and run the cell:

+ ```python

+ %%synapse

+ dir_name = "<dir-name>" # specify desired directory name

+ new_path = adls_path + dir_name

+ csl_beacon_pd = csl_beacon_df.coalesce(1).write.format("json").save(new_path)

+ ```

+1. After you've exported your data, you can stop your Spark session. After you've stopped your Spark session, and subsequent queries are run using the default Azure Machine Learning compute indicated in the **Compute** field at the top of the page.

+ Run the cell in the **Stop Spark Session** step:

+ ```python

+ %synapse stop

+ ```

+1. Export your JSON file with your query results from Azure Data Lake Storage to a local file system.

+ Use the code in the **Export results from ADLS to local filesystem**, **Download the files from ADLS**, and **Display results** steps to save your JSON file locally and view them.

+1. After you've saved your results locally, you can enrich them with extra data and run visualizations. For example, the **Azure Synapse - Detect potential network beaconing using Apache Spark** notebook provides extra steps, to take the following actions:

+ - Enrich results with IP address GeoLocation, WhoIs, and other threat intelligence data, to have a more complete picture of the anomalous network behaviors.

+ - Run MSTICPy visualizations to map locations while looking at the distribution of remote network connections or other events.

+ The results can be written back to Microsoft Sentinel for further investigation. For example, you can create custom incidents, watchlists, or hunting bookmarks from the results.

+ Use these steps as they are to detect potential network beaconing, or use them as a template and modify them for your organization's needs.

+## Next steps

+For more information, see:

+- [Use Jupyter notebooks to hunt for security threats](notebooks.md)

+- [Tutorial: Get started with Jupyter notebooks and MSTICPy in Microsoft Sentinel](notebook-get-started.md)

+- [Link Azure Synapse Analytics and Azure Machine Learning workspaces and attach Apache Spark pools(preview)](../machine-learning/how-to-link-synapse-ml-workspaces.md)

+- [Create your first Microsoft Sentinel notebook](https://techcommunity.microsoft.com/t5/microsoft-sentinel-blog/creating-your-first-microsoft-sentinel-notebook/ba-p/2977745) (Blog series)

+ Title: Configure big data analytics settings for Azure Synapse Analytics

+description: Learn how to set up Azure Synapse Analytics with Microsoft Sentinel notebooks to run big data queries.

+# Configure big data analytics settings for Azure Synapse Analytics

+Enable large-scale security analytics by integrating Microsoft Sentinel notebooks with Azure Synapse analytics.

+While KQL and Log Analytics are the primary tools and solutions for querying and analyzing data in Microsoft Sentinel, Azure Synapse provides extra features for big data analysis. Azure Synapse has built-in data lake access and the Apache Spark distributed processing engine.

+Integrate with Azure Synapse to get:

+For example, use notebooks with Azure Synapse to hunt for anomalous behaviors from network firewall logs to detect potential network beaconing. Or use notebooks with Azure Synapse to train and build machine learning models on top of data collected from a Log Analytics workspace.

+> [!IMPORTANT]

+> Microsoft Sentinel notebook integration with Azure Synapse Analytics is currently in PREVIEW. The [Azure Preview Supplemental Terms](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) include additional legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.

+>

+## Prerequisites

+We recommend that you learn about Microsoft Sentinel notebooks in general before performing the procedures in this article. To get started, see and [Use Jupyter notebooks to hunt for security threats](notebooks.md) and [Tutorial: Get started with Jupyter notebooks and MSTICPy in Microsoft Sentinel](notebook-get-started.md).

+## Connect to an Azure Machine Learning workspace

+To use Microsoft Sentinel notebooks with Azure Synapse, you must first connect an Azure Machine Learning workspace. If you aren't already connected, see [Create an Azure Machine Learning workspace from Microsoft Sentinel](notebooks-hunt.md#create-an-azure-ml-workspace-from-microsoft-sentinel).

+## Create an Azure Synapse workspace

+To use Microsoft Sentinel notebooks with Azure Synapse, you must connect an Azure Synapse workspace.

+1. In Microsoft Sentinel, select **Notebooks**.

+1. At the top of the Microsoft Sentinel **Notebooks** page, select **Configure Azure Synapse**.

+1. Select **Create new Azure Synapse workspace**.

+1. Select or create a Data Lake that is in the same region with your Microsoft Sentinel workspace. This step is required to export your data. An Azure Data Lake Storage Gen2 is a built-in Data Lake that comes with every Azure Synapse workspace.

+Microsoft Sentinel provides the built-in notebook **Azure Synapse - Configure Azure ML and Azure Synapse Analytics** to guide you through the configurations required to integrate with Azure Synapse.

+You only need to run this notebook once to configure your Azure Synapse integration to your Microsoft Sentinel workspace.

+### Launch the notebook

+To launch the **Azure Synapse - Configure Azure ML and Azure Synapse Analytics** notebook:

+1. In Microsoft Sentinel, select **Notebooks**.

+1. Select the **Templates** tab.

+1. Enter **Synapse** in the search bar to find the notebook.

+1. Select the **Azure Synapse - Configure Azure ML and Azure Synapse Analytics** notebook.

+1. Select **Create from template** at the bottom right-hand side of the page.

+1. In the **Clone notebook** pane, change the notebook name as appropriate.

+1. Select your Azure Machine Learning workspace you previously created.

+1. Select **Save**.

+ The notebook opens in your Azure Machine Learning workspace, inside Microsoft Sentinel. For more information, see [Launch a notebook in your Azure Machine Learning workspace](notebooks-hunt.md#launch-a-notebook-in-your-azure-ml-workspace).

+### Configure the integration

+To integrate Azure Machine Learning and Azure Synapse Analytics:

+1. Run the cells in step 5, **Configure Azure ML Workspace and Linked Services** to ensure that your Azure Machine Learning workspace can communicate with your Azure Synapse workspace. For more information, see [Link Azure Synapse Analytics and Azure Machine Learning workspaces and attach Apache Spark pools](../machine-learning/how-to-link-synapse-ml-workspaces.md).

+When not in an Azure Synapse session, Microsoft Sentinel defaults to the Azure Machine Learning compute selected in the **Compute** field at the top of the **Notebooks** page.

+Use the following code, which you can copy from here or the notebook **Azure Synapse - Detect potential network beaconing using Apache Spark**, to start and stop your Azure Synapse session.

+### Define your data look back period

+- If you're interested in data from a specific date, specify November 15, 2021 as the current date, and the query will run only on data from November 15, 2021.

+- **If you've already created a linked service between your Azure Machine Learning and the new Azure Synapse workspace**:

+ 1. Enter the name for the `linkservice` parameter in the following code cell, then rerun the cell and the subsequent cells:

+ amlworkspace = "<workspace name>" # fill in your Azure Machine Learning workspace name

+ resource_group = '<resource group of workspace>' # fill in your resource groups for your Azure Machine Learning workspace

+- **If you don't yet have a linked service between your Azure Machine Learning and Azure Synapse workspaces**, make sure to run the **Azure Synapse ΓÇô Configure Azure ML and Azure Synapse Analytics** notebook to configure the linked service before running the **Azure Synapse ΓÇô Detect potential network beaconing using Apache Spark** notebook.

+- [Export and transform historical log data from Microsoft Sentinel for big data analytics](notebooks-with-synapse-export-data.md)

+- [Identify network beaconing on firewall logs by using a notebook in Microsoft Sentinel and Azure Synapse Analytics](notebooks-with-synapse-hunt.md)

+|**Apache HTTP Server** |Data connector, analytics rules, hunting queries, parser | IT Operations |Microsoft |

+* **SentinelHealth data table**. Provides insights on health drifts, such as latest failure events per connector, or connectors with changes from success to failure states, which you can use to create alerts and other automated actions. Find more information [here](/azure/sentinel/monitor-data-connector-health).

+East US, East US 2, Central US, South Central US, North Central US, West US, West US 2, West US 3, West Europe, North Europe, UK South, Southeast Asia, Australia East, Canada Central, UAE North, Central India, Korea Central, East Asia, Japan East, South Africa North, Brazil South, and France Central.

+ Title: Client-side encryption for blobs

+description: The Blob Storage client library supports client-side encryption and integration with Azure Key Vault for users requiring encryption on the client.

+# Client-side encryption for blobs

+The [Azure Blob Storage client library for .NET](/dotnet/api/overview/azure/storage) supports encrypting data within client applications before uploading to Azure Storage, and decrypting data while downloading to the client. The library also supports integration with [Azure Key Vault](https://azure.microsoft.com/services/key-vault/) for storage account key management.

+> [!IMPORTANT]

+> Blob Storage supports both service-side and client-side encryption. For most scenarios, Microsoft recommends using service-side encryption features for ease of use in protecting your data. To learn more about service-side encryption, see [Azure Storage encryption for data at rest](../common/storage-service-encryption.md).

+For a step-by-step tutorial that leads you through the process of encrypting blobs using client-side encryption and Azure Key Vault, see [Encrypt and decrypt blobs in Microsoft Azure Storage using Azure Key Vault](../blobs/storage-encrypt-decrypt-blobs-key-vault.md).

+## About client-side encryption

+The Azure Blob Storage client library uses [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) in order to encrypt user data. There are two versions of client-side encryption available in the client library:

+- Version 2.x uses [Galois/Counter Mode (GCM)](https://en.wikipedia.org/wiki/Galois/Counter_Mode) mode with AES.

+- Version 1.x uses [Cipher Block Chaining (CBC)](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher-block_chaining_.28CBC.29) mode with AES.

+> [!WARNING]

+> Using version 1.x of client-side encryption is no longer recommended due to a security vulnerability in the client library's implementation of CBC mode. For more information about this security vulnerability, see [Azure Storage updating client-side encryption in SDK to address security vulnerability](https://aka.ms/azstorageclientencryptionblog). If you are currently using version 1.x, we recommend that you update your application to use version 2.x and migrate your data. See the following section, [Mitigate the security vulnerability in your applications](#mitigate-the-security-vulnerability-in-your-applications), for further guidance.

+## Mitigate the security vulnerability in your applications

+Due to a security vulnerability discovered in the Blob Storage client library's implementation of CBC mode, Microsoft recommends that you take one or more of the following actions immediately:

+- Consider using service-side encryption features instead of client-side encryption. For more information about service-side encryption features, see [Azure Storage encryption for data at rest](../common/storage-service-encryption.md).

+- If you need to use client-side encryption, then migrate your applications from client-side encryption v1 to client-side encryption v2.

+ Client-side encryption v2 is available only in version 12.x and later of the Azure Blob Storage client libraries. If your application is using an earlier version of the client library, you must first upgrade your code to version 12.x or later, and then decrypt and re-encrypt your data with client-side encryption v2. If necessary, you can use version 12.x side-by-side with an earlier version of the client library while you are migrating your code. For code examples, see [Example: Encrypting and decrypting a blob with client-side encryption v2](#example-encrypting-and-decrypting-a-blob-with-client-side-encryption-v2).

+The following table summarizes the steps you'll need to take if you choose to migrate your applications to client-side encryption v2:

+| Client-side encryption status | Recommended actions |

+|||

+| Application is using client-side encryption with Azure Blob Storage SDK version 11.x or earlier | Update your application to use Blob Storage SDK version 12.x or later. If necessary, you can use version 12.x side-by-side with an earlier version of the client library while you are migrating your code. [Learn more...](https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/storage/Azure.Storage.Blobs/AzureStorageNetMigrationV12.md)<br/><br/>Update your code to use client-side encryption v2. [Learn more...](#example-encrypting-and-decrypting-a-blob-with-client-side-encryption-v2)<br/><br/>Download any encrypted data to decrypt it, then reencrypt it with client-side encryption v2. [Learn more...](#reencrypt-previously-encrypted-data-with-client-side-encryption-v2) |

+| Application is using client-side encryption with Azure Blob Storage SDK version 12.x or later | Update your code to use client-side encryption v2. [Learn more...](#example-encrypting-and-decrypting-a-blob-with-client-side-encryption-v2)<br/><br/>Download any encrypted data to decrypt it, then reencrypt it with client-side encryption v2. [Learn more...](#reencrypt-previously-encrypted-data-with-client-side-encryption-v2) |

+Additionally, Microsoft recommends that you take the following steps to help secure your data:

+- Configure your storage accounts to use private endpoints to secure all traffic between your virtual network (VNet) and your storage account over a private link. For more information, see [Use private endpoints for Azure Storage](../common/storage-private-endpoints.md).

+- Limit network access to specific networks only.

+## How client-side encryption works

+The Azure Blob Storage client libraries use envelope encryption to encrypt and decrypt your data on the client side. Envelope encryption encrypts a key with one or more additional keys.

+The Blob Storage client libraries rely on Azure Key Vault to protect the keys that are used for client-side encryption. For more information about Azure Key Vault, see [What is Azure Key Vault?](../../key-vault/general/overview.md).

+### Encryption and decryption via the envelope technique

+Encryption via the envelope technique works as follows:

+1. The Azure Storage client library generates a content encryption key (CEK), which is a one-time-use symmetric key.

+1. User data is encrypted using the CEK.

+1. The CEK is then wrapped (encrypted) using the key encryption key (KEK). The KEK is identified by a key identifier and can be either an asymmetric key pair or a symmetric key. You can manage the KEK locally or store it in an Azure Key Vault.

+ The Azure Storage client library itself never has access to KEK. The library invokes the key wrapping algorithm that is provided by Key Vault. Users can choose to use custom providers for key wrapping/unwrapping if desired.

+1. The encrypted data is then uploaded to Azure Blob Storage. The wrapped key together with some additional encryption metadata is stored as metadata on the blob.

+Decryption via the envelope technique works as follows:

+1. The Azure Storage client library assumes that the user is managing the KEK either locally or in an Azure Key Vault. The user doesn't need to know the specific key that was used for encryption. Instead, a key resolver that resolves different key identifiers to keys can be set up and used.

+1. The client library downloads the encrypted data along with any encryption material that is stored in Azure Storage.

+1. The wrapped CEK) is then unwrapped (decrypted) using the KEK. The client library doesn't have access to the KEK during this process, but only invokes the unwrapping algorithm of the Azure Key Vault or other key store.

+1. The client library uses the CEK to decrypt the encrypted user data.

+### Encryption/decryption on blob upload/download

+The Blob Storage client library supports encryption of whole blobs only on upload. For downloads, both complete and range downloads are supported.

+During encryption, the client library generates a random initialization vector (IV) of 16 bytes and a random CEK of 32 bytes, and performs envelope encryption of the blob data using this information. The wrapped CEK and some additional encryption metadata are then stored as blob metadata along with the encrypted blob.

+When a client downloads an entire blob, the wrapped CEK is unwrapped and used together with the IV to return the decrypted data to the client.

+Downloading an arbitrary range in the encrypted blob involves adjusting the range provided by users in order to get a small amount of additional data that can be used to successfully decrypt the requested range.

+All blob types (block blobs, page blobs, and append blobs) can be encrypted/decrypted using this scheme.

+> [!WARNING]

+> If you are editing or uploading your own metadata for the blob, you must ensure that the encryption metadata is preserved. If you upload new metadata without also preserving the encryption metadata, then the wrapped CEK, IV, and other metadata will be lost and you will not be able to retrieve the contents of the blob. Calling the [Set Blob Metadata](/rest/api/storageservices/set-blob-metadata) operation always replaces all blob metadata.

+>

+> When reading from or writing to an encrypted blob, use whole blob upload commands, such as [Put Blob](/rest/api/storageservices/put-blob), and range or whole blob download commands, such as Get Blob. Avoid writing to an encrypted blob using protocol operations such as [Put Block](/rest/api/storageservices/put-block), [Put Block List](/rest/api/storageservices/put-block-list), [Put Page](/rest/api/storageservices/put-page), or [Append Block](/rest/api/storageservices/append-block). Calling these operations on an encrypted blob can corrupt it and make it unreadable.

+## Example: Encrypting and decrypting a blob with client-side encryption v2

+The code example in this section shows how to use client-side encryption v2 to encrypt and decrypt a blob.

+> [!IMPORTANT]

+> If you have data that has been previously encrypted with client-side encryption v1, then you'll need to decrypt that data and reencrypt it with client-side encryption v2. See the guidance and sample for your client library below.

+### [.NET](#tab/dotnet)

+To use client-side encryption from your .NET code, reference the [Blob Storage client library](/dotnet/api/overview/azure/storage.blobs-readme). Make sure that you are using version 12.13.0 or later. If you need to migrate from version 11.x to version 12.13.0, see the [Migration guide](https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/storage/Azure.Storage.Blobs/AzureStorageNetMigrationV12.md).

+Two additional packages are required for Azure Key Vault integration for client-side encryption:

+- The **Azure.Core** package provides the `IKeyEncryptionKey` and `IKeyEncryptionKeyResolver` interfaces. The Blob Storage client library for .NET already defines this assembly as a dependency.

+- The **Azure.Security.KeyVault.Keys** package (version 4.x and later) provides the Key Vault REST client and the cryptographic clients that are used with client-side encryption. You'll need to ensure that this package is referenced in your project if you're using Azure Key Vault as your key store.

+ Azure Key Vault is designed for high-value master keys, and throttling limits per key vault reflect this design. As of version 4.1.0 of Azure.Security.KeyVault.Keys, the `IKeyEncryptionKeyResolver` interface doesn't support key caching. Should caching be necessary due to throttling, you can use the approach demonstrated in [this sample](/samples/azure/azure-sdk-for-net/azure-key-vault-proxy/) to inject a caching layer into an `Azure.Security.KeyVault.Keys.Cryptography.KeyResolver` instance.

+Developers can provide a key, a key resolver, or both a key and a key resolver. Keys are identified using a key identifier that provides the logic for wrapping and unwrapping the CEK. A key resolver is used to resolve a key during the decryption process. The key resolver defines a resolve method that returns a key given a key identifier. The resolver provides users the ability to choose between multiple keys that are managed in multiple locations.

+On encryption, the key is used always and the absence of a key will result in an error.

+On decryption, if the key is specified and its identifier matches the required key identifier, that key is used for decryption. Otherwise, the client library attempts to call the resolver. If there's no resolver specified, then the client library throws an error. If a resolver is specified, then the key resolver is invoked to get the key. If the resolver is specified but doesn't have a mapping for the key identifier, then the client library throws an error.

+To use client-side encryption, create a **ClientSideEncryptionOptions** object and set it on client creation with **SpecializedBlobClientOptions**. You can't set encryption options on a per-API basis. Everything else will be handled by the client library internally.

+```csharp

+// Your key and key resolver instances, either through Azure Key Vault SDK or an external implementation.

+IKeyEncryptionKey key;

+IKeyEncryptionKeyResolver keyResolver;

+// Create the encryption options to be used for upload and download.

+ClientSideEncryptionOptions encryptionOptions = new ClientSideEncryptionOptions(ClientSideEncryptionVersion.V2_0)

+{

+ KeyEncryptionKey = key,

+ KeyResolver = keyResolver,

+ // String value that the client library will use when calling IKeyEncryptionKey.WrapKey()

+ KeyWrapAlgorithm = "some algorithm name"

+};

+// Set the encryption options on the client options.

+BlobClientOptions options = new SpecializedBlobClientOptions() { ClientSideEncryption = encryptionOptions };

+// Create blob client with client-side encryption enabled.

+// Client-side encryption options are passed from service clients to container clients,

+// and from container clients to blob clients.

+// Attempting to construct a BlockBlobClient, PageBlobClient, or AppendBlobClient from a BlobContainerClient

+// with client-side encryption options present will throw, as this functionality is only supported with BlobClient.

+BlobClient blob = new BlobServiceClient(connectionString, options).GetBlobContainerClient("my-container").GetBlobClient("myBlob");

+// Upload the encrypted contents to the blob.

+blob.Upload(stream);

+// Download and decrypt the encrypted contents from the blob.

+MemoryStream outputStream = new MemoryStream();

+blob.DownloadTo(outputStream);

+```

+You can apply encryption options to a **BlobServiceClient**, **BlobContainerClient**, or **BlobClient** constructors that accept **BlobClientOptions** objects.

+If a **BlobClient** object already exists in your code but lacks client-side encryption options, then you can use an extension method to create a copy of that object with the given **ClientSideEncryptionOptions**. This extension method avoids the overhead of constructing a new **BlobClient** object from scratch.

+```csharp

+using Azure.Storage.Blobs.Specialized;

+// An existing BlobClient instance and encryption options.

+BlobClient plaintextBlob;

+ClientSideEncryptionOptions encryptionOptions;

+// Get a copy of the blob that uses client-side encryption.

+BlobClient clientSideEncryptionBlob = plaintextBlob.WithClientSideEncryptionOptions(encryptionOptions);

+```

+After you update your code to use client-side encryption v2, make sure that you deencrypt and reencrypt any existing encrypted data, as described in [Reencrypt previously encrypted data with client-side encryption v2](#reencrypt-previously-encrypted-data-with-client-side-encryption-v2).

+### [Java](#tab/java)

+To use client-side encryption from your Java code, reference the [Blob Storage client library](/jav).

+For sample code that shows how to use client-side encryption v2 from Java, see [ClientSideEncryptionV2Uploader.java](https://github.com/wastore/azure-storage-samples-for-java/blob/f1621c807a4b2be8b6e04e226cbf0a288468d7b4/ClientSideEncryptionMigration/src/main/java/ClientSideEncryptionV2Uploader.java).

+After you update your code to use client-side encryption v2, make sure that you deencrypt and reencrypt any existing encrypted data, as described in [Reencrypt previously encrypted data with client-side encryption v2](#reencrypt-previously-encrypted-data-with-client-side-encryption-v2).

+### [Python v12 SDK](#tab/python)

+To use client-side encryption from your Python code, reference the [Blob Storage client library](/python/api/overview/azure/storage-blob-readme). Make sure that you are using version 12.13.0 or later. If you need to migrate from an earlier version of the Java client library, see the [Blob Storage migration guide for Python](https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/storage/azure-storage-blob/migration_guide.md).

+The following example shows how to use client-side migration v2 from Python:

+```python

+blob_client = blob_service_client.get_blob_client(container=container_name, blob=blob_name)

+ blob_client.require_encryption = True

+ blob_client.key_encryption_key = kek

+ blob_client.encryption_version = ΓÇÿ2.0ΓÇÖ # Use Version 2.0!

+ with open("decryptedcontentfile.txt", "rb") as stream:

+ blob_client.upload_blob(stream, overwrite=OVERWRITE_EXISTING)

+```

+After you update your code to use client-side encryption v2, make sure that you deencrypt and reencrypt any existing encrypted data, as described in [Reencrypt previously encrypted data with client-side encryption v2](#reencrypt-previously-encrypted-data-with-client-side-encryption-v2).

+## Reencrypt previously encrypted data with client-side encryption v2

+Any data that was previously encrypted with client-side encryption v1 must be decrypted and then reencrypted with client-side encryption v2 to mitigate the security vulnerability. Decryption requires downloading the data and reencryption requires reuploading it to Blob Storage.

+### [.NET](#tab/dotnet)

+For a sample project that shows how to migrate data from client-side encryption v1 to v2 and how to encrypt data with client-side encryption v2 in .NET, see the [Encryption migration sample project](https://github.com/wastore/azure-storage-samples-for-net/tree/master/ClientSideEncryptionMigration).

+### [Java](#tab/java)

+For a sample project that shows how to migrate data from client-side encryption v1 to v2 and how to encrypt data with client-side encryption v2 in Java, see [ClientSideEncryptionV2Uploader](https://github.com/wastore/azure-storage-samples-for-java/blob/f1621c807a4b2be8b6e04e226cbf0a288468d7b4/ClientSideEncryptionMigration/src/main/java/ClientSideEncryptionV2Uploader.java).

+### [Python](#tab/python)

+For a sample project that shows how to migrate data from client-side encryption v1 to v2 and how to encrypt data with client-side encryption v2 in Python, see [Client Side Encryption Migration from V1 to V2](https://github.com/wastore/azure-storage-samples-for-python/tree/master/ClientSideEncryptionToServerSideEncryptionMigrationSamples/ClientSideEncryptionV1ToV2).

+## Client-side encryption and performance

+Keep in mind that encrypting your storage data results in additional performance overhead. When you use client-side encryption in your application, the client library must securely generate the CEK and IV, encrypt the content itself, communicate with your chosen keystore for key-enveloping, and format and upload additional metadata. This overhead varies depending on the quantity of data being encrypted. We recommend that customers always test their applications for performance during development.

+## Next steps

+- [Azure Storage updating client-side encryption in SDK to address security vulnerability](https://aka.ms/azstorageclientencryptionblog)

+- [Azure Storage encryption for data at rest](../common/storage-service-encryption.md)

+- [Azure Key Vault documentation](../../key-vault/general/overview.md)

+Azure Storage uses service-side encryption (SSE) to automatically encrypt your data when it is persisted to the cloud. Azure Storage encryption protects your data and to help you to meet your organizational security and compliance commitments.

+Microsoft recommends using service-side encryption to protect your data for most scenarios. However, the Azure Storage client libraries for Blob Storage and Queue Storage also provide client-side encryption for customers who need to encrypt data on the client. For more information, see [Client-side encryption for blobs and queues](#client-side-encryption-for-blobs-and-queues).

+## About Azure Storage service-side encryption

+- You can specify a *customer-managed key* to use for encrypting and decrypting data in Blob Storage and in Azure Files.^1,2 Customer-managed keys must be stored in Azure Key Vault or Azure Key Vault Managed Hardware Security Model (HSM) (preview). For more information about customer-managed keys, see [Use customer-managed keys for Azure Storage encryption](./customer-managed-keys-overview.md).

+- You can specify a *customer-provided key* on Blob Storage operations. A client making a read or write request against Blob Storage can include an encryption key on the request for granular control over how blob data is encrypted and decrypted. For more information about customer-provided keys, see [Provide an encryption key on a request to Blob Storage](../blobs/encryption-customer-provided-keys.md).

+By default, a storage account is encrypted with a key that is scoped to the entire storage account. Encryption scopes enable you to manage encryption with a key that is scoped to a container or an individual blob. You can use encryption scopes to create secure boundaries between data that resides in the same storage account but belongs to different customers. Encryption scopes can use either Microsoft-managed keys or customer-managed keys. For more information about encryption scopes, see [Encryption scopes for Blob storage](../blobs/encryption-scope-overview.md).

+| Azure Storage services supported | All | Blob Storage, Azure Files^1,2 | Blob Storage |

+| Key scope | Account (default), container, or blob | Account (default), container, or blob | N/A |

+## Client-side encryption for blobs and queues

+The Azure Blob Storage client libraries for .NET, Java, and Python support encrypting data within client applications before uploading to Azure Storage, and decrypting data while downloading to the client. The Queue Storage client libraries for .NET and Python also support client-side encryption.

+> [!NOTE]

+> Consider using the service-side encryption features provided by Azure Storage to protect your data, instead of client-side encryption.

+The Blob Storage and Queue Storage client libraries uses [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) in order to encrypt user data. There are two versions of client-side encryption available in the client libraries:

+- Version 2.x uses [Galois/Counter Mode (GCM)](https://en.wikipedia.org/wiki/Galois/Counter_Mode) mode with AES.

+- Version 1.x uses [Cipher Block Chaining (CBC)](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher-block_chaining_.28CBC.29) mode with AES.

+> Using version 1.x of client-side encryption is no longer recommended due to a security vulnerability in the client library's implementation of CBC mode. For more information about this security vulnerability, see [Azure Storage updating client-side encryption in SDK to address security vulnerability](https://aka.ms/azstorageclientencryptionblog). If you are currently using version 1.x, we recommend that you update your application to use version 2.x and migrate your data.

+The following table shows which client libraries support which versions of client-side encryption and provides guidelines for migrating to client-side encryption v2.

+| Client library | Version of client-side encryption supported | Recommended migration | Additional guidance |

+|--|--|--|--|

+| Blob Storage client libraries for .NET, Java, and Python, version 12.x and above | 2.0<br/><br/>1.0 (for backward compatibility only) | Update your code to use client-side encryption v2.<br/><br/>Download any encrypted data to decrypt it, then reencrypt it with client-side encryption v2. | [Client-side encryption for blobs](../blobs/client-side-encryption.md) |

+| Blob Storage client library for .NET, Java, and Python, version 11.x and below | 1.0 (not recommended) | Update your application to use Blob Storage SDK version 12.x or later.<br/><br/>Update your code to use client-side encryption v2.<br/><br/>Download any encrypted data to decrypt it, then reencrypt it with client-side encryption v2. | [Client-side encryption for blobs](../blobs/client-side-encryption.md) |

+| Queue Storage client library for .NET and Python, version 12.x and above | 2.0<br/><br/>1.0 (for backward compatibility only) | Update your code to use client-side encryption v2. | [Client-side encryption for queues](../queues/client-side-encryption.md) |

+| Queue Storage client library for .NET and Python, version 11.x and below | 1.0 (not recommended) | Update your application to use Blob Storage SDK version 12.x or later.<br/><br/>Update your code to use client-side encryption v2. | [Client-side encryption for queues](../queues/client-side-encryption.md) |

+| Table Storage client library for .NET, Java, and Python | 1.0 (not recommended) | Not available. | N/A |

+- [Encryption scopes for Blob Storage](../blobs/encryption-scope-overview.md)

+- [Provide an encryption key on a request to Blob Storage](../blobs/encryption-customer-provided-keys.md)

+* <a id="ad-sid-to-upn"></a>

+**Is it possible to view the userPrincipalName (UPN) of a file/directory owner in Windows Explorer instead of the security identifier (SID)?**

+ In Windows Explorer, the SID of a file/directory owner is displayed instead of the UPN for files and directories hosted on Azure Files. However, you can use the following PowerShell command to view all items in a directory and their owner, including UPN:

+ ```PowerShell

+ Get-ChildItem <Path> | Get-ACL | Select Path, Owner

+ ```

+ Title: Client-side encryption for queues

+description: The Queue Storage client library supports client-side encryption and integration with Azure Key Vault for users requiring encryption on the client.

+# Client-side encryption for queues

+The Azure Queue Storage client libraries for .NET and Python support encrypting data within client applications before uploading to Azure Storage, and decrypting data while downloading to the client. The client libraries also support integration with [Azure Key Vault](https://azure.microsoft.com/services/key-vault/) for storage account key management.

+> [!IMPORTANT]

+> Azure Storage supports both service-side and client-side encryption. For most scenarios, Microsoft recommends using service-side encryption features for ease of use in protecting your data. To learn more about service-side encryption, see [Azure Storage encryption for data at rest](../common/storage-service-encryption.md).

+## About client-side encryption

+The Azure Queue Storage client library uses [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) in order to encrypt user data. There are two versions of client-side encryption available in the client library:

+- Version 2.x uses [Galois/Counter Mode (GCM)](https://en.wikipedia.org/wiki/Galois/Counter_Mode) mode with AES.

+- Version 1.x uses [Cipher Block Chaining (CBC)](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher-block_chaining_.28CBC.29) mode with AES.

+> [!WARNING]

+> Using version 1.x of client-side encryption is no longer recommended due to a security vulnerability in the client library's implementation of CBC mode. For more information about this security vulnerability, see [Azure Storage updating client-side encryption in SDK to address security vulnerability](https://aka.ms/azstorageclientencryptionblog). If you are currently using version 1.x, we recommend that you update your application to use version 2.x and migrate your data. See the following section, [Mitigate the security vulnerability in your applications](#mitigate-the-security-vulnerability-in-your-applications), for further guidance.

+## Mitigate the security vulnerability in your applications

+Due to a security vulnerability discovered in the Queue Storage client library's implementation of CBC mode, Microsoft recommends that you take one or more of the following actions immediately:

+- Consider using service-side encryption features instead of client-side encryption. For more information about service-side encryption features, see [Azure Storage encryption for data at rest](../common/storage-service-encryption.md).

+- If you need to use client-side encryption, then migrate your applications from client-side encryption v1 to client-side encryption v2.

+ Client-side encryption v2 is available only in version 12.x and later of the Azure Queue Storage client libraries for .NET and Python. If your application is using an earlier version of the client library, you must first upgrade your code to version 12.x or later, and then decrypt and re-encrypt your data with client-side encryption v2. If necessary, you can use version 12.x side-by-side with an earlier version of the client library while you are migrating your code.

+The following table summarizes the steps you'll need to take if you choose to migrate your applications to client-side encryption v2:

+| Client-side encryption status | Recommended actions |

+|||

+| Application is using client-side encryption with Azure Queue Storage SDK version 11.x or earlier | Update your application to use Queue Storage SDK version 12.x or later. If necessary, you can use version 12.x side-by-side with an earlier version of the client library while you are migrating your code.<br/><br/>Update your code to use client-side encryption v2. |

+| Application is using client-side encryption with Azure Queue Storage SDK version 12.x or later | Update your code to use client-side encryption v2. |

+Additionally, Microsoft recommends that you take the following steps to help secure your data:

+- Configure your storage accounts to use private endpoints to secure all traffic between your virtual network (VNet) and your storage account over a private link. For more information, see [Use private endpoints for Azure Storage](../common/storage-private-endpoints.md).

+- Limit network access to specific networks only.

+## How client-side encryption works

+The Azure Queue Storage client libraries use envelope encryption to encrypt and decrypt your data on the client side. Envelope encryption encrypts a key with one or more additional keys.

+The Queue Storage client libraries rely on Azure Key Vault to protect the keys that are used for client-side encryption. For more information about Azure Key Vault, see [What is Azure Key Vault?](../../key-vault/general/overview.md).

+### Encryption and decryption via the envelope technique

+Encryption via the envelope technique works as follows:

+1. The Azure Storage client library generates a content encryption key (CEK), which is a one-time-use symmetric key.

+1. User data is encrypted using the CEK.

+1. The CEK is then wrapped (encrypted) using the key encryption key (KEK). The KEK is identified by a key identifier and can be either an asymmetric key pair or a symmetric key. You can manage the KEK locally or store it in an Azure Key Vault.

+ The Azure Storage client library itself never has access to KEK. The library invokes the key wrapping algorithm that is provided by Key Vault. Users can choose to use custom providers for key wrapping/unwrapping if desired.

+1. The encrypted data is then uploaded to Azure Queue Storage. The wrapped key together with some additional encryption metadata is interpolated with the encrypted data.

+Decryption via the envelope technique works as follows:

+1. The Azure Storage client library assumes that the user is managing the KEK either locally or in an Azure Key Vault. The user doesn't need to know the specific key that was used for encryption. Instead, a key resolver that resolves different key identifiers to keys can be set up and used.

+1. The client library downloads the encrypted data along with any encryption material that is stored in Azure Storage.

+1. The wrapped CEK) is then unwrapped (decrypted) using the KEK. The client library doesn't have access to the KEK during this process, but only invokes the unwrapping algorithm of the Azure Key Vault or other key store.

+1. The client library uses the CEK to decrypt the encrypted user data.

+### Message encryption/decryption

+Since queue messages can be of any format, the client library defines a custom format that includes the Initialization Vector (IV) and the encrypted content encryption key (CEK) in the message text.

+During encryption, the client library generates a random IV of 16 bytes along with a random CEK of 32 bytes and performs envelope encryption of the queue message text using this information. The wrapped CEK and some additional encryption metadata are then added to the encrypted queue message. This modified message (shown below) is stored on the service.

+```xml

+<MessageText>{"EncryptedMessageContents":"6kOu8Rq1C3+M1QO4alKLmWthWXSmHV3mEfxBAgP9QGTU++MKn2uPq3t2UjF1DO6w","EncryptionData":{…}}</MessageText>

+```

+During decryption, the wrapped key is extracted from the queue message and unwrapped. The IV is also extracted from the queue message and used along with the unwrapped key to decrypt the queue message data. Encryption metadata is small (under 500 bytes), so while it does count toward the 64KB limit for a queue message, the impact should be manageable. The encrypted message is Base64-encoded, as shown in the above snippet, which will also expand the size of the message being sent.

+Due to the short-lived nature of messages in the queue, decrypting and reencrypting queue messages after updating to client-side encryption v2 should not be necessary. Any less secure messages will be rotated in the course of normal queue consumption.

+## Client-side encryption and performance

+Keep in mind that encrypting your storage data results in additional performance overhead. When you use client-side encryption in your application, the client library must securely generate the CEK and IV, encrypt the content itself, communicate with your chosen keystore for key-enveloping, and format and upload additional metadata. This overhead varies depending on the quantity of data being encrypted. We recommend that customers always test their applications for performance during development.

+## Next steps

+- [Azure Storage updating client-side encryption in SDK to address security vulnerability](https://aka.ms/azstorageclientencryptionblog)

+- [Azure Storage encryption for data at rest](../common/storage-service-encryption.md)

+- [Azure Key Vault documentation](../../key-vault/general/overview.md)

+> [!IMPORTANT]

+>

+> - There are three levels of package installing on Synapse Analytics -- default level, Spark pool level and session level.

+> - Apache Spark in Azure Synapse Analytics has a full Anaconda install plus extra libraries served as the default level installation which is fully managed by Synapse. The Spark pool level packages can be used by all running Artifacts, e.g., Notebook and Spark job definition attaching the corresponding Spark pool. The session level installation will create an environment for the specific Notebook session, the change of session level libraries will not be persisted between sessions.

+> - You can upload custom libraries and a specific version of an open-source library that you would like to use in your Azure Synapse Analytics Workspace. The workspace packages can be installed in your Spark pools.

+> - To be noted, the pool level library management can take certain amount of time depending on the size of packages and the complexity of required dependencies. The session level installation is suggested with experimental and quick iterative scenarios.

+Default packages include a full Anaconda install plus extra commonly used libraries. The full libraries list can be found at [Apache Spark version support](apache-spark-version-support.md).

+In Synapse, workspace packages can be custom or private *.whl* or *.jar* files. You can upload these packages to your workspace and later assign them to a specific serverless Apache Spark pool. Once assigned, these workspace packages are installed automatically on all Spark pool sessions.

+To learn more about how to manage workspace libraries, see the following article:

+- [Manage workspace packages](./apache-spark-manage-workspace-packages.md)

+To learn more about these capabilities, see [Manage Spark pool packages](./apache-spark-manage-pool-packages.md).

+- [Python session packages: ](./apache-spark-manage-session-packages.md#session-scoped-python-packages) At the start of a session, provide a Conda *environment.yml* to install more Python packages from popular repositories.

+- [Scal#session-scoped-java-or-scala-packages) At the start of your session, provide a list of *.jar* files to install using `%%configure`.

+## Manage your packages outside Synapse Analytics UI

+If your team want to manage the libraries without visiting the package management UIs, you have the options to manage the workspace packages and pool level package updates through Azure PowerShell cmdlets or REST APIs for Synapse Analytics.

+To learn more about Azure PowerShell cmdlets and package management REST APIs, see the following articles:

+- Azure PowerShell cmdlets for Synapse Analytics: [Manage your Spark pool libraries through Azure PowerShell cmdlets](apache-spark-manage-packages-outside-ui.md#manage-packages-through-azure-powershell-cmdlets)

+- Package management REST APIs: [Manage your Spark pool libraries through REST APIs](apache-spark-manage-packages-outside-ui.md#manage-packages-through-rest-apis)

+## Next steps

+- Troubleshoot library installation errors: [Troubleshoot library errors](apache-spark-troubleshoot-library-errors.md)

+Now that you've verified your custom channel, you can use the [Python pool management](./apache-spark-manage-pool-packages.md#manage-packages-from-synapse-studio-or-azure-portal) process to update the libraries on your Apache Spark pool.

+- Manage Session level Python packages: [Python package management on Notebook Session](./apache-spark-manage-session-packages.md#session-scoped-python-packages)

+ Title: Manage packages outside Synapse Analytics Studio UIs

+description: Learn how to manage packages using Azure PowerShell cmdlets or REST APIs

+# Manage packages outside Synapse Analytics Studio UIs

+You may want to manage your libraries for your serverless Apache Spark pools without going into the Synapse Analytics UI pages. For example, you may find that:

+- you develop a custom package and want to upload it to your workspace and use it in your Spark pool. And you want to finish the steps on your local tools without visiting the package management UIs.

+- you are updating your packages through the CI/CD process

+In this article, we'll provide a general guide to help you managing libraries through Azure PowerShell cmdlets or REST APIs.

+## Manage packages through Azure PowerShell cmdlets

+### Add new libraries

+1. [New-AzSynapseWorkspacePackage](https://docs.microsoft.com/powershell/module/az.synapse/new-azsynapseworkspacepackage) command can be used to **upload new libraries to workspace**.

+ ```powershell

+ New-AzSynapseWorkspacePackage -WorkspaceName ContosoWorkspace -Package ".\ContosoPackage.whl"

+ ```

+2. The combination of [New-AzSynapseWorkspacePackage](https://docs.microsoft.com/powershell/module/az.synapse/new-azsynapseworkspacepackage) and [Update-AzSynapseSparkPool](https://docs.microsoft.com/powershell/module/az.synapse/update-azsynapsesparkpool) commands can be used to **upload new libraries to workspace** and **attach the library to a Spark pool**.

+ ```powershell

+ $package = New-AzSynapseWorkspacePackage -WorkspaceName ContosoWorkspace -Package ".\ContosoPackage.whl"

+ Update-AzSynapseSparkPool -WorkspaceName ContosoWorkspace -Name ContosoSparkPool -PackageAction Add -Package $package

+ ```

+3. If you want to attach an **existing workspace library** to your Spark pool, please refer to the command combination of [Get-AzSynapseWorkspacePackage](https://docs.microsoft.com/powershell/module/az.synapse/get-azsynapseworkspacepackage) and [Update-AzSynapseSparkPool](https://docs.microsoft.com/powershell/module/az.synapse/update-azsynapsesparkpool).

+ ```powershell

+ $packages = Get-AzSynapseWorkspacePackage -WorkspaceName ContosoWorkspace

+ Update-AzSynapseSparkPool -WorkspaceName ContosoWorkspace -Name ContosoSparkPool -PackageAction Add -Package $packages

+ ```

+### Remove libraries

+1. In order to **remove a installed package** from your Spark pool, please refer to the command combination of [Get-AzSynapseWorkspacePackage](https://docs.microsoft.com/powershell/module/az.synapse/get-azsynapseworkspacepackage) and [Update-AzSynapseSparkPool](https://docs.microsoft.com/powershell/module/az.synapse/update-azsynapsesparkpool).

+ ```powershell

+ $package = Get-AzSynapseWorkspacePackage -WorkspaceName ContosoWorkspace -Name ContosoPackage

+ Update-AzSynapseSparkPool -WorkspaceName ContosoWorkspace -Name ContosoSparkPool -PackageAction Remove -Package $package

+ ```

+2. You can also retrieve a Spark pool and **remove all attached workspace libraries** from the pool by calling [Get-AzSynapseSparkPool](https://docs.microsoft.com/powershell/module/az.synapse/get-azsynapsesparkpool) and [Update-AzSynapseSparkPool](https://docs.microsoft.com/powershell/module/az.synapse/update-azsynapsesparkpool) commands.

+ ```powershell

+ $pool = Get-AzSynapseSparkPool -ResourceGroupName ContosoResourceGroup -WorkspaceName ContosoWorkspace -Name ContosoSparkPool

+ $pool | Update-AzSynapseSparkPool -PackageAction Remove -Package $pool.WorkspacePackages

+ ```

+For more Azure PowerShell cmdlets capabilities, please refer to [Azure PowerShell cmdlets for Azure Synapse Analytics](https://docs.microsoft.com/powershell/module/az.synapse).

+## Manage packages through REST APIs

+### Manage the workspace packages

+With the ability of REST APIs, you can add/delete packages or list all uploaded files of your workspace. See the full supported APIs, please refer to [Overview of workspace library APIs](https://docs.microsoft.com/rest/api/synapse/data-plane/library).

+### Manage the Spark pool packages

+You can leverage the [Spark pool REST API](https://docs.microsoft.com/rest/api/synapse/big-data-pools/create-or-update) to attach or remove your custom or open source libraries to your Spark pools.

+1. For custom libraries, please specify the list of custom files as the **customLibraries** property in request body.

+ ```json

+ "customLibraries": [

+ {

+ "name": "samplejartestfile.jar",

+ "path": "<workspace-name>/libraries/<jar-name>.jar",

+ "containerName": "prep",

+ "uploadedTimestamp": "1970-01-01T00:00:00Z",

+ "type": "jar"

+ }

+ ]

+ ```

+2. You can also update your Spark pool libraries by specifying the **libraryRequirements** property in request body.

+ ```json

+ "libraryRequirements": {

+ "content": "",

+ "filename": "requirements.txt"

+ }

+ ```

+## Next steps

+- View the default libraries: [Apache Spark version support](apache-spark-version-support.md)

+- Manage Spark pool level packages through Synapse Studio portal: [Python package management on Notebook Session](./apache-spark-manage-session-packages.md#session-scoped-python-packages)

+ Title: Manage Spark pool level libraries for Apache Spark

+description: Learn how to add and manage libraries on Spark pool level in Azure Synapse Analytics.

+# Manage libraries for Apache Spark pools in Azure Synapse Analytics

+Once you have identified the Scala, Java or Python packages that you would like to use or update for your Spark application, you can install or remove them into a Spark pool. Pool-level libraries are available to all notebooks and jobs running on the pool.

+There are two primary ways to install a library on a Spark pool:

+- Install a workspace library that has been uploaded as a workspace package.

+- For updating Python libraries, provide a *requirements.txt* or *Conda environment.yml* environment specification to install packages from repositories like PyPI, Conda-Forge, and more. Read the section about [environment specification](#environment-specification-formats) for further information.

+After the changes are saved, a Spark job will run the installation and cache the resulting environment for later reuse. Once the job is complete, new Spark jobs or notebook sessions will use the updated pool libraries.

+> [!IMPORTANT]

+> - If the package you are installing is large or takes a long time to install, this affects the Spark instance start up time.

+> - Altering the PySpark, Python, Scala/Java, .NET, or Spark version is not supported.

+> - Installing packages from external repositories like PyPI, Conda-Forge, or the default Conda channels is not supported within data exfiltration protection enabled workspaces.

+## Manage packages from Synapse Studio or Azure portal

+Spark pool libraries can be managed either from the Synapse Studio or Azure portal.

+To update or add libraries to a Spark pool:

+1. Navigate to your Azure Synapse Analytics workspace from the Azure portal.

+ If you are updating from the **Azure portal**:

+ - Under the **Synapse resources** section, select the **Apache Spark pools** tab and select a Spark pool from the list.

+

+ - Select the **Packages** from the **Settings** section of the Spark pool.

+ :::image type="content" source="./media/apache-spark-azure-portal-add-libraries/apache-spark-add-library-azure.png" alt-text="Screenshot that highlights the upload environment configuration file button." lightbox="./media/apache-spark-azure-portal-add-libraries/apache-spark-add-library-azure.png":::

+

+ If you are updating from the **Synapse Studio**:

+ - Select **Manage** from the main navigation panel and then select **Apache Spark pools**.

+ - Select the **Packages** section for a specific Spark pool.

+ :::image type="content" source="./media/apache-spark-azure-portal-add-libraries/studio-update-libraries.png" alt-text="Screenshot that highlights the logs of library installation." lightbox="./media/apache-spark-azure-portal-add-libraries/studio-update-libraries.png":::

+

+2. For Python feed libraries, upload the environment configuration file using the file selector in the **Packages** section of the page.

+3. You can also select additional **workspace packages** to add Jar or Wheel files to your pool.

+4. You can also remove the deprecated packages from **Workspace packages** section, your pool will no longer attach these packages.

+5. Once you save your changes, a system job will be triggered to install and cache the specified libraries. This process helps reduce overall session startup time.

+6. Once the job has successfully completed, all new sessions will pick up the updated pool libraries.

+> [!IMPORTANT]

+> By selecting the option to **Force new settings**, you will end the all current sessions for the selected Spark pool. Once the sessions are ended, you will have to wait for the pool to restart.

+>

+> If this setting is unchecked, then you will have to wait for the current Spark session to end or stop it manually. Once the session has ended, you will need to let the pool restart.

+## Track installation progress

+A system reserved Spark job is initiated each time a pool is updated with a new set of libraries. This Spark job helps monitor the status of the library installation. If the installation fails due to library conflicts or other issues, the Spark pool will revert to its previous or default state.

+In addition, users can also inspect the installation logs to identify dependency conflicts or see which libraries were installed during the pool update.

+To view these logs:

+1. Navigate to the Spark applications list in the **Monitor** tab.

+2. Select the system Spark application job that corresponds to your pool update. These system jobs run under the *SystemReservedJob-LibraryManagement* title.

+ :::image type="content" source="./media/apache-spark-azure-portal-add-libraries/system-reserved-library-job.png" alt-text="Screenshot that highlights system reserved library job." lightbox="./media/apache-spark-azure-portal-add-libraries/system-reserved-library-job.png":::

+3. Switch to view the **driver** and **stdout** logs.

+4. Within the results, you will see the logs related to the installation of your dependencies.

+ :::image type="content" source="./media/apache-spark-azure-portal-add-libraries/system-reserved-library-job-results.png" alt-text="Screenshot that highlights system reserved library job results." lightbox="./media/apache-spark-azure-portal-add-libraries/system-reserved-library-job-results.png":::

+## Environment specification formats

+### PIP requirements.txt

+A *requirements.txt* file (output from the `pip freeze` command) can be used to upgrade the environment. When a pool is updated, the packages listed in this file are downloaded from PyPI. The full dependencies are then cached and saved for later reuse of the pool.

+The following snippet shows the format for the requirements file. The PyPI package name is listed along with an exact version. This file follows the format described in the [pip freeze](https://pip.pypa.io/en/stable/cli/pip_freeze/) reference documentation.

+This example pins a specific version.

+```

+absl-py==0.7.0

+adal==1.2.1

+alabaster==0.7.10

+```

+#### YML format

+In addition, you can also provide an *environment.yml* file to update the pool environment. The packages listed in this file are downloaded from the default Conda channels, Conda-Forge, and PyPI. You can specify other channels or remove the default channels by using the configuration options.

+This example specifies the channels and Conda/PyPI dependencies.

+```

+name: stats2

+channels:

+- defaults

+dependencies:

+- bokeh

+- numpy

+- pip:

+ - matplotlib

+ - koalas==1.7.0

+```

+For details on creating an environment from this environment.yml file, see [Creating an environment from an environment.yml file](https://conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html#activating-an-environment

+).

+## Next steps

+- View the default libraries: [Apache Spark version support](apache-spark-version-support.md)

+- Troubleshoot library installation errors: [Troubleshoot library errors](apache-spark-troubleshoot-library-errors.md)

+ Title: Manage session level libraries for Apache Spark

+description: Learn how to add and manage libraries on Spark Notebook sessions for Azure Synapse Analytics.

+# Manage session-scoped packages

+In addition to pool level packages, you can also specify session-scoped libraries at the beginning of a notebook session. Session-scoped libraries let you specify and use custom Python environments or jar packages within a notebook session.

+When using session-scoped libraries, it is important to keep the following points in mind:

+ - When you install session-scoped libraries, only the current notebook has access to the specified libraries.

+ - These libraries will not impact other sessions or jobs using the same Spark pool.

+ - These libraries are installed on top of the base runtime and pool level libraries.

+ - Notebook libraries will take the highest precedence.

+## Session-scoped Python packages

+To specify session-scoped Python packages:

+1. Navigate to the selected Spark pool and ensure that you have enabled session-level libraries. You can enable this setting by navigating to the **Manage** > **Apache Spark pool** > **Packages** tab.

+ :::image type="content" source="./media/apache-spark-azure-portal-add-libraries/enable-session-packages.png" alt-text="Screenshot of enabling session packages." lightbox="./media/apache-spark-azure-portal-add-libraries/enable-session-packages.png":::

+2. Once the setting has been applied, you can open a notebook and select **Configure Session**> **Packages**.

+ 

+ 

+3. Here, you can upload a Conda *environment.yml* file to install or upgrade packages within a session. Once you start your session, the specified libraries will be installed. Once your session ends, these libraries will no longer be available as they are specific to your session.

+### Verify installed libraries

+To verify if the correct versions of the correct libraries are installed from PyPI, run the following code:

+```python

+import pkg_resources

+for d in pkg_resources.working_set:

+ print(d)

+```

+In some cases, to view the package versions from Conda, you may need to inspect the package version individually.

+## Session-scoped Java or Scala packages

+To specify session-scoped Java or Scala packages, you can use the ```%%configure``` option:

+```scala

+%%configure -f

+{

+ "conf": {

+ "spark.jars": "abfss://<<file system>>@<<storage account>.dfs.core.windows.net/<<path to JAR file>>",

+ }

+}

+```

+We recommend you to run the %%configure at the beginning of your notebook. You can refer to this [document](https://github.com/cloudera/livy#request-body) for the full list of valid parameters.

+## Next steps

+- View the default libraries: [Apache Spark version support](apache-spark-version-support.md)

+- Manage the packages outside Synapse Studio portal: [Manage packages through Az commands and REST APIs](apache-spark-manage-packages-outside-ui.md)

+ Title: Manage workspace libraries for Apache Spark

+description: Learn how to add and manage libraries to workspace in Azure Synapse Analytics.

+# Workspace packages

+Workspace packages can be custom or private wheel or jar files. You can upload these packages to your workspace and later assign them to a specific Spark pool.

+To add workspace packages:

+1. Navigate to the **Manage** > **Workspace packages** tab.

+2. Upload your wheel files by using the file selector.

+3. Once the files have been uploaded to the Azure Synapse workspace, you can add these packages to a given Apache Spark pool.

+ :::image type="content" source="./media/apache-spark-azure-portal-add-libraries/studio-add-workspace-package.png" alt-text="Screenshot that highlights workspace packages." lightbox="./media/apache-spark-azure-portal-add-libraries/studio-add-workspace-package.png":::

+>[!WARNING]

+>- Within Azure Synapse, an Apache Spark pool can leverage custom libraries that are either uploaded as Workspace Packages or uploaded within a well-known Azure Data Lake Storage path. However, both of these options cannot be used simultaneously within the same Apache Spark pool. If packages are provided using both methods, only the wheel files specified in the Workspace packages list will be installed.

+>

+>- Once Workspace Packages are used to install packages on a given Apache Spark pool, there is a limitation that you can no longer specify packages using the Storage account path on the same pool.

+## Storage account

+Custom-built wheel packages can be installed on the Apache Spark pool by uploading all the wheel files into the Azure Data Lake Storage (Gen2) account that is linked with the Synapse workspace.

+The files should be uploaded to the following path in the storage account's default container:

+```

+abfss://<file_system>@<account_name>.dfs.core.windows.net/synapse/workspaces/<workspace_name>/sparkpools/<pool_name>/libraries/python/

+```

+>[!WARNING]

+> - In some cases, you may need to create the file path based on the structure above if it does not already exist. For example, you may need to add the ```python``` folder within the ```libraries``` folder if it does not already exist.

+> - This method of managing custom wheel files will not be supported on the Azure Synapse Runtime for Apache Spark 3.0. Please refer to the Workspace packages feature to manage custom wheel files.

+> [!IMPORTANT]

+> To install custom libraries using the Azure DataLake Storage method, you must have the **Storage Blob Data Contributor** or **Storage Blob Data Owner** permissions on the primary Gen2 Storage account that is linked to the Azure Synapse Analytics workspace.

+## Next steps

+- View the default libraries: [Apache Spark version support](apache-spark-version-support.md)

+- Troubleshoot library installation errors: [Troubleshoot library errors](apache-spark-troubleshoot-library-errors.md)

+- Create a private Conda channel using your Azure Data Lake Storage Account: [Conda private channels](./spark/../apache-spark-custom-conda-channel.md)

+An environment configuration file can be used to upgrade the Conda environment. This acceptable file formats for Python pool management are listed as [Environment Specifications](./apache-spark-manage-pool-packages.md#environment-specification-formats).

+- Generalize the VM by running [sysprep](../virtual-machines/generalize.md)

+ Title: Azure Hybrid Benefit for Linux virtual machine scale sets

+> [!NOTE]

+> This article focuses on virtual machine scale sets running in Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for virtual machine scale sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).

+**Azure Hybrid Benefit for Linux virtual machine scale set is generally available now**. *Azure Hybrid Benefit (AHB)* can reduce the cost of running your *Red Hat Enterprise Linux (RHEL)* and *SUSE Linux Enterprise Server (SLES)* [virtual machine scale sets](./overview.md). AHB is available for all RHEL and SLES Marketplace pay-as-you-go (PAYG) images.

+A virtual machine scale set deployed from PAYG marketplace images is charged both infrastructure and software fees when AHB is enabled.

+### How to enable AHB for Red Hat virtual machine scale sets

+1. Apply AHB to any of your new or existing RHEL PAYG virtual machine scale sets. You can use Azure portal or Azure *command-line interface (CLI)* to enable AHB.

+### How to enable AHB for SUSE virtual machine scale sets

+### How to enable AHB during virtual machine scale set creation in Azure portal:

+1. Go to 'Create a virtual machine scale set' page on the portal.

+ :::image type="content" source="./media/azure-hybrid-benefit-linux/create-vmss-ahb.png" alt-text="Screenshot of the virtual machine scale set blade in the Azure portal.":::

+ :::image type="content" source="./media/azure-hybrid-benefit-linux/create-vmss-ahb-checkbox.png" alt-text="Screenshot of the check box associated with hybrid benefit during the virtual machine scale set create phase in the Azure portal.":::

+1. Create a virtual machine scale set following the next set of instructions

+ :::image type="content" source="./media/azure-hybrid-benefit-linux/create-vmss-ahb-os-blade.png" alt-text="Screenshot of the virtual machine scale set create page in the Azure portal after the use select the hybrid benefit check box.":::

+1. Open the 'virtual machine scale set' page on which you want to apply the conversion.

+# This will enable AHB on a RHEL virtual machine scale set

+# This will enable AHB on a SLES virtual machine scale set

+> Scale sets have an ["upgrade policy"](./virtual-machine-scale-sets-upgrade-scale-set.md#how-to-bring-vms-up-to-date-with-the-latest-scale-set-model) that determine how Virtual Machine's are brought up-to-date with the latest scale set model.

+Hence, if your virtual machine scale set have 'Automatic' upgrade policy, AHB will be applied automatically as Virtual Machine instances get updated.

+If virtual machine scale set have 'Rolling' upgrade policy, based on the scheduled updates, AHB will be applied.

+# This will bring virtual machine scale set instances up to date with latest virtual machine scale set model

+## How to apply AHB at virtual machine scale set creation time

+### How to apply AHB at virtual machine scale set creation time using a CLI

+# This will enable AHB while creating RHEL virtual machine scale set

+# This will enable AHB while creating RHEL virtual machine scale set

+* [Learn how to create and update Virtual Machines and add license types (RHEL_BYOS, SLES_BYOS) for AHB by using the Azure CLI](/cli/azure/vmss)

+Now create a virtual machine scale set with [az vmss create](/cli/azure/vmss). The following example creates a scale set named *myScaleSet* that is set to automatically update as changes are applied, and generates SSH keys if they don't exist in *~/.ssh/id_rsa*. A 32-Gb data disk is attached to each VM instance, and the Azure [Custom Script Extension](../virtual-machines/extensions/custom-script-linux.md) is used to prepare the data disks with [az vmss extension set](/cli/azure/vmss/extension):

+ Title: Create virtual machines in a Flexible scale set using Azure CLI

+description: Learn how to create a virtual machine scale set in Flexible orchestration mode using Azure CLI.

+# Create virtual machines in a scale set using Azure CLI

+This article steps through using the Azure CLI to create a virtual machine scale set.

+Make sure that you've installed the latest [Azure CLI](/cli/azure/install-az-cli2) and are logged in to an Azure account with [az login](/cli/azure/reference-index).

+## Launch Azure Cloud Shell

+The Azure Cloud Shell is a free interactive shell that you can use to run the steps in this article. It has common Azure tools preinstalled and configured to use with your account.

+To open the Cloud Shell, just select **Try it** from the upper right corner of a code block. You can also launch Cloud Shell in a separate browser tab by going to [https://shell.azure.com/cli](https://shell.azure.com/cli). Select **Copy** to copy the blocks of code, paste it into the Cloud Shell, and press enter to run it.

+## Create a resource group

+Create a resource group with [az group create](/cli/azure/group) as follows:

+```azurecli-interactive

+az group create --name myResourceGroup --location eastus

+```

+## Create a virtual machine scale set

+Now create a virtual machine scale set with [az vmss create](/cli/azure/vmss). The following example creates a scale set with an instance count of *2*, and generates SSH keys.

+```azurecli-interactive

+az vmss create \

+ --resource-group myResourceGroup \

+ --name myScaleSet \

+ --orchestration-mode Flexible \

+ --image UbuntuLTS \

+ --upgrade-policy-mode automatic \

+ --instance-count 2 \

+ --admin-username azureuser \

+ --generate-ssh-keys

+```

+## Clean up resources

+To remove your scale set and additional resources, delete the resource group and all its resources with [az group delete](/cli/azure/group). The `--no-wait` parameter returns control to the prompt without waiting for the operation to complete. The `--yes` parameter confirms that you wish to delete the resources without an additional prompt to do so.

+```azurecli-interactive

+az group delete --name myResourceGroup --yes --no-wait

+```

+## Next steps

+> [!div class="nextstepaction"]

+> [Learn how to create a scale set in the Azure Portal.](flexible-virtual-machine-scale-sets-portal.md)

+ Title: Migrate deployments and resources to virtual machine scale sets in Flexible orchestration

+description: Learn how to migrate deployments and resources to virtual machine scale sets in Flexible orchestration.

+# Migrate deployments and resources to virtual machine scale sets in Flexible orchestration

+Like availability sets, virtual machine scale sets allows you to spread virtual machines across multiple fault domains. Virtual machine scale sets with Flexible orchestration allows you to combine the scalability of [virtual machine scale sets in Uniform orchestration mode](../virtual-machine-scale-sets/overview.md) with the regional availability guarantees of [availability sets](../virtual-machines/availability-set-overview.md). This article goes over migration considerations when switching to Flexible orchestration mode for virtual machine scale sets.

+## Update availability set deployments templates and scripts

+First, you need to create a virtual machine scale set with no auto scaling profile via [Azure CLI](flexible-virtual-machine-scale-sets-cli.md), [Azure PowerShell](flexible-virtual-machine-scale-sets-powershell.md), or [ARM Template](flexible-virtual-machine-scale-sets-rest-api.md). Azure portal only allows creating a virtual machine scale set with an autoscaling profile. If you do not want or need an autoscaling profile and you want to create a scale set using [Azure portal](flexible-virtual-machine-scale-sets-portal.md), you can set the initial capacity to 0.

+

+You must specify the fault domain count for the virtual machine scale set. For regional (non-zonal) deployments, virtual machine scale sets offers the same fault domain guarantees as availability sets. However, you can scale up to 1000 instances. For zonal deployments where you are spreading instances across multiple availability zones, the fault domain count must be set to 1.

+Update domains have been deprecated in Flexible Orchestration mode. Most platform updates with general purpose SKUs are performed with Live Migration and do not require instance reboot. On the occasion that a platform maintenance requires instances to be rebooted, updates are applied fault domain by fault domain.

+

+Flexible orchestration for virtual machine scale sets also supports deploying instances across multiple availability zones. You may want to consider updating your VM deployments to spread across multiple availability zones.

+The last step in this process is to create a virtual machine. Instead of specifying an availability set, specify the virtual machine scale set. Optionally, you can specify the availability zone or fault domain in which you wish to place the VM.

+## Migrate existing availability set VMs

+There is currently no automated tooling to directly move existing instances in an Availability Set to a virtual machine scale set. However, there are several strategies you can utilize to migrate existing instances to a Flexible scale set:

+### Blue/green or side by side migration

+1. Bring up new scale set virtual machine instances with similar configuration into the same resource group, virtual network, load balancer, etc. as the VMs in the availability

+1. Migrate data, network traffic, etc. to use the new scale set instances

+1. Deallocate or remove the original Availability Set virtual machines, leaving the scale set VMs running for your application

+### Replace VM instances

+1. Note the parameters you want to keep from the virtual machine (name, NIC ID, OS and data disk IDs, VM configuration settings, fault domain placement, etc.)

+1. Delete the availability set virtual machine. The NICs and disks for the VM will not be deleted

+1. Create a new virtual machine object, using the parameters from the original VM

+ - NIC ID

+ - OS and Data disks

+ - Fault domain placement

+ - Other VM settings

+## Update Uniform scale sets deployment templates and scripts

+Update Uniform virtual machine scale sets deployment templates and scripts to use Flexible orchestration. Change the following elements in your templates to successfully complete the process.

+- Remove `LoadBalancerNATPool` (not valid for flex)

+- Remove overprovisioning parameter (not valid for flex)

+- Remove `upgradePolicy` (not valid for flex, yet)

+- Update compute API version to **2021-03-01**

+- Add orchestration mode `flexible`

+- `platformFaultDomainCount` required

+- `singlePlacementGroup`=false required

+- Add network API version to **2021-11-01** or higher

+- Set IP `configuration.properties.primary` to *true* (required for Outbound rules)

+## Migrate existing Uniform scale sets

+There is currently no automated tooling to directly move existing instances or upgrade a Uniform scale set to a Flexible virtual machine scale set. However, here is a strategy you can utilize to migrate existing instances to a Flexible scale set:

+### Blue/green or side by side migration

+1. Bring up new Flexible orchestration mode scale set with similar configuration into the same resource group, virtual network, load balancer, etc. as the original scale set in Uniform orchestration mode

+1. Migrate data, network traffic, etc. to use the new scale set instances

+1. Scale down or remove the original Uniform scale set virtual machines, leaving the scale set virtual machines running for your application

+## Flexible scale sets considerations

+Virtual machine scale sets with Flexible orchestration allows you to combine the scalability of [virtual machine scale sets in Uniform orchestration](../virtual-machine-scale-sets/overview.md) with the regional availability guarantees of availability sets. The following are key considerations when deciding to work with the Flexible orchestration mode.

+### Create scalable network connectivity

+<!-- the following is an important link to use in FLEX documentation to reference this section:

+/virtual-machines/flexible-virtual-machine-scale-sets-migration-resources.md#create-scalable-network-connectivity

+-->

+Networking outbound access behavior will vary depending on how you choose to create virtual machines within your scale set. **Manually added VM instances** have default outbound connectivity access. **Implicitly created VM instances** do not have default access.

+In order to enhance default network security, **virtual machine instances created implicitly via the autoscaling profile do not have default outbound access**. In order to use virtual machine scale sets with implicitly created VM instances, outbound access must be explicitly defined through one of the following methods:

+- For most scenarios, we recommend [NAT Gateway attached to the subnet](../virtual-network/nat-gateway/quickstart-create-nat-gateway-portal.md).

+- For scenarios with high security requirements or when using Azure Firewall or Network Virtual Appliance (NVA), you can specify a custom User Defined Route as next hop through firewall.

+- Instances are in the backend pool of a Standard SKU Azure Load Balancer.

+- Attach a Public IP Address to the instance network interface.

+Common scenarios that will require explicit outbound connectivity include:

+- Windows VM activation will require that you have defined outbound connectivity from the VM instance to the Windows Activation Key Management Service (KMS). See [Troubleshoot Windows VM activation problems](/troubleshoot/azure/virtual-machines/troubleshoot-activation-problems) for more information.

+- Access to storage accounts or Key Vault. Connectivity to Azure services can also be established via [Private Link](../private-link/private-link-overview.md).

+- Windows updates.

+- Access to Linux package managers.

+See [Default outbound access in Azure](../virtual-network/ip-services/default-outbound-access.md) for more details on defining outbound connectivity.

+With single instance VMs where you explicitly create the NIC, default outbound access is provided. Virtual machine scale sets in Uniform Orchestration mode also has default outbound connectivity.

+> [!IMPORTANT]

+> Confirm that you have explicit outbound network connectivity. Learn more about this in [virtual networks and virtual machines in Azure](../virtual-network/network-overview.md) and make sure you are following Azure's networking [best practices](../virtual-network/concepts-and-best-practices.md).

+### Assign fault domain during VM creation

+You can choose the number of fault domains for the Flexible orchestration scale set. By default, when you add a VM to a Flexible scale set, Azure evenly spreads instances across fault domains. While it is recommended to let Azure assign the fault domain, for advanced or troubleshooting scenarios you can override this default behavior and specify the fault domain where the instance will land.

+```azurecli-interactive

+az vm create ΓÇôvmss "myVMSS" ΓÇô-platform_fault_domain 1

+```

+### Instance naming

+When you create a VM and add it to a Flexible scale set, you have full control over instance names within the Azure Naming convention rules. When VMs are automatically added to the scale set via autoscaling, you provide a prefix and Azure appends a unique number to the end of the name.

+### List scale sets VM API changes

+Virtual Machine Scale Sets allows you to list the instances that belong to the scale set. With Flexible orchestration, the list Virtual Machine Scale Sets VM command provides a list of scale sets VM IDs. You can then call the GET Virtual Machine Scale Sets VM commands to get more details on how the scale set is working with the VM instance. To get the full details of the VM, use the standard GET VM commands or [Azure Resource Graph](../governance/resource-graph/overview.md).

+### Query instances for power state

+The preferred method is to use Azure Resource Graph to query for all VMs in a Virtual Machine Scale Set. Azure Resource Graph provides efficient query capabilities for Azure resources at scale across subscriptions.

+```

+| where type =~ 'Microsoft.Compute/virtualMachines'

+| where properties.virtualMachineScaleSet contains "demo"

+| extend powerState = properties.extended.instanceView.powerState.code

+| project name, resourceGroup, location, powerState

+| order by resourceGroup desc, name desc

+```

+Querying resources with [Azure Resource Graph](../governance/resource-graph/overview.md) is a convenient and efficient way to query Azure resources and minimizes API calls to the resource provider. Azure Resource Graph is an eventually consistent cache where new or updated resources may not be reflected for up to 60 seconds. You can:

+- List VMs in a resource group or subscription.

+- Use the expand option to retrieve the instance view (fault domain assignment, power and provisioning states) for all VMs in your subscription.

+- Use the Get VM API and commands to get model and instance view for a single instance.

+### Scale sets VM batch operations

+Use the standard VM commands to start, stop, restart, delete instances, instead of the Virtual Machine Scale Set VM APIs. The Virtual Machine Scale Set VM Batch operations (start all, stop all, reimage all, etc.) are not used with Flexible orchestration mode.

+### Monitor application health

+Application health monitoring allows your application to provide Azure with a heartbeat to determine whether your application is healthy or unhealthy. Azure can automatically replace VM instances that are unhealthy. For Flexible scale set instances, you must install and configure the Application Health Extension on the virtual machine. For Uniform scale set instances, you can use either the Application Health Extension, or measure health with an Azure Load Balancer Custom Health Probe.

+### Retrieve boot diagnostics data

+Use the standard VM APIs and commands to retrieve instance Boot Diagnostics data and screenshots. The Virtual Machine Scale Sets VM boot diagnostic APIs and commands are not used with Flexible orchestration mode instances.

+### VM extensions

+Use extensions targeted for standard virtual machines, instead of extensions targeted for Uniform orchestration mode instances.

+### Protect instances from delete

+Virtual machine scale sets in Flexible orchestration mode do not currently have instance protection options. If you have autoscale enabled on a virtual machine scale set, some VMs might be at risk of deletion during the scaling in process. If you want to protect certain VM instances from deletion, use [Azure Resource Manager lock](../azure-resource-manager/management/lock-resources.md).

+## Next steps

+> [!div class="nextstepaction"]

+> [Compare the API differences between Uniform and Flexible orchestration modes.](../virtual-machine-scale-sets/orchestration-modes-api-comparison.md)

+ Title: Create virtual machines in a Flexible scale set using Azure portal

+description: Learn how to create a virtual machine scale set in Flexible orchestration mode in the Azure portal.

+# Create virtual machines in a scale set using Azure portal

+This article steps through using Azure portal to create a virtual machine scale set.

+## Log in to Azure

+Log in to the Azure portal at https://portal.azure.com.

+## Create a virtual machine scale set

+You can deploy a scale set with a Windows Server image or Linux image such as RHEL, CentOS, Ubuntu, or SLES.

+1. In the Azure portal search bar, search for and select **Virtual machine scale sets**.

+1. Select **Create** on the **Virtual machine scale sets** page.

+1. In the **Basics** tab, under **Project details**, make sure the correct subscription is selected and create a new resource group called *myVMSSResourceGroup*.

+1. Under **Scale set details**, set *myScaleSet* for your scale set name and select a **Region** that is close to your area.

+1. Under **Orchestration**, select *Flexible*.

+1. Under **Instance details**, select a marketplace image for **Image**. In this example, we have chosen *Ubuntu Server 18.04 LTS*.

+1. Under **Administrator account** configure the admin username and set up an associated password or SSH public key.

+ - A **Password** must be at least 12 characters long and meet three out of the four following complexity requirements: one lower case character, one upper case character, one number, and one special character. For more information, see [username and password requirements](../virtual-machines/windows/faq.yml#what-are-the-password-requirements-when-creating-a-vm-).

+ - If you select a Linux OS disk image, you can instead choose **SSH public key**. You can use an existing key or create a new one. In this example, we will have Azure generate a new key pair for us. For more information on generating key pairs, see [create and use SSH keys](../virtual-machines/linux/mac-create-ssh-keys.md).

+1. Select **Next: Disks** to move the disk configuration options. For this quickstart, leave the default disk configurations.

+1. Select **Next: Networking** to move the networking configuration options.

+1. On the **Networking** page, under **Load balancing**, select the **Use a load balancer** checkbox to put the scale set instances behind a load balancer.

+1. In **Load balancing options**, select **Azure load balancer**.

+1. In **Select a load balancer**, select a load balancer or create a new one.

+1. For **Select a backend pool**, select **Create new**, type *myBackendPool*, then select **Create**.

+1. Select **Next: Scaling** to move to the scaling configurations.

+1. On the **Scaling** page, set the **initial instance count** field to *5*. You can set this number up to 1000.

+1. For the **Scaling policy**, keep it *Manual*.

+1. When you're done, select **Review + create**.

+1. After it passes validation, select **Create** to deploy the scale set.

+## Clean up resources

+When no longer needed, delete the resource group, scale set, and all related resources. To do so, select the resource group for the scale set and then select **Delete**.

+## Next steps

+> [!div class="nextstepaction"]

+> [Learn how to create a Flexible scale with Azure CLI.](flexible-virtual-machine-scale-sets-cli.md)

+ Title: Create virtual machines in a scale set using Azure PowerShell

+description: Learn how to create a virtual machine scale set in Flexible orchestration mode using PowerShell.

+# Create virtual machines in a scale set using PowerShell

+This article steps through using PowerShell to create a virtual machine scale set.

+## Launch Azure Cloud Shell

+The Azure Cloud Shell is a free interactive shell that you can use to run the steps in this article. It has common Azure tools preinstalled and configured to use with your account.

+To open the Cloud Shell, just select **Try it** from the upper right corner of a code block. You can also launch Cloud Shell in a separate browser tab by going to [https://shell.azure.com/powershell](https://shell.azure.com/powershell). Select **Copy** to copy the blocks of code, paste it into the Cloud Shell, and press enter to run it.

+## Create resource group

+Create an Azure resource group with [New-AzResourceGroup](/powershell/module/az.resources/new-azresourcegroup). A resource group is a logical container into which Azure resources are deployed and managed.

+```azurepowershell-interactive

+New-AzResourceGroup -Name 'myVMSSResourceGroup' -Location 'EastUS'

+```

+## Create a virtual machine scale set

+Now create a virtual machine scale set with [New-AzVmss](/powershell/module/azcompute/new-azvmss). The following example creates a scale set with an instance count of *2* running Windows Server 2019 Datacenter edition.

+```azurepowershell-interactive

+New-AzVmss `

+ -ResourceGroup "myVMSSResourceGroup" `

+ -Name "myScaleSet" `

+ -OrchestrationMode "Flexible" `

+ -Location "East US" `

+ -InstanceCount "2" `

+ -ImageName "Win2019Datacenter"

+```

+## Clean up resources

+When you delete a resource group, all resources contained within, such as the VM instances, virtual network, and disks, are also deleted. The `-Force` parameter confirms that you wish to delete the resources without an additional prompt to do so. The `-AsJob` parameter returns control to the prompt without waiting for the operation to complete.

+```azurepowershell-interactive

+Remove-AzResourceGroup -Name "myResourceGroup" -Force -AsJob

+```

+## Next steps

+> [!div class="nextstepaction"]

+> [Learn how to create a scale set in the Azure portal.](flexible-virtual-machine-scale-sets-portal.md)

+ Title: Create virtual machines in a Flexible scale set using an ARM template

+description: Learn how to create a virtual machine scale set in Flexible orchestration mode using an ARM template.

+# Create virtual machines in a scale set using an ARM template

+This article steps through using an ARM template to create a virtual machine scale set.

+If your environment meets the prerequisites and you're familiar with using ARM templates, select the **Deploy to Azure** button. The template will open in the Azure portal.

+[](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure%2Fazure-quickstart-templates%2Fmaster%2Fquickstarts%2Fmicrosoft.compute%2Fvmss-flexible-orchestration-quickstart%2Fazuredeploy.json)

+## Prerequisites

+If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

+## ARM template

+ARM templates let you deploy groups of related resources. In a single template, you can create the virtual machine scale set, install applications, and configure autoscale rules. With the use of variables and parameters, this template can be reused to update existing, or create additional, scale sets. You can deploy templates through the Azure portal, Azure CLI, or Azure PowerShell, or from continuous integration / continuous delivery (CI/CD) pipelines.

+## Review the template

+```armasm

+{

+ "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",

+ "contentVersion": "1.0.0.0",

+ "parameters": {

+ "location": {

+ "type": "string",

+ "defaultValue": "[resourceGroup().location]",

+ "metadata": {

+ "description": "Location for all resources"

+ }

+ },

+ "vmSku": {

+ "type": "string",

+ "defaultValue": "Standard_D1_v2",

+ "metadata": {

+ "description": "Size of VMs in the VM Scale Set."

+ }

+ },

+ "vmssName": {

+ "type": "string",

+ "metadata": {

+ "description": "String used as a base for naming resources (9 characters or less). A hash is prepended to this string for some resources, and resource-specific information is appended."

+ }

+ },

+ "instanceCount": {

+ "type": "int",

+ "defaultValue": 1,

+ "minValue": 1,

+ "maxValue": 100,

+ "metadata": {

+ "description": "Number of VM instances (100 or less)."

+ }

+ },

+ "adminUsername": {

+ "type": "string",

+ "metadata": {

+ "description": "Admin username on all VMs."

+ }

+ },

+ "authenticationType": {

+ "type": "string",

+ "defaultValue": "sshPublicKey",

+ "allowedValues": [

+ "sshPublicKey",

+ "password"

+ ],

+ "metadata": {

+ "description": "Type of authentication to use on the Virtual Machine. SSH key is recommended."

+ }

+ },

+ "adminPasswordOrKey": {

+ "type": "securestring",

+ "metadata": {

+ "description": "SSH Key or password for the Virtual Machine. SSH key is recommended."

+ }

+ },

+ "_artifactsLocation": {

+ "type": "string",

+ "defaultValue": "[deployment().properties.templatelink.uri]",

+ "metadata": {

+ "description": "The base URI where artifacts required by this template are located"

+ }

+ },

+ "_artifactsLocationSasToken": {

+ "type": "securestring",

+ "defaultValue": "",

+ "metadata": {

+ "description": "The sasToken required to access _artifactsLocation. When the template is deployed using the accompanying scripts, a sasToken will be automatically generated"

+ }

+ }

+ },

+ "variables": {

+ "addressPrefix": "10.0.0.0/16",

+ "subnetPrefix": "10.0.0.0/24",

+ "networkApiVersion": "2020-11-01",

+ "virtualNetworkName": "[concat(parameters('vmssName'), 'vnet')]",

+ "publicIPAddressName": "[concat(parameters('vmssName'), 'pip')]",

+ "subnetName": "[concat(parameters('vmssName'), 'subnet')]",

+ "loadBalancerName": "[concat(parameters('vmssName'), 'lb')]",

+ "publicIPAddressID": "[resourceId('Microsoft.Network/publicIPAddresses',variables('publicIPAddressName'))]",

+ "networkSecurityGroupName": "[concat(parameters('vmssName'), 'nsg')]",

+ "bePoolName": "[concat(parameters('vmssName'), 'bepool')]",

+ "lbRuleName": "[concat(parameters('vmssName'), 'lbrule')]",

+ "lbProbeName": "[concat(parameters('vmssName'), 'lbprobe')]",

+ "bePoolConfigID": "[resourceId('Microsoft.Network/loadBalancers/backendAddressPools', variables('loadBalancerName'),variables('bePoolName'))]",

+ "lbProbeID": "[resourceId('Microsoft.Network/loadBalancers/probes', variables('loadBalancerName'),variables('lbProbeName'))]",

+ "nicName": "[concat(parameters('vmssName'), 'nic')]",

+ "ipConfigName": "[concat(parameters('vmssName'), 'ipconfig')]",

+ "frontEndIPConfigID": "[resourceId('Microsoft.Network/loadBalancers/frontendIPConfigurations', variables('loadBalancerName'),'loadBalancerFrontEnd')]",

+ "osType": {

+ "publisher": "Canonical",

+ "offer": "UbuntuServer",

+ "sku": "16.04-LTS",

+ "version": "latest"

+ },

+ "imageReference": "[variables('osType')]",

+ "linuxConfiguration": {

+ "disablePasswordAuthentication": true,

+ "ssh": {

+ "publicKeys": [

+ {

+ "path": "[concat('/home/', parameters('adminUsername'), '/.ssh/authorized_keys')]",

+ "keyData": "[parameters('adminPasswordOrKey')]"

+ }

+ ]

+ }

+ }

+ },

+ "resources": [

+ {

+ "type": "Microsoft.Network/networkSecurityGroups",

+ "apiVersion": "2020-06-01",

+ "name": "[variables('networkSecurityGroupName')]",

+ "location": "[parameters('location')]",

+ "properties": {

+ "securityRules": [

+ {

+ "name": "AllowPort9000",

+ "properties": {

+ "protocol": "*",

+ "sourcePortRange": "*",

+ "destinationPortRange": "9000",

+ "sourceAddressPrefix": "Internet",

+ "destinationAddressPrefix": "*",

+ "access": "Allow",

+ "priority": 100,

+ "direction": "Inbound"

+ }

+ }

+ ]

+ }

+ },

+ {

+ "type": "Microsoft.Network/virtualNetworks",

+ "apiVersion": "2020-06-01",

+ "name": "[variables('virtualNetworkName')]",

+ "location": "[parameters('location')]",

+ "properties": {

+ "addressSpace": {

+ "addressPrefixes": [

+ "[variables('addressPrefix')]"

+ ]

+ },

+ "subnets": [

+ {

+ "name": "[variables('subnetName')]",

+ "properties": {

+ "addressPrefix": "[variables('subnetPrefix')]",

+ "networkSecurityGroup": {

+ "id": "[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]"

+ }

+ }

+ }

+ ]

+ }

+ },

+ {

+ "type": "Microsoft.Network/publicIPAddresses",

+ "apiVersion": "2020-06-01",

+ "name": "[variables('publicIPAddressName')]",

+ "location": "[parameters('location')]",

+ "sku": {

+ "name": "Standard"

+ },

+ "properties": {

+ "publicIPAllocationMethod": "Static",

+ "dnsSettings": {

+ "domainNameLabel": "[parameters('vmssName')]"

+ }

+ }

+ },

+ {

+ "type": "Microsoft.Network/loadBalancers",

+ "apiVersion": "2020-06-01",

+ "name": "[variables('loadBalancerName')]",

+ "location": "[parameters('location')]",

+ "sku": {

+ "name": "Standard"

+ },

+ "dependsOn": [

+ "[resourceId('Microsoft.Network/publicIPAddresses', variables('publicIPAddressName'))]"

+ ],

+ "properties": {

+ "frontendIPConfigurations": [

+ {

+ "name": "LoadBalancerFrontEnd",

+ "properties": {

+ "publicIPAddress": {

+ "id": "[variables('publicIPAddressID')]"

+ }

+ }

+ }

+ ],

+ "backendAddressPools": [

+ {

+ "name": "[variables('bePoolName')]"

+ }

+ ],

+ "probes": [

+ {

+ "name": "[variables('lbProbeName')]",

+ "properties": {

+ "port": 9000,

+ "protocol": "Tcp",

+ "numberOfProbes": 2,

+ "intervalInSeconds": 5

+ }

+ }

+ ],

+ "loadBalancingRules": [

+ {

+ "name": "[variables('lbRuleName')]",

+ "properties": {

+ "frontendIPConfiguration": {

+ "id": "[variables('frontEndIPConfigID')]"

+ },

+ "backendAddressPool": {

+ "id": "[variables('bePoolConfigID')]"

+ },

+ "probe": {

+ "id": "[variables('lbProbeID')]"

+ },

+ "loadDistribution": "Default",

+ "backendPort": 9000,

+ "frontendPort": 9000,

+ "protocol": "Tcp",

+ "idleTimeoutInMinutes": 4,

+ "enableFloatingIP": false,

+ "enableTcpReset": false,

+ "disableOutboundSnat": false

+ }

+ }

+ ]

+ }

+ },

+ {

+ "type": "Microsoft.Compute/virtualMachineScaleSets",

+ "apiVersion": "2021-03-01",

+ "name": "[parameters('vmssName')]",

+ "location": "[parameters('location')]",

+ "sku": {

+ "name": "[parameters('vmSku')]",

+ "tier": "Standard",

+ "capacity": "[parameters('instanceCount')]"

+ },

+ "dependsOn": [

+ "[resourceId('Microsoft.Network/loadBalancers', variables('loadBalancerName'))]",

+ "[resourceId('Microsoft.Network/virtualNetworks', variables('virtualNetworkName'))]"

+ ],

+ "properties": {

+ "orchestrationMode": "Flexible",

+ "platformFaultDomainCount": 1,

+ "singlePlacementGroup": false,

+ "virtualMachineProfile": {

+ "storageProfile": {

+ "osDisk": {

+ "createOption": "FromImage",

+ "caching": "ReadWrite"

+ },

+ "imageReference": "[variables('imageReference')]"

+ },

+ "osProfile": {

+ "computerNamePrefix": "[parameters('vmssName')]",

+ "adminUsername": "[parameters('adminUsername')]",

+ "adminPassword": "[parameters('adminPasswordOrKey')]",

+ "linuxConfiguration": "[if(equals(parameters('authenticationType'), 'password'), json('null'), variables('linuxConfiguration'))]"

+ },

+ "networkProfile": {

+ "networkApiVersion": "[variables('networkApiVersion')]",

+ "networkInterfaceConfigurations": [

+ {

+ "name": "[variables('nicName')]",

+ "properties": {

+ "primary": true,

+ "ipConfigurations": [

+ {

+ "name": "[variables('ipConfigName')]",

+ "properties": {

+ "primary": true,

+ "subnet": {

+ "id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('virtualNetworkName'), variables('subnetName'))]"

+ },

+ "loadBalancerBackendAddressPools": [

+ {

+ "id": "[resourceId('Microsoft.Network/loadBalancers/backendAddressPools', variables('loadBalancerName'), variables('bePoolName'))]"

+ }

+ ]

+ }

+ }

+ ]

+ }

+ }

+ ]

+ },

+ "extensionProfile": {

+ "extensions": [

+ {

+ "name": "lapextension",

+ "properties": {

+ "publisher": "Microsoft.Azure.Extensions",

+ "type": "CustomScript",

+ "typeHandlerVersion": "2.0",

+ "autoUpgradeMinorVersion": true,

+ "settings": {

+ "fileUris": [

+ "[uri(parameters('_artifactsLocation'), concat('installserver.sh', parameters('_artifactsLocationSasToken')))]",

+ "[uri(parameters('_artifactsLocation'), concat('workserver.py', parameters('_artifactsLocationSasToken')))]"

+ ],

+ "commandToExecute": "bash installserver.sh"

+ }

+ }

+ }

+ ]

+ }

+ }

+ }

+ },

+ {

+ "type": "Microsoft.Insights/autoscaleSettings",

+ "apiVersion": "2015-04-01",

+ "name": "[concat(parameters('vmssName'), '-autoscalehost')]",

+ "location": "[parameters('location')]",

+ "dependsOn": [

+ "[resourceId('Microsoft.Compute/virtualMachineScaleSets', parameters('vmSSName'))]"

+ ],

+ "properties": {

+ "name": "[concat(parameters('vmssName'), '-autoscalehost')]",

+ "targetResourceUri": "[resourceId('Microsoft.Compute/virtualMachineScaleSets', parameters('vmSSName'))]",

+ "enabled": true,

+ "profiles": [

+ {

+ "name": "Profile1",

+ "capacity": {

+ "minimum": "1",

+ "maximum": "10",

+ "default": "1"

+ },

+ "rules": [

+ {

+ "metricTrigger": {

+ "metricName": "Percentage CPU",

+ "metricResourceUri": "[resourceId('Microsoft.Compute/virtualMachineScaleSets', parameters('vmSSName'))]",

+ "timeGrain": "PT1M",

+ "statistic": "Average",

+ "timeWindow": "PT5M",

+ "timeAggregation": "Average",

+ "operator": "GreaterThan",

+ "threshold": 60

+ },

+ "scaleAction": {

+ "direction": "Increase",

+ "type": "ChangeCount",

+ "value": "1",

+ "cooldown": "PT1M"

+ }

+ },

+ {

+ "metricTrigger": {

+ "metricName": "Percentage CPU",

+ "metricResourceUri": "[resourceId('Microsoft.Compute/virtualMachineScaleSets', parameters('vmSSName'))]",

+ "timeGrain": "PT1M",

+ "statistic": "Average",

+ "timeWindow": "PT5M",

+ "timeAggregation": "Average",

+ "operator": "LessThan",

+ "threshold": 30

+ },

+ "scaleAction": {

+ "direction": "Decrease",

+ "type": "ChangeCount",

+ "value": "1",

+ "cooldown": "PT1M"

+ }

+ }

+ ]

+ }

+ ]

+ }

+ }

+ ]

+ }

+```

+These resources are defined in the template:

+- [**Microsoft.Network/virtualNetworks**](/azure/templates/microsoft.network/virtualnetworks)

+- [**Microsoft.Network/publicIPAddresses**](/azure/templates/microsoft.network/publicipaddresses)

+- [**Microsoft.Network/loadBalancers**](/azure/templates/microsoft.network/loadbalancers)

+- [**Microsoft.Compute/virtualMachineScaleSets**](/azure/templates/microsoft.compute/virtualmachinescalesets)

+- [**Microsoft.Insights/autoscaleSettings**](/azure/templates/microsoft.insights/autoscalesettings)

+- [**Microsoft.Network/networkSecurityGroups**](/azure/templates/microsoft.network/networksecuritygroups)

+### Define a scale set

+To create a scale with a template, you define the appropriate resources. The core parts of the virtual machine scale set resource type are:

+| Property | Description of property | Example template value |

+||-|-|

+| type | Azure resource type to create | Microsoft.Compute/virtualMachineScaleSets |

+| name | The scale set name | myScaleSet |

+| location | The location to create the scale set | East US |

+| sku.name | The VM size for each scale set instance | Standard_A1 |

+| sku.capacity | The number of VM instances to initially create | 2 |

+| imageReference | The platform or custom image to use for the VM instances | Canonical Ubuntu Server 16.04-LTS |

+| osProfile.computerNamePrefix | The name prefix for each VM instance | myvmss |

+| osProfile.adminUsername | The username for each VM instance | azureuser |

+| osProfile.adminPassword | The password for each VM instance | P@ssw0rd! |

+To customize a scale set template, you can change the VM size or initial capacity. Another option is to use a different platform or a custom image.

+### Add a sample application

+To test your scale set, install a basic web application. When you deploy a scale set, VM extensions can provide post-deployment configuration and automation tasks, such as installing an app. Scripts can be downloaded from Azure storage or GitHub, or provided to the Azure portal at extension run-time. To apply an extension to your scale set, you add the *extensionProfile* section to the preceding resource example. The extension profile typically defines the following properties:

+- Extension type

+- Extension publisher

+- Extension version

+- Location of configuration or install scripts

+- Commands to execute on the VM instances

+The template uses the Custom Script Extension to install [Bottle](https://bottlepy.org/docs/dev/), a Python web framework, and a simple HTTP server.

+Two scripts are defined in **fileUris** - *installserver.sh*, and *workserver.py*. These files are downloaded from GitHub, then *commandToExecute* runs `bash installserver.sh` to install and configure the app.

+## Deploy the template

+You can also deploy a Resource Manager template by using Azure CLI:

+```azurecli-interactive

+# Create a resource group

+az group create --name myResourceGroup --location EastUS

+# Deploy template into resource group

+az deployment group create -g myResourceGroup -f azuredeploy.json --parameters _artifactsLocation=https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/application-workloads/python/vmss-bottle-autoscale/azuredeploy.json

+```

+Answer the prompts to provide a scale set name, instance count, and admin credentials for the VM instances. It takes a few minutes for the scale set and supporting resources to be created.

+## Validate the deployment

+To see your scale set in action, access the sample web application in a web browser. Obtain the public IP address of the load balancer with [az network public-ip list](/cli/azure/network/public-ip) as follows:

+```azurecli-interactive

+az network public-ip list \

+ --resource-group myResourceGroup \

+ --query [*].ipAddress -o tsv

+```

+Enter the public IP address of the load balancer in to a web browser in the format *http:\//publicIpAddress:9000/do_work*. The load balancer distributes traffic to one of your VM instances, as shown in the following example:

+

+## Clean up resources

+When no longer needed, you can use [az group delete](/cli/azure/group) to remove the resource group, scale set, and all related resources as follows. The `--no-wait` parameter returns control to the prompt without waiting for the operation to complete. The `--yes` parameter confirms that you wish to delete the resources without an additional prompt to do so.

+```azurecli-interactive

+az group delete --name myResourceGroup --yes --no-wait

+```

+## Next steps

+> [!div class="nextstepaction"]

+> [Learn how to create a Flexible scale set in the Azure portal.](flexible-virtual-machine-scale-sets-portal.md)

+> You can't currently create a virtual machine scale set using Flexible orchestration mode from an image shared by another tenant.

+> [!NOTE]

+> We recommend using Flexible virtual machine scale sets for new workloads. Learn more about this new orchestration mode in our [Flexible virtual machine scale sets overview](flexible-virtual-machine-scale-sets.md).

+Azure virtual machine scale sets let you create and manage a group of load balanced VMs. The number of VM instances can automatically increase or decrease in response to demand or a defined schedule. Scale sets provide the following key benefits:

+- Easy to create and manage multiple VMs

+- Provides high availability and application resiliency by distributing VMs across availability zones or fault domains

+- Allows your application to automatically scale as resource demand changes

+- Works at large-scale

+With Flexible orchestration, Azure provides a unified experience across the Azure VM ecosystem. Flexible orchestration offers high availability guarantees (up to 1000 VMs) by spreading VMs across fault domains in a region or within an Availability Zone. This enables you to scale out your application while maintaining fault domain isolation that is essential to run quorum-based or stateful workloads, including:

+- Quorum-based workloads

+- Open-source databases

+- Stateful applications

+- Services that require high availability and large scale

+- Services that want to mix virtual machine types or leverage Spot and on-demand VMs together

+- Existing Availability Set applications

+Learn more about the differences between Uniform scale sets and Flexible scale sets in [Orchestration Modes](../virtual-machine-scale-sets/virtual-machine-scale-sets-orchestration-modes.md).

+> The orchestration mode is defined when you create the scale set and cannot be changed or updated later.

+Azure virtual machine scale sets provide the management capabilities for applications that run across many VMs, automatic scaling of resources, and load balancing of traffic. Scale sets provide the following key benefits:

+ - Scale sets support up to 1,000 VM instances for standard marketplace images and custom images through the Azure Compute Gallery (formerly known as Shared Image Gallery). If you create a scale set using a managed image, the limit is 600 VM instances.

+> [Flexible orchestration mode for your scale sets with Azure portal.](flexible-virtual-machine-scale-sets-portal.md)

+description: Learn about creating proximity placement groups for Windows virtual machine scale sets in Azure.

+# Create a proximity placement group using PowerShell

+Placing VMs in a single region reduces the physical distance between the instances. Placing them within a single availability zone will also bring them physically closer together. However, as the Azure footprint grows, a single availability zone may span multiple physical data centers, which may result in a network latency impacting your application.

+To get VMs as close as possible, achieving the lowest possible latency, you can deploy them within a proximity placement group.

+- Low latency between stand-alone VMs.

+- Low Latency between VMs in a single availability set or a virtual machine scale set.

+- Low latency between stand-alone VMs, VMs in multiple Availability Sets, or multiple scale sets. You can have multiple compute resources in a single placement group to bring together a multi-tiered application.

+- Low latency between multiple application tiers using different hardware types. For example, running the backend using M-series in an availability set and the front end on a D-series instance, in a scale set, in a single proximity placement group.

+## Using Proximity Placement Groups

+A proximity placement group is a resource in Azure. You need to create one before using it with other resources. Once created, it could be used with virtual machines, availability sets, or virtual machine scale sets.

+You specify a proximity placement group when creating compute resources providing the proximity placement group ID.

+You can also move an existing resource into a proximity placement group. When moving a resource into a proximity placement group, you should stop (deallocate) the asset first since it will be redeployed potentially into a different data center in the region to satisfy the colocation constraint.

+In the case of availability sets and virtual machine scale sets, you should set the proximity placement group at the resource level rather than the individual virtual machines.

+A proximity placement group is a colocation constraint rather than a pinning mechanism. It is pinned to a specific data center with the deployment of the first resource to use it. Once all resources using the proximity placement group have been stopped (deallocated) or deleted, it is no longer pinned. Therefore, when using a proximity placement group with multiple VM series, it is important to specify all the required types upfront in a template when possible or follow a deployment sequence which will improve your chances for a successful deployment. If your deployment fails, restart the deployment with the VM size which has failed as the first size to be deployed.

+## What to expect when using Proximity Placement Groups

+Proximity placement groups offer colocation in the same data center. However, because proximity placement groups represent an additional deployment constraint, allocation failures can occur. There are few use cases where you may see allocation failures when using proximity placement groups:

+- When you ask for the first virtual machine in the proximity placement group, the data center is automatically selected. In some cases, a second request for a different virtual machine SKU, may fail if it doesn't exist in that data center. In this case, an **OverconstrainedAllocationRequest** error is returned. To avoid this, try changing the order in which you deploy your SKUs or have both resources deployed using a single ARM template.

+- In the case of elastic workloads, where you add and remove VM instances, having a proximity placement group constraint on your deployment may result in a failure to satisfy the request resulting in **AllocationFailure** error.

+- Stopping (deallocate) and starting your VMs as needed is another way to achieve elasticity. Since the capacity is not kept once you stop (deallocate) a VM, starting it again may result in an **AllocationFailure** error.

+- VM start and redeploy operations will continue to respect the Proximity Placement Group once successfully configured.

+## Planned maintenance and Proximity Placement Groups

+Planned maintenance events, like hardware decommissioning at an Azure datacenter, could potentially affect the alignment of resources in proximity placement groups. Resources may be moved to a different data center, disrupting the collocation and latency expectations associated with the proximity placement group.

+### Check the alignment status

+You can do the following to check the alignment status of your proximity placement groups.

+- Proximity placement group colocation status can be viewed using the portal, CLI, and PowerShell.

+ - For PowerShell, colocation status can be obtained using Get-AzProximityPlacementGroup cmdlet by including the optional parameter ΓÇÿ-ColocationStatus`.

+ - For CLI, colocation status can be obtained using `az ppg show` by including the optional parameter ΓÇÿ--include-colocation-status`.

+- For each proximity placement group, a **colocation status** property

+ provides the current alignment status summary of the grouped resources.

+ - **Aligned**: Resource is within the same latency envelop of the proximity placement group.

+ - **Unknown**: at least one of the VM resources are deallocated. Once they start successfully, the status will go back to **Aligned**.

+ - **Not aligned**: at least one VM resource is not aligned with the proximity placement group. The specific resources which are not aligned will also be called out separately in the membership section

+- For Availability Sets, you can see information about alignment of individual VMs in the Availability Set Overview page.

+- For scale sets, information about alignment of individual instances can be seen in the **Instances** tab of the **Overview** page for the scale set.

+### Re-align resources

+If a proximity placement group is `Not Aligned`, you can stop\deallocate and then restart the affected resources. If the VM is in an availability set or a scale set, all VMs in the availability set or scale set must be stopped\deallocated first before restarting them.

+If there is an allocation failure due to deployment constraints, you may have to stop\deallocate all resources in the affected proximity placement group (including the aligned resources) first and then restart them to restore alignment.

+## Best practices

+- For the lowest latency, use proximity placement groups together with accelerated networking. For more information, see [Create a Linux virtual machine with Accelerated Networking](../virtual-network/create-vm-accelerated-networking-cli.md) or [Create a Windows virtual machine with Accelerated Networking](../virtual-network/create-vm-accelerated-networking-powershell.md).

+- Deploy all VM sizes in a single template. In order to avoid landing on hardware that doesn't support all the VM SKUs and sizes you require, include all of the application tiers in a single template so that they will all be deployed at the same time.

+- If you are scripting your deployment using PowerShell, CLI or the SDK, you may get an allocation error `OverconstrainedAllocationRequest`. In this case, you should stop/deallocate all the existing VMs, and change the sequence in the deployment script to begin with the VM SKU/sizes that failed.

+- When reusing an existing placement group from which VMs were deleted, wait for the deletion to fully complete before adding VMs to it.

+- If latency is your first priority, put VMs in a proximity placement group and the entire solution in an availability zone. But, if resiliency is your top priority, spread your instances across multiple availability zones (a single proximity placement group cannot span zones).

+## Create a scale set in a proximity placement group

+> [!NOTE]

+> This quickstart uses Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for virtual machine scale sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).

+> [!NOTE]

+> The following article is for Uniform virtual machine scale sets. We recommend using Flexible virtual machine scale sets for new workloads. Learn more about this new orchestration mode in our [Flexible virtual machine scale sets overview](flexible-virtual-machine-scale-sets.md).

+> [!NOTE]

+> The following article is for Uniform virtual machine scale sets. We recommend using Flexible virtual machine scale sets for new workloads. Learn more about this new orchestration mode in our [Flexible virtual machine scale sets overview](flexible-virtual-machine-scale-sets.md).

+> [!NOTE]

+> The following article is for Uniform virtual machine scale sets. We recommend using Flexible virtual machine scale sets for new workloads. Learn more about this new orchestration mode in our [Flexible virtual machine scale sets overview](flexible-virtual-machine-scale-sets.md).

+> [!NOTE]

+> The following article is for Uniform virtual machine scale sets. We recommend using Flexible virtual machine scale sets for new workloads. Learn more about this new orchestration mode in our [Flexible virtual machine scale sets overview](flexible-virtual-machine-scale-sets.md).

+> [!NOTE]

+> The following article is for Uniform virtual machine scale sets. We recommend using Flexible virtual machine scale sets for new workloads. Learn more about this new orchestration mode in our [Flexible virtual machine scale sets overview](flexible-virtual-machine-scale-sets.md).

+> [!NOTE]

+> This tutorial uses Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for virtual machine scale sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).

+> [!NOTE]

+> This tutorial uses Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for virtual machine scale sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).

+> [!NOTE]

+> This tutorial uses Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for virtual machine scale sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).

+> [!NOTE]

+> This tutorial uses Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for virtual machine scale sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).

+It takes a few minutes to update the capacity of your scale set. To see the number of instances you now have in the scale set, use [az vmss show](/cli/azure/vmss) and query on *sku.capacity*:

+ Title: 'Tutorial: Create and manage a virtual machine scale set with Azure PowerShell'

+> [!NOTE]

+> This tutorial uses Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for virtual machine scale sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).

+The marketplace includes many images that can be used to create VM instances. To see a list of available publishers, use the [Get-AzVMImagePublisher](/powershell/module/az.compute/get-azvmimagepublisher) command.

+It takes a few minutes to update the capacity of your scale set. To see the number of instances you now have in the scale set, use [Get-AzVmss](/powershell/module/az.compute/get-azvmss):

+> [!NOTE]

+> This tutorial uses Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for virtual machine scale sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).

+> [!NOTE]

+> This tutorial uses Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for virtual machine scale sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).

+> [!NOTE]

+> This tutorial uses Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for virtual machine scale sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).

+> [!NOTE]

+> This tutorial uses Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for virtual machine scale sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).

+Create the scale set using [`az vmss create`](/cli/azure/vmss#az-vmss-create) using the --specialized parameter to indicate the image is a specialized image.

+> [!NOTE]

+> This tutorial uses Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for virtual machine scale sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).

+You can see a list of VMs that are available in a resource group using [Get-AzVM](/powershell/module/az.compute/get-azvm). Once you know the VM name and what resource group, you can use `Get-AzVM` again to get the VM object and store it in a variable to use later. This example gets a VM named *sourceVM* from the "myResourceGroup" resource group and assigns it to the variable *$vm*.

+> [!NOTE]

+> This tutorial uses Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for virtual machine scale sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).

+> [!NOTE]

+> This tutorial uses Uniform Orchestration mode. We recommend using Flexible Orchestration for new workloads. For more information, see [Orchesration modes for virtual machine scale sets in Azure](virtual-machine-scale-sets-orchestration-modes.md).