made additional changes

content/rosa/entra-external-auth/index.md

@@ -20,7 +20,7 @@ You must configure your ROSA cluster with external authentication enabled at clu
 ## Prerequisites
 * [A ROSA with HCP cluster with external authentication enabled](https://docs.openshift.com/rosa/rosa_hcp/rosa-hcp-sts-creating-a-cluster-ext-auth.html)
 * [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html)
-* [OpenShift CLI](https://mirror.openshift.com/pub/openshift-v4/clients/ocp/)
+* [OpenShift Command Line Interface (CLI)](https://mirror.openshift.com/pub/openshift-v4/clients/ocp/)
 * [jq](https://stedolan.github.io/jq/download/)
 
 ## Deploy a ROSA HCP cluster with External Authentication
@@ -138,7 +138,7 @@ CLIENT_SECRET=<entra-client_secret_value>
 TENANT_ID=<entra-tenant_id>
 ROSA_CLUSTER_NAME=<cluster-name>
 API_URL=$(rosa describe cluster --cluster ${ROSA_CLUSTER_NAME} -o json | jq -r '.api.url')
-
+```
 ### Create an external authentication provider in ROSA 
 
 ```bash
@@ -151,14 +151,14 @@ To verify your external authentication provider, run the following command:
 
 ```bash
 rosa describe external-auth-provider -c ${ROSA_CLUSTER_NAME} --name ${IDP_NAME}
+```
 ### Creating a break glass credential to access the ROSA cluster
 
 One of the key differences between a cluster which has external authentication enabled and a cluster that doesn't is that there is no internal OAuth server to act as a separate identity provider. This means that there cannot be a standalone or pre-created cluster-admin account.  Instead, a temporary kubeconfig with cluster-admin privileges, which we refer to as a break glass credential, can be generated and used to access the ROSA cluster. Credentials are only valid for a maximum of 24 hours and are intended only to provide temporary elevated permissions into the cluster.
 
 By using break glass credentials, cluster administrators can securely set up and manage role-based access control (RBAC) for their ROSA with HCP clusters, ensuring proper authentication and authorization mechanisms are in place before regular users access the cluster. During initial setup, Break glass credentials are crucial for applying the ClusterRoleBinding that maps external identity provider groups to cluster roles
 
 Create a new break glass credential by executing the following command:
-. 
 
 ```bash
 rosa create break-glass-credential -c ${ROSA_CLUSTER_NAME} --username=breakglass
@@ -176,9 +176,7 @@ Save the kubeconfig file that will allow you to log into the cluster with the br
 ```bash
 rosa describe break-glass-credential <BREAK_GLASS_CREDENTIAL_ID> -c ${ROSA_CLUSTER_NAME} --kubeconfig > rosa-cluster.kubeconfig
 ```
-Validate that rosa-cluster.kubeconfig is populated
-
-Your file should look like this:
+Validate that rosa-cluster.kubeconfig is populated. Your file should look like this:
 
 ```
 apiVersion: v1
@@ -204,9 +202,11 @@ users:
     XXXXXXXXXXXXXXXXXXXXXX
 ```
 
-Set the KUBECONFIG environment variable to the location of the rosa-cluster.kubeconfig file which will enable the OpenShift Command Line Interface to authenticate against the ROSA cluster with the contents of the file.. 
+Set the `KUBECONFIG` environment variable to the location of the `rosa-cluster.kubeconfig` file which will enable the OpenShift CLI to authenticate against the ROSA cluster with the contents of the file.. 
 
+```bash
 export KUBECONFIG=$(pwd)/rosa-cluster.kubeconfig
+```
 
 Confirm you can access the cluster by running the following command:
 
@@ -302,7 +302,7 @@ rosa describe cluster -c ${ROSA_CLUSTER_NAME} -o json | jq -r '.console.url'
 Open this URL and your external authentication provider should open.
 
 ### Validate access to the cluster's API
-Here we will be leveraging a client-go Credential Plugin to automate the interaction between the OpenShift Command Line Interface and the External Authentication Provider including the management of OIDC tokens.
+Here we will be leveraging a client-go Credential Plugin to automate the interaction between the OpenShift CLI and the External Authentication Provider including the management of OIDC tokens.
 
 More information related to Kubernetes plugins can be found [here](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/).
 
@@ -340,9 +340,9 @@ users:
       env: null
       interactiveMode: Never
 ```
-Set the KUBECONFIG environment variable to the location of the rosa-cluster.kubeconfig file which will enable the OpenShift Command Line Interface to authenticate against the ROSA cluster with the contents of the file.. 
+Set the KUBECONFIG environment variable to the location of the rosa-cluster.kubeconfig file which will enable the OpenShift CLI to authenticate against the ROSA cluster with the contents of the file.
 
-To confirm that the identity details from the OIDC token is being used by the OpenShift Command Line Interface:
+To confirm that the identity details from the OIDC token is being used by the OpenShift CLI:
 
 ```bash
 export KUBECONFIG=$(pwd)/rosa-auth.kubeconfig
@@ -368,13 +368,15 @@ oc auth whoami
 ```
 ### Validate access to the cluster's API using device-code authentication 
 
-Note: This option is only used when the client machine lacks keyring. 
+Note: Using device-code authentication is when you are authenticating from somewhere that doesn't have a web browser. The --token-cache-storage=disk parameter is used when a client machine lacks keyring. 
 
 Click on the "Authentication" on your Entra ID and Enable Public flows in Advanced section of the page
 
 ![Azure Portal - Enable Public flows Authentication Page](./images/azure-portal-allow-public-flows.png)
 
-Create a KUBECONFIG file here with EntraID details for example create **rosa-auth-headless.kubeconfig** file with following information
+Generate a KUBECONFIG File with Entra ID Details
+
+Create a **rosa-auth-headless.kubeconfig** file containing Entra ID authentication details and cluster API.
 
 ```bash
 apiVersion: v1
@@ -411,9 +413,9 @@ users:
       env: null
       interactiveMode: Never
 ```
-Set the KUBECONFIG environment variable to the location of the rosa-cluster.kubeconfig file which will enable the OpenShift CLI to authenticate against the ROSA cluster with the contents of the file.
+Set the `KUBECONFIG` environment variable to the location of the `rosa-cluster.kubeconfig` file which will enable the OpenShift CLI to authenticate against the ROSA cluster with the contents of the file.
 
-To confirm that the identity details from the OIDC token is being used by the OpenShift Command Line Interface:
+To confirm that the identity details from the OIDC token is being used by the OpenShift CLI:
 
 ```bash
 export KUBECONFIG=$(pwd)/rosa-auth-headless.kubeconfig
@@ -452,16 +454,4 @@ Groups      [0000000000000000 system:authenticated]
 ```
 
 ### Revoke break glass credential
-Upon completion of any activities that require elevated access to the ROSA cluster (such as the management of RBAC policies) using a break glass credential, all remnants of its use should be removed. Proper removal ensures that no unexpected actions are performed using these privileged credentials. 
-There are two locations where the management of this credential should be performed:
-ROSA Cluster
-kubeconfig file
-
-Delete the kubeconfig file
-rm $KUBECONFIG
-
-A break glass credential can be removed from a ROSA cluster using the `rosa revoke break-glass-credentials` command. Execute the following command to revoke the break glass credential associated with a ROSA cluster.
-
-```bash
-rosa revoke break-glass-credentials -c ${ROSA_CLUSTER_NAME}
-```
+Revoking break-glass credentials in OpenShift is crucial for security and compliance. These credentials are typically highly privileged, providing full administrative access to the cluster. Upon setting up external authentication with cluster administrator credentials, the break-glass credential should be revoked. Refer to [documentation](https://docs.openshift.com/rosa/rosa_hcp/rosa-hcp-sts-creating-a-cluster-ext-auth.html?utm_source=chatgpt.com#rosa-hcp-sts-revoking-a-break-glass-cred-cli_rosa-hcp-sts-creating-a-cluster-ext-auth) on revoking break-glass credential