Merge pull request #286495 from pauljewellmsft/queue-refresh

Update queue articles - Acrolinx

Author: prmerger-automator[bot]

articles/storage/queues/client-side-encryption.md

@@ -7,7 +7,7 @@ author: pauljewellmsft
 
 ms.service: azure-queue-storage
 ms.topic: article
-ms.date: 07/11/2022
+ms.date: 09/10/2024
 ms.author: pauljewell
 ms.reviewer: ozgun
 ms.custom: devx-track-csharp
@@ -38,7 +38,7 @@ Due to a security vulnerability discovered in the Queue Storage client library's
 
 - If you need to use client-side encryption, then migrate your applications from client-side encryption v1 to 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:
+The following table summarizes the steps you need to take if you choose to migrate your applications to client-side encryption v2:
 
 | Client-side encryption status | Recommended actions |
 |---|---|
@@ -59,7 +59,7 @@ The following table shows which versions of the client libraries for .NET and Py
 | **Client-side encryption v2 and v1** | [Versions 12.11.0 and later](https://www.nuget.org/packages/Azure.Storage.Queues) | [Versions 12.4.0 and later](https://pypi.org/project/azure-storage-queue) |
 | **Client-side encryption v1 only** | Versions 12.10.0 and earlier | Versions 12.3.0 and earlier |
 
-If your application is using client-side encryption with an earlier version of the .NET or Python client library, you must first upgrade your code to a version that supports client-side encryption v2. Next, you must decrypt and re-encrypt your data with client-side encryption v2. If necessary, you can use a version of the client library that supports client-side encryption v2 side-by-side with an earlier version of the client library while you are migrating your code.
+If your application is using client-side encryption with an earlier version of the .NET or Python client library, you must first upgrade your code to a version that supports client-side encryption v2. Next, you must decrypt and re-encrypt your data with client-side encryption v2. If necessary, you can use a version of the client library that supports client-side encryption v2 side-by-side with an earlier version of the client library while you're migrating your code.
 
 ## How client-side encryption works
 
@@ -90,15 +90,15 @@ Decryption via the envelope technique works as follows:
 
 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.
+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 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.
+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 64 KB limit for a queue message, the impact should be manageable. The encrypted message is Base64-encoded, as shown in the above snippet, which expands 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.
+Due to the short-lived nature of messages in the queue, decrypting and reencrypting queue messages after updating to client-side encryption v2 shouldn't be necessary. Any less secure messages are rotated in the course of normal queue consumption.
 
 ## Client-side encryption and performance
 

articles/storage/queues/queues-auth-abac-examples.md

@@ -1,7 +1,7 @@
 ---
-title: Example Azure role assignment conditions for Queue Storage
+title: Examples for Azure role assignment conditions for Queue Storage
 titleSuffix: Azure Storage
-description: Example Azure role assignment conditions for Queue Storage.
+description: Example role assignment conditions and Azure attribute-based access control (Azure ABAC) for Azure Queue Storage.
 author: pauljewellmsft
 
 ms.service: azure-queue-storage
@@ -47,7 +47,7 @@ This condition allows users to peek or clear messages in a queue named **sample-
 
 ![Diagram of condition showing peek and clear access to named queue.](./media/queues-auth-abac-examples/peek-clear-messages-named-queue.png)
 
-The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the **Visual editor** tab and the **Code editor** tabs below to view the examples for your preferred portal editor.
+The condition can be added to a role assignment using either the Azure portal or Azure PowerShell. The portal has two tools for building ABAC conditions - the visual editor and the code editor. You can switch between the two editors in the Azure portal to see your conditions in different views. Switch between the **Visual editor** tab and the **Code editor** tabs in this article to view the examples for your preferred portal editor.
 
 # [Portal: Visual editor](#tab/portal-visual-editor)
 
@@ -68,7 +68,7 @@ Use the values in the following table to build the expression portion of the con
 | Operator | [StringEquals](../../role-based-access-control/conditions-format.md#stringequals) |
 | Value | {queueName} |
 
-The following image shows the condition after the settings have been entered into the Azure portal. Note that you must group expressions to ensure correct evaluation.
+The following image shows the condition after the settings are entered into the Azure portal. You must group expressions to ensure correct evaluation.
 
 :::image type="content" source="./media/queues-auth-abac-examples/peek-clear-messages-portal.png" alt-text="Screenshot of condition editor in Azure portal showing peek or clear access to messages in a named queue." lightbox="./media/queues-auth-abac-examples/peek-clear-messages-portal.png":::
 
@@ -150,7 +150,7 @@ Use the values in the following table to build the expression portion of the con
 | Operator | [DateTimeGreaterThan](../../role-based-access-control/conditions-format.md#datetime-comparison-operators) |
 | Value | `2023-05-01T13:00:00.000Z` |
 
-The following image shows the condition after the settings have been entered into the Azure portal. Note that you must group expressions to ensure correct evaluation.
+The following image shows the condition after the settings are entered into the Azure portal. You must group expressions to ensure correct evaluation.
 
 :::image type="content" source="./media/queues-auth-abac-examples/environment-utcnow-queue-peek-portal.png" alt-text="Screenshot of the condition editor in the Azure portal showing peek access allowed after a specific date and time." lightbox="./media/queues-auth-abac-examples/environment-utcnow-queue-peek-portal.png":::
 
@@ -242,7 +242,7 @@ Use the values in the following table to build the expression portion of the con
 | Operator | [StringEqualsIgnoreCase](../../role-based-access-control/conditions-format.md#stringequals) |
 | Value | `/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/sample-vnet/subnets/default` |
 
-The following image shows the condition after the settings have been entered into the Azure portal. Note that you must group expressions to ensure correct evaluation.
+The following image shows the condition after the settings are entered into the Azure portal. You must group expressions to ensure correct evaluation.
 
 :::image type="content" source="./media/queues-auth-abac-examples/environment-subnet-queue-put-update-portal.png" alt-text="Screenshot of the condition editor in the Azure portal showing read access to specific queues allowed from a specific subnet." lightbox="./media/queues-auth-abac-examples/environment-subnet-queue-put-update-portal.png":::