Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into rolyon-aadroles-roles-security-operator-identity-protection

Author: rolyon

articles/container-apps/quotas.md

@@ -6,7 +6,7 @@ author: craigshoemaker
 ms.service: container-apps
 ms.custom: event-tier1-build-2022
 ms.topic: conceptual
-ms.date: 11/21/2022
+ms.date: 02/17/2023
 ms.author: cshoe
 ---
 
@@ -18,8 +18,8 @@ To request an increase in quota amounts for your container app, learn [how to re
 
 | Feature | Scope | Default | Is Configurable<sup>1</sup> | Remarks |
 |--|--|--|--|--|
-| Environments | Region |  Up to 5 | Yes | Limit up to five environments per subscription, per region.<br><br>For example, if you deploy to three regions you can get up to 15 environments for a single subscription. |
-| Container Apps | Environment | 20 | Yes | |
+| Environments | Region |  Up to 15 | Yes | Limit up to 15 environments per subscription, per region.<br><br>For example, if you deploy to three regions you can get up to 45 environments for a single subscription. |
+| Container Apps | Environment | Unlimited | Yes | |
 | Revisions | Container app | 100 | No | |
 | Replicas | Revision | 30 | Yes | |
 | Cores | Replica | 2 | No | Maximum number of cores that can be requested by a revision replica. |

articles/machine-learning/how-to-deploy-mlflow-models-online-endpoints.md

@@ -21,11 +21,11 @@ ms.custom: deploy, mlflow, devplatv2, no-code-deployment, devx-track-azurecli, c
 > * [v1](./v1/how-to-deploy-mlflow-models.md)
 > * [v2 (current version)](how-to-deploy-mlflow-models-online-endpoints.md)
 
-In this article, learn how to deploy your [MLflow](https://www.mlflow.org) model to an [online endpoint](concept-endpoints.md) for real-time inference. When you deploy your MLflow model to an online endpoint, you don't need to indicate a scoring script or an environment. This characteristic is usually referred as __no-code deployment__. 
+In this article, learn how to deploy your [MLflow](https://www.mlflow.org) model to an [online endpoint](concept-endpoints.md) for real-time inference. When you deploy your MLflow model to an online endpoint, you don't need to indicate a scoring script or an environment. This characteristic is referred as __no-code deployment__. 
 
 For no-code-deployment, Azure Machine Learning 
 
-* Dynamically installs Python packages provided in the `conda.yaml` file, this means the dependencies are installed during container runtime.
+* Dynamically installs Python packages provided in the `conda.yaml` file. Hence, dependencies are installed during container runtime.
 * Provides a MLflow base image/curated environment that contains the following items:
     * [`azureml-inference-server-http`](how-to-inference-server-http.md) 
     * [`mlflow-skinny`](https://github.com/mlflow/mlflow/blob/master/README_SKINNY.rst)
@@ -37,11 +37,11 @@ For no-code-deployment, Azure Machine Learning
 
 ## About this example
 
-This example shows how you can deploy an MLflow model to an online endpoint to perform predictions. This example uses an MLflow model based on the [Diabetes dataset](https://www4.stat.ncsu.edu/~boos/var.select/diabetes.html). This dataset contains ten baseline variables, age, sex, body mass index, average blood pressure, and six blood serum measurements obtained from n = 442 diabetes patients, as well as the response of interest, a quantitative measure of disease progression one year after baseline (regression).
+This example shows how you can deploy an MLflow model to an online endpoint to perform predictions. This example uses an MLflow model based on the [Diabetes dataset](https://www4.stat.ncsu.edu/~boos/var.select/diabetes.html). This dataset contains ten baseline variables, age, sex, body mass index, average blood pressure, and six blood serum measurements obtained from n = 442 diabetes patients. It also contains the response of interest, a quantitative measure of disease progression one year after baseline (regression).
 
-The model has been trained using an `scikit-learn` regressor and all the required preprocessing has been packaged as a pipeline, making this model an end-to-end pipeline that goes from raw data to predictions.
+The model was trained using an `scikit-learn` regressor and all the required preprocessing has been packaged as a pipeline, making this model an end-to-end pipeline that goes from raw data to predictions.
 
-The information in this article is based on code samples contained in the [azureml-examples](https://github.com/azure/azureml-examples) repository. To run the commands locally without having to copy/paste YAML and other files, clone the repo and then change directories to the `cli/endpoints/online` if you are using the Azure CLI or `sdk/endpoints/online` if you are using our SDK for Python.
+The information in this article is based on code samples contained in the [azureml-examples](https://github.com/azure/azureml-examples) repository. To run the commands locally without having to copy/paste YAML and other files, clone the repo, and then change directories to the `cli/endpoints/online` if you are using the Azure CLI or `sdk/endpoints/online` if you are using our SDK for Python.
 
 ```azurecli
 git clone https://github.com/Azure/azureml-examples --depth 1
@@ -58,9 +58,9 @@ Before following the steps in this article, make sure you have the following pre
 
 - An Azure subscription. If you don't have an Azure subscription, create a free account before you begin. Try the [free or paid version of Azure Machine Learning](https://azure.microsoft.com/free/).
 - Azure role-based access controls (Azure RBAC) are used to grant access to operations in Azure Machine Learning. To perform the steps in this article, your user account must be assigned the owner or contributor role for the Azure Machine Learning workspace, or a custom role allowing Microsoft.MachineLearningServices/workspaces/onlineEndpoints/*. For more information, see [Manage access to an Azure Machine Learning workspace](how-to-assign-roles.md).
-- You must have a MLflow model registered in your workspace. Particularly, this example will register a model trained for the [Diabetes dataset](https://www4.stat.ncsu.edu/~boos/var.select/diabetes.html).
+- You must have a MLflow model registered in your workspace. Particularly, this example registers a model trained for the [Diabetes dataset](https://www4.stat.ncsu.edu/~boos/var.select/diabetes.html).
 
-Additionally, you will need to:
+Additionally, you need to:
 
 # [Azure CLI](#tab/cli)
 
@@ -86,7 +86,7 @@ Additionally, you will need to:
 
 # [Studio](#tab/studio)
 
-There are no additional prerequisites when working in Azure Machine Learning studio.
+There are no more prerequisites when working in Azure Machine Learning studio.
 
 ---
 
@@ -104,7 +104,7 @@ az configure --defaults workspace=<workspace> group=<resource-group> location=<l
 
 # [Python (Azure ML SDK)](#tab/sdk)
 
-The workspace is the top-level resource for Azure Machine Learning, providing a centralized place to work with all the artifacts you create when you use Azure Machine Learning. In this section, we'll connect to the workspace in which you'll perform deployment tasks.
+The workspace is the top-level resource for Azure Machine Learning, providing a centralized place to work with all the artifacts you create when you use Azure Machine Learning. In this section, we connect to the workspace in which you perform deployment tasks.
 
 1. Import the required libraries:
 
@@ -587,7 +587,7 @@ Use the following steps to deploy an MLflow model with a custom scoring script.
             raise Exception("Request must contain a top level key named 'input_data'")
         
         serving_input = json.dumps(json_data["input_data"])
-        data = infer_and_parse_json_input(raw_data, input_schema)
+        data = infer_and_parse_json_input(serving_input, input_schema)
         result = model.predict(data)
         
         result = StringIO()

articles/service-bus-messaging/service-bus-authentication-and-authorization.md

@@ -2,14 +2,19 @@
 title: Azure Service Bus authentication and authorization | Microsoft Docs
 description: Authenticate apps to Service Bus with Shared Access Signature (SAS) authentication.
 ms.topic: article
-ms.date: 02/01/2022
+ms.date: 02/17/2023
 ---
 
 # Service Bus authentication and authorization
-There are two ways to authenticate and authorize access to Azure Service Bus resources: Azure Active Directory (Azure AD) and Shared Access Signatures (SAS). This article gives you details on using these two types of security mechanisms. 
+There are two ways to authenticate and authorize access to Azure Service Bus resources: 
+
+- Azure Active Directory (Azure AD)
+- Shared Access Signatures (SAS). 
+
+This article gives you details on using these two types of security mechanisms. 
 
 ## Azure Active Directory
-Azure AD integration for Service Bus resources provides Azure role-based access control (RBAC) for fine-grained control over a client’s access to resources. You can use Azure RBAC to grant permissions to a security principal, which may be a user, a group, or an application service principal. The security principal is authenticated by Azure AD to return an OAuth 2.0 token. The token can be used to authorize a request to access a Service Bus resource (queue, topic, and so on).
+Azure AD integration with Service Bus provides role-based access control (RBAC) to Service Bus resources. You can use Azure RBAC to grant permissions to a security principal, which may be a user, a group, or an application service principal. Azure AD authenticates the security principal and returns an OAuth 2.0 token. This token can be used to authorize a request to access a Service Bus resource (queue, topic, and so on).
 
 For more information about authenticating with Azure AD, see the following articles:
 
@@ -20,23 +25,21 @@ For more information about authenticating with Azure AD, see the following artic
 > [Service Bus REST API](/rest/api/servicebus/) supports OAuth authentication with Azure AD.
 
 > [!IMPORTANT]
-> Authorizing users or applications using OAuth 2.0 token returned by Azure AD provides superior security and ease of use over shared access signatures (SAS). With Azure AD, there is no need to store the tokens in your code and risk potential security vulnerabilities. We recommend that you use Azure AD with your Azure Service Bus applications when possible. 
+> Authorizing users or applications using OAuth 2.0 token returned by Azure AD provides superior security and ease of use over shared access signatures (SAS). With Azure AD, there is no need to store tokens in your code and risk potential security vulnerabilities. We recommend that you use Azure AD with your Azure Service Bus applications when possible. 
 > 
 > You can disable local or SAS key authentication for a Service Bus namespace and allow only Azure AD authentication. For step-by-step instructions, see [Disable local authentication](disable-local-authentication.md).
 
 ## Shared access signature
 [SAS authentication](service-bus-sas.md) enables you to grant a user access to Service Bus resources, with specific rights. SAS authentication in Service Bus involves the configuration of a cryptographic key with associated rights on a Service Bus resource. Clients can then gain access to that resource by presenting a SAS token, which consists of the resource URI being accessed and an expiry signed with the configured key.
 
-You can configure keys for SAS on a Service Bus namespace. The key applies to all messaging entities within that namespace. You can also configure keys on Service Bus queues and topics. SAS is also supported on [Azure Relay](../azure-relay/relay-authentication-and-authorization.md).
-
-To use SAS, you can configure a shared access authorization rule on a namespace, queue, or topic. This rule consists of the following elements:
+You can configure keys for SAS on a Service Bus namespace. The key applies to all messaging entities within that namespace. You can also configure keys on Service Bus queues and topics. To use SAS, you can configure a shared access authorization rule on a namespace, queue, or topic. This rule consists of the following elements:
 
-* *KeyName*: identifies the rule.
-* *PrimaryKey*: a cryptographic key used to sign/validate SAS tokens.
-* *SecondaryKey*: a cryptographic key used to sign/validate SAS tokens.
-* *Rights*: represents the collection of **Listen**, **Send**, or **Manage** rights granted.
+* **KeyName**: identifies the rule.
+* **PrimaryKey**: a cryptographic key used to sign/validate SAS tokens.
+* **SecondaryKey**: a cryptographic key used to sign/validate SAS tokens.
+* **Rights**: represents the collection of **Listen**, **Send**, or **Manage** rights granted.
 
-Authorization rules configured at the namespace level can grant access to all entities in a namespace for clients with tokens signed using the corresponding key. You can configure up to 12 such authorization rules on a Service Bus namespace, queue, or topic. By default, a  shared access authorization rule with all rights is configured for every namespace when it's first provisioned.
+Authorization rules configured at the namespace level can grant access to all entities in a namespace for clients with tokens signed using the corresponding key. You can configure up to 12 such authorization rules on a Service Bus namespace, queue, or topic. By default, a shared access authorization rule with all rights is configured for every namespace when it's first provisioned.
 
 To access an entity, the client requires a SAS token generated using a specific shared access authorization rule. The SAS token is generated using the HMAC-SHA256 of a resource string that consists of the resource URI to which access is claimed, and an expiry with a cryptographic key associated with the authorization rule.