Merge branch 'MicrosoftDocs:main' into patch-3

Author: ggailey777

articles/azure-portal/TOC.yml

@@ -79,6 +79,8 @@
     displayName: mobile, app, training
   - name: Microsoft Copilot in Azure
     href: mobile-app/microsoft-copilot-in-azure.md
+  - name: Intune MAM
+    href: mobile-app/intune-management.md
 - name: Reference
   items:
   - name: Supported browsers and devices

articles/azure-portal/mobile-app/intune-management.md

@@ -0,0 +1,53 @@
+---
+title: Use Microsoft Intune MAM on devices that run the Azure mobile app
+description: Learn about setting and enforcing app protection policies on devices that run the Azure mobile app.
+ms.date: 06/17/2024
+ms.topic: conceptual
+ms.custom:
+  - build-2024
+---
+
+# Use Microsoft Intune mobile application management (MAM) on devices that run the Azure mobile app
+
+[Microsoft Intune mobile application management (MAM)](/mem/intune/apps/app-management) is a cloud-based service that allows an organization to protect its data at the app level on both company devices and users' personal devices, such as smartphones, tablets, and laptops.
+
+Since the Azure mobile app is an Intune-protected app, app protection policies (APP) can be applied and enforced on devices that run the Azure mobile app.
+
+## App protection policies and settings
+
+Intune [app protection policies (APP)](/mem/intune/apps/app-protection-policy) are rules or sets of action that ensure an organization's data remains safe. Administrators use these policies to control how data is accessed and shared. For an overview of how to create an app protection policy, see [How to create and assign app protection policies](/mem/intune/apps/app-protection-policies).
+
+Available app protection settings are continuously being updated and may vary across platforms. For details about the currently available settings, see [Android app protection policy settings in Microsoft Intune](/mem/intune/apps/app-protection-policy-settings-android) and [iOS app protection policy settings](/mem/intune/apps/app-protection-policy-settings-ios) devices.
+
+## User management
+
+With Intune MAM, you can select and assign groups of users to include and exclude in your policies, allowing you to control who has access to your data in Azure Mobile. For more information on user and group assignments, see [Include and exclude app assignments in Microsoft Intune](/mem/intune/apps/apps-inc-exl-assignments).
+
+An Intune license is required in order for app protection policies to apply correctly to a user or group. If an unlicensed user is included in an app protection policy, the rules of that policy won't be applied to that user.
+
+Only Intune-targeted users and groups will be subject to the rules of the app protection policy. To ensure data remains protected, verify that the necessary groups and users were included in your policy during creation.
+
+Users that are out of compliance with their MAM policy or Conditional Access policy may lose access to data and resources, including full access to the Azure mobile app. When a user is marked as out of compliance, the Azure mobile app may initially try automated remediation to regain compliance. If automatic remediation is disabled or unsuccessful, the user is signed out of the app.
+
+You can use [Microsoft Entra Conditional Access policies in combination with Intune compliance policies](/mem/intune/protect/app-based-conditional-access-intune) to ensure that only managed apps and policy-compliant users can access corporate data.
+
+## User experience
+
+When  Intune-licensed Azure mobile app users are targeted with an Intune MAM policy, they are subject to all rules and actions dictated by their policy. When these users sign in to the Azure Mobile app, policy rules are retrieved and enacted immediately, before allowing access to any corporate data.
+
+For example, a user's MAM policy may specify a 6-digit PIN requirement. When that user first signs into the Azure mobile app, they see a message from Intune MAM that describes their current device state and asks them to set an access PIN.
+
+:::image type="content" source="media/intune-management/intune-intro-message.png" alt-text="Screenshot of an introductory message from Intune MAM in the Azure mobile app.":::   :::image type="content" source="media/intune-management/intune-pin-prompt.png" alt-text="Screenshot of Intune MAM prompting the user to set up a PIN in the Azure mobile app.":::
+
+After the user sets up their PIN, they'll be prompted to enter that PIN every time they sign in. The PIN must be entered in order to use the Azure mobile app.
+
+:::image type="content" source="media/intune-management/intune-pin-enter.png" alt-text="Screenshot of Intune MAM prompting the user to enter their PIN in the Azure mobile app.":::
+
+If a user is marked as out of compliance with their policy (following any remediation steps), they'll be signed out of the app. For example, a user might switch to a different policy-protected account that was marked as out of compliance. In this case, the app signs them out and displays a message notifying the user that they must sign back in.
+
+:::image type="content" source="media/intune-management/intune-sign-in-required.png" alt-text="Screenshot of Intune MAM requiring a user to sign back in to the Azure mobile app.":::
+
+## Next steps
+
+- Learn more about the [Microsoft Intune](/mem/intune/fundamentals/what-is-intune).
+- Download the Azure mobile app for free from the [Apple App Store](https://aka.ms/azureapp/ios/doc), [Google Play](https://aka.ms/azureapp/android/doc), or [Amazon App Store](https://aka.ms/azureapp/amazon/doc).

articles/azure-portal/mobile-app/media/intune-management/intune-intro-message.png

@@ -11,15 +11,15 @@ ms.date: 11/13/2023
 
 # Security policy for Confidential Containers on Azure Kubernetes Service
 
-As described by the Confidential Computing Consortium (CCC), *"Confidential Computing is the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment (TEE)."* AKS Confidential Containers are designed to protect Kubernetes pods data in use from unauthorized access from outside of these pods. Each pod is executed in a Confidential Virtual Machine (CVM) protected by the [AMD SEV-SNP TEE](https://www.amd.com/content/dam/amd/en/documents/epyc-business-docs/white-papers/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf) by encrypting data in use and prevent access to the data by the Host Operating System (OS). Microsoft engineers collaborated with the [Confidential Containers](https://github.com/confidential-containers) (CoCo) and [Kata Containers](https://github.com/kata-containers/) open-source communities on the design and implementation of the Confidential Containers.  
+As described by the Confidential Computing Consortium (CCC), *"Confidential Computing is the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment (TEE)."* AKS Confidential Containers are designed to protect Kubernetes pods data in use from unauthorized access from outside of these pods. Each pod is executed in a Utility VM (UVM) protected by the [AMD SEV-SNP TEE](https://www.amd.com/content/dam/amd/en/documents/epyc-business-docs/white-papers/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf) by encrypting data in use and prevent access to the data by the Host Operating System (OS). Microsoft engineers collaborated with the [Confidential Containers](https://github.com/confidential-containers) (CoCo) and [Kata Containers](https://github.com/kata-containers/) open-source communities on the design and implementation of the Confidential Containers.  
 
 ## Security policy overview
 
-One of the main components of the [Kata Containers system architecture](https://github.com/kata-containers/kata-containers/blob/main/docs/design/architecture/history.md#kata-2x-architecture) is the [Kata agent](https://github.com/kata-containers/kata-containers/blob/main/docs/design/architecture/README.md#agent). When using Kata Containers to implement Confidential Containers, the agent is executed inside the hardware-based TEE and therefore is part of the pod's Trusted Computing Base (TCB). As shown in the following diagram, the Kata agent provides a set of [ttrpc](https://github.com/containerd/ttrpc) APIs allowing the system components outside of the TEE to create and manage CVM-based Kubernetes pods. These other components (for example, the Kata Shim) aren't part of the pod's TCB. Therefore, the agent must protect itself from potentially buggy or malicious API calls.
+One of the main components of the [Kata Containers system architecture](https://github.com/kata-containers/kata-containers/blob/main/docs/design/architecture/history.md#kata-2x-architecture) is the [Kata agent](https://github.com/kata-containers/kata-containers/blob/main/docs/design/architecture/README.md#agent). When using Kata Containers to implement Confidential Containers, the agent is executed inside the hardware-based TEE and therefore is part of the pod's Trusted Computing Base (TCB). As shown in the following diagram, the Kata agent provides a set of [ttrpc](https://github.com/containerd/ttrpc) APIs allowing the system components outside of the TEE to create and manage Confidential-based Kubernetes pods. These other components (for example, the Kata Shim) aren't part of the pod's TCB. Therefore, the agent must protect itself from potentially buggy or malicious API calls.
 
 :::image type="content" source="media/confidential-containers-security-policy/security-policy-architecture-diagram.png" alt-text="Diagram of the AKS Confidential Containers security policy model.":::
 
-In AKS Confidential Containers, the Kata agent API self-protection is implemented using a security policy (also known as the Kata *Agent Policy*), specified by the owners of the confidential pods. The policy document contains rules and data corresponding to each pod, using the industry standard [Rego policy language](https://www.openpolicyagent.org/docs/latest/policy-language/). The enforcement of the policy inside the CVM is implemented using the [Open Policy Agent (OPA)](https://www.openpolicyagent.org/) – a graduated project of the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/).
+In AKS Confidential Containers, the Kata agent API self-protection is implemented using a security policy (also known as the Kata *Agent Policy*), specified by the owners of the confidential pods. The policy document contains rules and data corresponding to each pod, using the industry standard [Rego policy language](https://www.openpolicyagent.org/docs/latest/policy-language/). The enforcement of the policy inside the Utility VM (UVM) is implemented using the [Open Policy Agent (OPA)](https://www.openpolicyagent.org/) – a graduated project of the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/).
 
 ## Policy contents
 
@@ -44,9 +44,9 @@ Examples of data included in the policy document for each of the containers in a
 
 ### Rules
 
-The policy rules, specified in Rego format, get executed by OPA for each Kata agent API call from outside of the CVM. The agent provides all API inputs to OPA, and OPA uses the rules to check if the inputs are consistent with policy data. If the policy rules and data doesn't allow API inputs, the agent rejects the API call by returning a "blocked by policy" error message. Here are some rule examples:
+The policy rules, specified in Rego format, get executed by OPA for each Kata agent API call from outside of the Utility VM (UVM). The agent provides all API inputs to OPA, and OPA uses the rules to check if the inputs are consistent with policy data. If the policy rules and data doesn't allow API inputs, the agent rejects the API call by returning a "blocked by policy" error message. Here are some rule examples:
 
-* Each container layer is exposed as a read-only [virtio block](https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-2390002) device to the CVM. The integrity of those block devices is protected using the [dm-verity](https://docs.kernel.org/admin-guide/device-mapper/verity.html) technology of the Linux kernel. The expected root value of the dm-verity [hash tree](https://docs.kernel.org/admin-guide/device-mapper/verity.html#hash-tree) is included in the policy data, and verified at runtime by the policy rules.
+* Each container layer is exposed as a read-only [virtio block](https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#x1-2390002) device to the Utility VM (UVM). The integrity of those block devices is protected using the [dm-verity](https://docs.kernel.org/admin-guide/device-mapper/verity.html) technology of the Linux kernel. The expected root value of the dm-verity [hash tree](https://docs.kernel.org/admin-guide/device-mapper/verity.html#hash-tree) is included in the policy data, and verified at runtime by the policy rules.
 * Rules reject Container creation when an unexpected command line, storage mount, execution security context, or environment variable is detected.
 
 By default, policy [rules](https://github.com/microsoft/kata-containers/blob/2795dae5e99bd918b7b8d0a9643e9a857e95813d/src/tools/genpolicy/rules.rego#L37) are common to all pods. The *genpolicy* tool generates the policy data and is specific to each pod.
@@ -61,17 +61,17 @@ When evaluating the Rego rules using the policy data and API inputs as parameter
 
 ## Sending the policy to Kata agent
 
-All AKS Confidential Containers CVMs start up using a generic, default policy included in the CVMs root file system. Therefore, a Policy that matches the actual customer workload must be provided to the agent at run time. The policy text is embedded in your YAML manifest file as described earlier, and is provided this way to the agent early during CVM initialization. The policy annotation travels through the kubelet, containerd, and [Kata shim](https://github.com/kata-containers/kata-containers/blob/main/src/runtime/cmd/containerd-shim-kata-v2) components of the AKS Confidential Containers system. Then the agent working together with OPA enforces the policy for all the calls to its own APIs.
+All AKS Confidential Container Utility VM (UVM) start up using a generic, default policy included in the Utility VM (UVM) root file system. Therefore, a Policy that matches the actual customer workload must be provided to the agent at run time. The policy text is embedded in your YAML manifest file as described earlier, and is provided this way to the agent early during Utility VM (UVM) initialization. The policy annotation travels through the kubelet, containerd, and [Kata shim](https://github.com/kata-containers/kata-containers/blob/main/src/runtime/cmd/containerd-shim-kata-v2) components of the AKS Confidential Containers system. Then the agent working together with OPA enforces the policy for all the calls to its own APIs.
 
 The policy is provided using components that aren't part of your TCB, so initially this policy isn't trusted. The trustworthiness of the policy must be established through Remote Attestation, as described in the following section.
 
 ## Establish trust in the policy document
 
-Before creating the Pod CVM, the Kata shim computes the SHA256 hash of the Policy document and attaches that hash value to the TEE. That action creates a strong binding between the contents of the Policy and the CVM. This TEE field isn't modifiable later by either the software executed inside the CVM, or outside of it.
+Before creating the Utility VM (UVM), the Kata shim computes the SHA256 hash of the Policy document and attaches that hash value to the TEE. That action creates a strong binding between the contents of the Policy and the Utility VM (UVM). This TEE field isn't modifiable later by either the software executed inside the Utility VM (UVM), or outside of it.
 
 Upon receiving the policy, the agent verifies the hash of the policy matches the immutable TEE field. The agent rejects the incoming Policy if it detects a hash mismatch.
 
-Before handling sensitive information, your workloads must perform Remote Attestation steps to prove to any Relying Party that the workload is executed using the expected versions of the TEE, OS, agent, OPA, and root file system versions. Attestation is implemented in a Container running inside the CVM that obtains signed attestation evidence from the AMD SEV-SNP hardware. One of the fields from the attestation evidence is the policy hash TEE field described earlier. Therefore, the Attestation service can verify the integrity of the policy, by comparing the value of this field with the expected hash of the pod policy.
+Before handling sensitive information, your workloads must perform Remote Attestation steps to prove to any Relying Party that the workload is executed using the expected versions of the TEE, OS, agent, OPA, and root file system versions. Attestation is implemented in a Container running inside the Utility VM (UVM) that obtains signed attestation evidence from the AMD SEV-SNP hardware. One of the fields from the attestation evidence is the policy hash TEE field described earlier. Therefore, the Attestation service can verify the integrity of the policy, by comparing the value of this field with the expected hash of the pod policy.
 
 ## Policy enforcement
 

articles/azure-portal/mobile-app/media/intune-management/intune-pin-enter.png

@@ -0,0 +1,25 @@
+---
+author: seesharprun
+ms.author: sidandrews
+ms.service: cosmos-db
+ms.subservice: mongodb
+ms.topic: include
+ms.date: 06/14/2024
+ms.custom: include file
+zone_pivot_groups: azure-cosmos-db-quickstart-env
+---
+
+::: zone pivot="devcontainer-codespace"
+
+- An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).
+- [GitHub account](https://docs.github.com//get-started/quickstart/creating-an-account-on-github)
+
+::: zone-end
+
+::: zone pivot="devcontainer-vscode"
+
+- An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).
+- [Azure Developer CLI](/azure/developer/azure-developer-cli/install-azd)
+- [Docker Desktop](https://www.docker.com/products/docker-desktop/)
+
+::: zone-end