Edits in progress

Author: johnmarco

articles/openshift/howto-bring-nsg.md

@@ -12,77 +12,63 @@ keywords: azure, openshift, aro, NSG
 #Customer intent: I need to attach my own Network Security Group to an ARO cluster before beginning cluster installation.
 ---
 
-# Bring your own Network Security Group (NSG) to an ARO cluster
+# Bring your own Network Security Group (NSG) to an Azure Red Hat OpenShift (ARO) cluster
 
-Typically, when setting up an ARO cluster, you must designate a resource group for deploying the ARO cluster object (referred to as the Base Resource Group in the diagram below). In such scenarios, you have the option to use either the same resource group for both the VNET and the cluster, or you can opt for a separate resource group solely for the VNET. Neither of these resource groups directly corresponds to a single ARO cluster, granting you complete control over them. This means you can freely create, modify, or delete resources within these resource groups.
+Typically, when setting up an ARO cluster, you must designate a resource group for deploying the ARO cluster object (referred to as the Base Resource Group in the following diagram). In such scenarios, you can use either the same resource group for both the virtual network (VNET) and the cluster, or you can opt for a separate resource group solely for the VNET. Neither of these resource groups directly corresponds to a single ARO cluster, granting you complete control over them. This means you can freely create, modify, or delete resources within these resource groups.
 
-During the cluster creation process, the ARO Resource Provider (RP) establishes a dedicated resource group specific to the cluster's needs. This group houses various cluster-specific resources like node VMs, load balancers, and Network Security Groups (NSGs), as depicted by the Managed Resource Group in the diagram below. The Managed Resource Group is tightly secured, prohibiting any modifications to its contents, including the NSG linked to the VNET subnets specified during cluster creation. Note that the NSG generated by the ARO RP might not adhere to the security policies of certain organizations.
+During the cluster creation process, the ARO Resource Provider (RP) establishes a dedicated resource group specific to the cluster's needs. This group houses various cluster-specific resources like node VMs, load balancers, and Network Security Groups (NSGs), as depicted by the Managed Resource Group in the diagram below. The Managed Resource Group is tightly secured, prohibiting any modifications to its contents, including the NSG linked to the VNET subnets specified during cluster creation. The NSG generated by the ARO RP might not adhere to the security policies of certain organizations.
 
 :::image type="content" source="media/howto-bring-nsg/network-security-group-old.png" alt-text="Diagram showing an overview of how network security groups work in a typical ARO cluster.":::
 
-In this article you'll learn how to use the "bring your own" Network Security Group (NSG) feature to attach your own NSG residing in the Base/VNET RG (as shown in the diagram below) to the ARO cluster subnets. Since you own this NSG, you'll be able to add/remove rules during the lifetime of the ARO cluster.
-
-:::image type="content" source="media/howto-bring-nsg/network-security-group-new.png" alt-text="Diagram showing an overview of how the bring your own network security group works in Azure Red Hat OpenShift.":::
-
-<!--
-
-Normally, to create an ARO cluster, you need to specify a resource group where the ARO cluster object will be deployed (Base Resource Group in diagram below). In these cases, you can use the same resource group for both the VNET and the cluster, or you can use a dedicated resource group for the VNET. Neither of those resource groups has a 1:1 mapping to an ARO cluster, and you'll have full control over these resource groups (i.e., you can create/modify/delete resources inside those resource groups).
-
-During the cluster creation process, the ARO Resource Provider (RP) creates a cluster-specific resource group used to hold various cluster-specific resources such as node VMs, load balancers, and Network Security Groups (NSGs) (see Managed Resource Group in the diagram below). The Managed Resource Group is locked down; you can't modify any resource inside it, including the NSG that the ARO resource group attaches to the VNET subnets specified during cluster creation. The ARO RP created NSG may not comply with the security policies in some organizations. 
-
-
-and up until now there was no way to modify it to achieve compliance.
-
-:::image type="content" source="media/howto-bring-nsg/network-security-group-overview.png" alt-text="Diagram showing an overview of how network security groups are normally used in Azure Red Hat OpenShift.":::
-
--->
+This article shows how to use the "bring your own" Network Security Group (NSG) feature to attach your own NSG residing in the Base/VNET RG (as shown in the following diagram) to the ARO cluster subnets. Since you own this NSG, you can add/remove rules during the lifetime of the ARO cluster.
 
+:::image type="content" source="media/howto-bring-nsg/network-security-group-new.png" alt-text="Diagram showing an overview of how to bring your own network security group works in Azure Red Hat OpenShift.":::
 
 ## Capabilities and limitations
 
-1. You need to attach your pre-configured NSGs to both master and worker subnets before you create the cluster. Failure to attached your pre-configured NSGs to both subnets will result in an error. 
+1. You need to attach your preconfigured NSGs to both master and worker subnets before you create the cluster. Failure to be attached your preconfigured NSGs to both subnets results in an error. 
 
-1. You can choose to use the same or different pre-configured NSGs for master and worker subnets.
+1. You can choose to use the same or different preconfigured NSGs for master and worker subnets.
 
-1. When using your own NSG, the ARO RP still creates an NSG in the Managed RG (default NSG), but that NSG won't be attached to the worker or master subnets.
+1. When using your own NSG, the ARO RP still creates an NSG in the Managed RG (default NSG), but that NSG isn't attached to the worker or master subnets.
 
-1. Pre-configured NSGs aren't automatically updated with rules when you create Kubernetes LoadBalancer type services or OpenShift routes within the ARO cluster. You'll have to do such rule updates. This behavior is different from the original ARO behavior wherein the default NSG is programmatically updated in such situations.
+1. Preconfigured NSGs aren't automatically updated with rules when you create Kubernetes LoadBalancer type services or OpenShift routes within the ARO cluster. Update these rules. This behavior is different from the original ARO behavior wherein the default NSG is programmatically updated in such situations.
 
 1. The default ARO cluster NSG (not attached to any subnet while using this feature) will still be updated with rules when you create Kubernetes LoadBalancer type services or OpenShift routes within the ARO cluster.
 
-1. You can detach pre-configured NSGs from the subnets of the cluster created using this feature. It will result in a cluster with subnets that have no NSGs. You can then attach a different set of pre-configured NSGs to the cluster. Alternatively, you can attach the ARO default NSG to the cluster subnets (at which point your cluster becomes like any other cluster that's not using this feature).
+1. You can detach preconfigured NSGs from the subnets of the cluster created using this feature. It results in a cluster with subnets that have no NSGs. You can then attach a different set of preconfigured NSGs to the cluster. Alternatively, you can attach the ARO default NSG to the cluster subnets (at which point your cluster becomes like any other cluster that's not using this feature).
 
-1. Your pre-configured NSGs should not have INBOUND/OUTBOUND DENY rules of the following types, as these can interfere with the operation of the cluster and/or hinder the ARO support/SRE teams from providing support/management. (Here, subnet indicates any or all IP addresses in the subnet and all ports corresponding to that subnet):
+1. Your preconfigured NSGs shouldn't have INBOUND/OUTBOUND DENY rules of the following types, as these can interfere with the operation of the cluster and/or hinder the ARO support/SRE teams from providing support/management. (Here, subnet indicates any or all IP addresses in the subnet and all ports corresponding to that subnet):
 
     1. Master Subnet ←→ Master Subnet
     1. Worker Subnet ←→ Worker Subnet
     1. Master Subnet ←→ Worker Subnet
 
-    Misconfigured rules will result in a signal used by Azure Monitor to help troubleshoot pre-configured NSGs.
+    Misconfigured rules result in a [signal used by Azure Monitor](/azure/openshift/howto-monitor-alerts) to help troubleshoot preconfigured NSGs.
 
-1. To allow incoming traffic to your ARO public cluster, you'll need the following INBOUND ALLOW rules (or equivalent) in your NSG. Refer to the default NSG of the cluster for specific details and to the example NSG shown in [Deployment](#deployment). You can create a cluster even without such rules in the NSG.
+1. To allow incoming traffic to your ARO public cluster, set the following INBOUND ALLOW rules (or equivalent) in your NSG. Refer to the default NSG of the cluster for specific details and to the example NSG shown in [Deployment](#deployment). You can create a cluster even without such rules in the NSG.
 
     1. For API server access → From Internet (or your preferred source IPs) to port 6443 on the master subnet.
     1. For access to OpenShift router (and hence to OpenShift console and OpenShift routes) → From Internet (or your preferred source IPs) to ports 80 and 443 on the default-v4 public IP on the public Load-balancer of the cluster.
     1. For access to any Load-balancer type Kubernetes service → From Internet (or your preferred source IPs) to service ports on public IP corresponding to the service on the public Load-balancer of the cluster.
 
-1. You cannot enable the pre-configured NSG feature on an existing ARO cluster. Currently, this feature can only be enabled at the time of cluster creation.
+1. You can't enable the preconfigured NSG feature on an existing ARO cluster. Currently, this feature can only be enabled at the time of cluster creation.
 
-1. The pre-configured NSG option is not configurable from the Azure portal.
+1. The preconfigured NSG option isn't configurable from the Azure portal.
 
-1. If you used this feature during its preview, your existing pre-configured clusters are now fully supported. 
+1. If you used this feature during its preview, your existing preconfigured clusters are now fully supported. 
 
 ## Deployment
 
-### Create VNET and create and configure pre-configured NSG
+### Create VNET and create and configure preconfigured NSG
 
 1. Create a VNET, and then create master and worker subnets within it.
 
-1. Create pre-configured NSG(s) with default rules (or no rules at all) and attach them to the master and worker subnets.
+1. Create preconfigured NSGs with default rules (or no rules at all) and attach them to the master and worker subnets.
 
-### Create an ARO Cluster and Update pre-configured NSG(s)
+### Create an ARO cluster and update preconfigured NSGs
 
-1. Create the cluster:
+1. Create the cluster.
 
     ```
     az aro create \
@@ -96,9 +82,9 @@ and up until now there was no way to modify it to achieve compliance.
     --enable-preconfigured-nsg
     ```
     
-1. Update the pre-configured NSG(s) with rules as per your requirements while also considering the points mentioned in [Capabilities and limitations](#capabilities-and-limitations).
+1. Update the preconfigured NSGs with rules as per your requirements while also considering the points mentioned in [Capabilities and limitations](#capabilities-and-limitations).
 
-    The following example has the Cluster Public Load-balancer as shown in screenshot/CLI output below:
+    The following example has the Cluster Public Load-balancer as shown in the screenshot/CLI output:
     
     :::image type="content" source="media/howto-bring-nsg/ip-configuration-load-balancer.png" alt-text="Screenshot of the cluster's public load balancer as shown with the output from the command.":::