Merge pull request #277206 from jcjiang/patch-1

JamesJBarnett · web-flow · commit 9e81a5f0555c · 2024-06-28T11:47:58.000-07:00
Update scale-app.md
diff --git a/articles/container-apps/managed-identity.md b/articles/container-apps/managed-identity.md
@@ -350,11 +350,16 @@ To get a token for a resource, make an HTTP `GET` request to the endpoint, inclu
 
 ---
 
-## Use managed identity for scale rules
+## <a name="scale-rules"></a>Use managed identity for scale rules
 
-Starting in API version `2024-02-02-preview`, you can use managed identities in your scale rules to authenticate with Azure services that support managed identities. To use a managed identity in your scale rule, use the `identity` property instead of the `auth` property in your scale rule. Acceptable values for the `identity` property are either the Azure resource ID of a user-assigned identity, or `system` to use a system-assigned identity
+You can use managed identities in your scale rules to authenticate with Azure services that support managed identities. To use a managed identity in your scale rule, use the `identity` property instead of the `auth` property in your scale rule. Acceptable values for the `identity` property are either the Azure resource ID of a user-assigned identity, or `system` to use a system-assigned identity.
 
-The following example shows how to use a managed identities with an Azure Queue Storage scale rule. The queue storage account uses the `accountName` property to identify the storage account, while the `identity` property specifies which managed identity to use. You do not need to use the `auth` property.
+> [!NOTE]
+> Managed identity authentication in scale rules is in public preview. It's available in API version `2024-02-02-preview`.
+
+The following ARM template example shows how to use a managed identity with an Azure Queue Storage scale rule:
+
+The queue storage account uses the `accountName` property to identify the storage account, while the `identity` property specifies which managed identity to use. You do not need to use the `auth` property.
 
 ```json
 "scale": {
@@ -371,19 +376,20 @@ The following example shows how to use a managed identities with an Azure Queue
     }]
 }
 ```
+To learn more about using managed identity with scale rules, see [Set scaling rules in Azure Container Apps](scale-app.md?pivots=azure-portal#authentication-2).
 
 ## Control managed identity availability
 
-Container Apps allow you to specify [init containers](containers.md#init-containers) and main containers. By default, both main and init containers in a consumption workload profile environment can use managed identity to access other Azure services. In consumption-only environments and dedicated workload profile environments, only main containers can use managed identity. Managed identity access tokens are available for every managed identity configured on the container app. However, in some situations only the init container or the main container require access tokens for a managed identity. Other times, you may use a managed identity only to access your Azure Container Registry to pull the container image, and your application itself doesn't need to have access to your Azure Container Registry.
+Container Apps allows you to specify [init containers](containers.md#init-containers) and main containers. By default, both main and init containers in a consumption workload profile environment can use managed identity to access other Azure services. In consumption-only environments and dedicated workload profile environments, only main containers can use managed identity. Managed identity access tokens are available for every managed identity configured on the container app. However, in some situations only the init container or the main container require access tokens for a managed identity. Other times, you may use a managed identity only to access your Azure Container Registry to pull the container image, and your application itself doesn't need to have access to your Azure Container Registry.
 
 Starting in API version `2024-02-02-preview`, you can control which managed identities are available to your container app during the init and main phases to follow the security principle of least privilege. The following options are available:
 
-- `Init`: available only to init containers. Use this when you want to perform some intilization work that requires a managed identity, but you no longer need the managed identity in the main container. This option is currently only supported in [workload profile consumption environments](environment.md#types)
-- `Main`: available only to main containers. Use this if your init container does not need managed identity.
-- `All`: available to all containers. This is the default setting.
-- `None`: not available to any containers. Use this when you have a managed identity that is only used for ACR image pull, scale rules, or Key Vault secrets and does not need to be available to the code running in your containers.
+- `Init`: Available only to init containers. Use this when you want to perform some initialization work that requires a managed identity, but you no longer need the managed identity in the main container. This option is currently only supported in [workload profile consumption environments](environment.md#types)
+- `Main`: Available only to main containers. Use this if your init container does not need managed identity.
+- `All`: Available to all containers. This value is the default setting.
+- `None`: Not available to any containers. Use this when you have a managed identity that is only used for ACR image pull, scale rules, or Key Vault secrets and does not need to be available to the code running in your containers.
 
-The following example shows how to configure a container app on a workload profile consumption environment that:
+The following ARM template example shows how to configure a container app on a workload profile consumption environment that:
 
 - Restricts the container app's system-assigned identity to main containers only.
 - Restricts a specific user-assigned identity to init containers only.
@@ -413,15 +419,15 @@ This approach limits the resources that can be accessed if a malicious actor wer
             "identitySettings":[
             {
                 "identity": "ACR_IMAGEPULL_IDENTITY_RESOURCE_ID",
-                "lifecycle": "none"
+                "lifecycle": "None"
             },
             {
                 "identity": "<IDENTITY1_RESOURCE_ID>",
-                "lifecycle": "init"
+                "lifecycle": "Init"
             },
             {
                 "identity": "system",
-                "lifecycle": "main"
+                "lifecycle": "Main"
             }]
         },
         "template": {
diff --git a/articles/container-apps/scale-app.md b/articles/container-apps/scale-app.md
@@ -247,7 +247,7 @@ The following example demonstrates how to create a custom scale rule.
 
 This example shows how to convert an [Azure Service Bus scaler](https://keda.sh/docs/latest/scalers/azure-service-bus/) to a Container Apps scale rule, but you use the same process for any other [ScaledObject](https://keda.sh/docs/latest/concepts/scaling-deployments/)-based [KEDA scaler](https://keda.sh/docs/latest/scalers/) specification.
 
-For authentication, KEDA scaler authentication parameters convert into [Container Apps secrets](manage-secrets.md).
+For authentication, KEDA scaler authentication parameters take [Container Apps secrets](manage-secrets.md) or [managed identity](managed-identity.md#scale-rules).
 
 ::: zone pivot="azure-resource-manager"
 
@@ -319,10 +319,13 @@ First, you define the type and metadata of the scale rule.
 
 ### Authentication
 
-A KEDA scaler supports using secrets in a [TriggerAuthentication](https://keda.sh/docs/latest/concepts/authentication/) that is referenced by the `authenticationRef` property. You can map the TriggerAuthentication object to the Container Apps scale rule.
+Container Apps scale rules support secrets-based authentication. Scale rules for Azure resources, including Azure Queue Storage, Azure Service Bus, and Azure Event Hubs, also support managed identity. Where possible, use managed identity authentication to avoid storing secrets within the app.
 
-> [!NOTE]
-> Container Apps scale rules only support secret references. Other authentication types such as pod identity are not supported.
+#### Use secrets
+
+To use secrets for authentication, you need to create a secret in the container app's `secrets` array. The secret value is used in the `auth` array of the scale rule.
+
+KEDA scalers can use secrets in a [TriggerAuthentication](https://keda.sh/docs/latest/concepts/authentication/) that is referenced by the `authenticationRef` property. You can map the TriggerAuthentication object to the Container Apps scale rule.
 
 1. Find the `TriggerAuthentication` object referenced by the KEDA `ScaledObject` specification.
 
@@ -344,6 +347,33 @@ A KEDA scaler supports using secrets in a [TriggerAuthentication](https://keda.s
 
     Refer to the [considerations section](#considerations) for more security related information.
 
+#### Using managed identity
+
+Container Apps scale rules can use managed identity to authenticate with Azure services. The following ARM template passes in system-based managed identity to authenticate for an Azure Queue scaler.
+
+```
+"scale": {
+  "minReplicas": 0,
+  "maxReplicas": 4,
+  "rules": [
+    {
+      "name": "azure-queue",
+      "custom": {
+        "type": "azure-queue",
+        "metadata": {
+          "accountName": "apptest123",
+          "queueName": "queue1",
+          "queueLength": "1"
+        },
+        "identity": "system"
+      }
+    }
+  ]
+}
+```
+
+To learn more about using managed identity with scale rules, see [Managed identity](managed-identity.md#scale-rules).
+
 ::: zone-end
 
 ::: zone pivot="azure-cli"
@@ -368,10 +398,13 @@ A KEDA scaler supports using secrets in a [TriggerAuthentication](https://keda.s
 
 ### Authentication
 
-A KEDA scaler supports using secrets in a [TriggerAuthentication](https://keda.sh/docs/latest/concepts/authentication/) that is referenced by the authenticationRef property. You can map the TriggerAuthentication object to the Container Apps scale rule.
+Container Apps scale rules support secrets-based authentication. Scale rules for Azure resources, including Azure Queue Storage, Azure Service Bus, and Azure Event Hubs, also support managed identity. Where possible, use managed identity authentication to avoid storing secrets within the app.
 
-> [!NOTE]
-> Container Apps scale rules only support secret references. Other authentication types such as pod identity are not supported.
+#### Use secrets
+
+To configure secrets-based authentication for a Container Apps scale rule, you configure the secrets in the container app and reference them in the scale rule.
+
+A KEDA scaler supports secrets in a [TriggerAuthentication](https://keda.sh/docs/latest/concepts/authentication/) which the `authenticationRef` property uses for reference. You can map the `TriggerAuthentication` object to the Container Apps scale rule.
 
 1. Find the `TriggerAuthentication` object referenced by the KEDA `ScaledObject` specification. Identify each `secretTargetRef` of the `TriggerAuthentication` object.
 
@@ -386,6 +419,24 @@ A KEDA scaler supports using secrets in a [TriggerAuthentication](https://keda.s
     1. Create an authentication entry with the `--scale-rule-auth` parameter. If there are multiple entries, separate them with a space.
 
     :::code language="bash" source="~/azure-docs-snippets-pr/container-apps/container-apps-azure-service-bus-cli.bash" highlight="8,14":::
+   
+#### Using managed identity
+
+Container Apps scale rules can use managed identity to authenticate with Azure services. The following command creates a container app with a user-assigned managed identity and uses it to authenticate for an Azure Queue scaler.
+
+```bash
+az containerapp create \
+  --resource-group <RESOURCE_GROUP> \
+  --name <APP_NAME> \
+  --environment <ENVIRONMENT_ID> \
+  --user-assigned <USER_ASSIGNED_IDENTITY_ID> \
+  --scale-rule-name azure-queue \
+  --scale-rule-type azure-queue \
+  --scale-rule-metadata "accountName=<AZURE_STORAGE_ACCOUNT_NAME>" "queueName=queue1" "queueLength=1" \
+  --scale-rule-identity <USER_ASSIGNED_IDENTITY_ID>
+```
+
+Replace placeholders with your values.
 
 ::: zone-end
 
@@ -423,10 +474,9 @@ A KEDA scaler supports using secrets in a [TriggerAuthentication](https://keda.s
 
 ### Authentication
 
-A KEDA scaler supports using secrets in a [TriggerAuthentication](https://keda.sh/docs/latest/concepts/authentication/) that is referenced by the authenticationRef property. You can map the TriggerAuthentication object to the Container Apps scale rule.
+Container Apps scale rules support secrets-based authentication. Scale rules for Azure resources, including Azure Queue Storage, Azure Service Bus, and Azure Event Hubs, also support managed identity. Where possible, use managed identity authentication to avoid storing secrets within the app.
 
-> [!NOTE]
-> Container Apps scale rules only support secret references. Other authentication types such as pod identity are not supported.
+#### Use secrets
 
 1. In your container app, create the [secrets](./manage-secrets.md) that you want to reference.
 
@@ -436,6 +486,10 @@ A KEDA scaler supports using secrets in a [TriggerAuthentication](https://keda.s
 
 1. In the *Authentication* section, select **Add** to create an entry for each KEDA `secretTargetRef` parameter.
 
+#### Using managed identity
+
+Managed identity authentication is not supported in the Azure portal. Use the [Azure CLI](scale-app.md?pivots=azure-cli#authentication) or [Azure Resource Manager](scale-app.md?&pivots=azure-resource-manager#authentication) to authenticate using managed identity.
+
 ::: zone-end
 
 ## Default scale rule
