Merge pull request #75397 from jeana-redhat/OSDOCS-10415-Azure-AD-Microsoft-Entra-WID

jeana-redhat · web-flow · commit 5f14dc63872e · 2024-05-16T09:55:36.000-04:00
OSDOCS-10415: update Azure AD to Entra branding
diff --git a/_attributes/common-attributes.adoc b/_attributes/common-attributes.adoc
@@ -25,14 +25,6 @@ ifdef::openshift-origin[]
 endif::[]
 :tsb-name: Template Service Broker
 :kebab: image:kebab.png[title="Options menu"]
-ifndef::openshift-origin[]
-:rh-openstack-first: Red Hat OpenStack Platform (RHOSP)
-:rh-openstack: RHOSP
-endif::openshift-origin[]
-ifdef::openshift-origin[]
-:rh-openstack-first: OpenStack
-:rh-openstack: OpenStack
-endif::openshift-origin[]
 :ai-full: Assisted Installer
 :cluster-manager-first: Red Hat OpenShift Cluster Manager
 :cluster-manager: OpenShift Cluster Manager
@@ -224,21 +216,33 @@ endif::[]
 :devworkspace-op: DevWorkspace Operator
 :secrets-store-driver: Secrets Store CSI driver
 :secrets-store-operator: Secrets Store CSI Driver Operator
-//AWS STS
-:sts-first: Security Token Service (STS)
-:sts-full: Security Token Service
-:sts-short: STS
-//Cloud provider names
-//AWS
+// Cluster Observability Operator
+:coo-first: Cluster Observability Operator (COO)
+:coo-full: Cluster Observability Operator
+:coo-short: COO
+//ODF
+:odf-first: Red Hat OpenShift Data Foundation (ODF)
+:odf-full: Red Hat OpenShift Data Foundation
+:odf-short: ODF
+:rh-dev-hub: Red Hat Developer Hub
+//IBU
+:lcao: Lifecycle Agent
+
+
+
+
+
+// Cloud provider names
+// Alibaba Cloud
+:alibaba: Alibaba Cloud
+// Amazon Web Services (AWS)
 :aws-first: Amazon Web Services (AWS)
 :aws-full: Amazon Web Services
 :aws-short: AWS
-//GCP
+// Google Cloud Platform (GCP)
 :gcp-first: Google Cloud Platform (GCP)
 :gcp-full: Google Cloud Platform
 :gcp-short: GCP
-//alibaba cloud
-:alibaba: Alibaba Cloud
 // IBM general
 :ibm-name: IBM(R)
 :ibm-title: IBM
@@ -258,15 +262,10 @@ endif::[]
 :ibm-z-title: IBM Z
 :ibm-linuxone-name: IBM(R) LinuxONE
 :ibm-linuxone-title: IBM LinuxONE
-//Azure
+// Microsoft Azure
 :azure-first: Microsoft Azure
 :azure-full: Microsoft Azure
 :azure-short: Azure
-:azure-id: Azure AD Workload Identity
-//vSphere
-:vmw-first: VMware vSphere
-:vmw-full: VMware vSphere
-:vmw-short: vSphere
 //Oracle
 :oci-first: Oracle(R) Cloud Infrastructure (OCI)
 :oci-first-no-rt: Oracle Cloud Infrastructure (OCI)
@@ -279,17 +278,29 @@ endif::[]
 :ocid: OCID
 :ocvs-first: Oracle(R) Cloud VMware Solution (OCVS)
 :ocvs: OCVS
-// Cluster Observability Operator
-:coo-first: Cluster Observability Operator (COO)
-:coo-full: Cluster Observability Operator
-:coo-short: COO
-//ODF
-:odf-first: Red Hat OpenShift Data Foundation (ODF)
-:odf-full: Red Hat OpenShift Data Foundation
-:odf-short: ODF
-:rh-dev-hub: Red Hat Developer Hub
-//IBU
-:lcao: Lifecycle Agent
+// Red Hat OpenStack Platform (RHOSP)/OpenStack
+ifndef::openshift-origin[]
+:rh-openstack-first: Red Hat OpenStack Platform (RHOSP)
+:rh-openstack: RHOSP
+endif::openshift-origin[]
+ifdef::openshift-origin[]
+:rh-openstack-first: OpenStack
+:rh-openstack: OpenStack
+endif::openshift-origin[]
+// VMware vSphere
+:vmw-first: VMware vSphere
+:vmw-full: VMware vSphere
+:vmw-short: vSphere
+
+
+//Token-based auth products
+//AWS Security Token Service
+:sts-first: Security Token Service (STS)
+:sts-full: Security Token Service
+:sts-short: STS
+//Microsoft Entra Workload ID (FKA Azure Active Directory Workload Identities)
+:entra-first: Microsoft Entra Workload ID
+:entra-short: Workload ID
 
 
 // Cluster API Providers
diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
@@ -1945,7 +1945,7 @@ Topics:
       File: osdk-token-auth
     - Name: CCO-based workflow for OLM-managed Operators with AWS STS
       File: osdk-cco-aws-sts
-    - Name: CCO-based workflow for OLM-managed Operators with Azure AD Workload Identity
+    - Name: CCO-based workflow for OLM-managed Operators with Microsoft Entra Workload ID
       File: osdk-cco-azure
   - Name: Validating Operators using the scorecard
     File: osdk-scorecard
diff --git a/authentication/managing_cloud_provider_credentials/cco-short-term-creds.adoc b/authentication/managing_cloud_provider_credentials/cco-short-term-creds.adoc
@@ -28,7 +28,7 @@ Cloud providers use different terms for their implementation of this authenticat
 |GCP Workload Identity
 
 |Global Microsoft Azure
-|Azure AD Workload Identity
+|{entra-first}
 
 |====
 
@@ -76,15 +76,15 @@ include::modules/cco-short-term-creds-format-gcp.adoc[leveloffset=+2]
 //include::modules/cco-short-term-creds-component-permissions-gcp.adoc[leveloffset=+2]
 
 [id="cco-short-term-creds-azure_{context}"]
-== Azure AD Workload Identity
+== {entra-first}
 
-In manual mode with Azure AD Workload Identity, the individual {product-title} cluster components use the Azure AD workload identity provider to assign components short-term security credentials.
+In manual mode with {entra-first}, the individual {product-title} cluster components use the {entra-short} provider to assign components short-term security credentials.
 
 [role="_additional-resources"]
 .Additional resources
 * xref:../../installing/installing_azure/installing-azure-customizations.adoc#installing-azure-with-short-term-creds_installing-azure-customizations[Configuring a global Microsoft Azure cluster to use short-term credentials]
 
-//Azure AD Workload Identity authentication process
+//Microsoft Entra Workload ID authentication process
 include::modules/cco-short-term-creds-auth-flow-azure.adoc[leveloffset=+2]
 
 //Azure component secret formats
@@ -93,12 +93,12 @@ include::modules/cco-short-term-creds-format-azure.adoc[leveloffset=+2]
 //Azure component secret permissions requirements
 include::modules/cco-short-term-creds-component-permissions-azure.adoc[leveloffset=+2]
 
-//OLM-managed Operator support for authentication with Azure AD Workload Identity
+//OLM-managed Operator support for authentication with Microsoft Entra Workload ID
 include::modules/cco-short-term-creds-azure-olm.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
-* xref:../../operators/operator_sdk/token_auth/osdk-cco-azure.adoc#osdk-cco-azure[CCO-based workflow for OLM-managed Operators with {azure-id}]
+* xref:../../operators/operator_sdk/token_auth/osdk-cco-azure.adoc#osdk-cco-azure[CCO-based workflow for OLM-managed Operators with {entra-first}]
 
 [role="_additional-resources"]
 [id="additional-resources_{context}"]
diff --git a/installing/installing_azure/installing-azure-customizations.adoc b/installing/installing_azure/installing-azure-customizations.adoc
@@ -80,7 +80,7 @@ include::modules/manually-create-identity-access-management.adoc[leveloffset=+2]
 [id="installing-azure-with-short-term-creds_{context}"]
 === Configuring an Azure cluster to use short-term credentials
 
-To install a cluster that uses Azure AD Workload Identity, you must configure the Cloud Credential Operator utility and create the required Azure resources for your cluster.
+To install a cluster that uses {entra-first}, you must configure the Cloud Credential Operator utility and create the required Azure resources for your cluster.
 
 //Task part 1: Configuring the Cloud Credential Operator utility
 include::modules/cco-ccoctl-configuring.adoc[leveloffset=+3]
diff --git a/installing/installing_azure/installing-azure-network-customizations.adoc b/installing/installing_azure/installing-azure-network-customizations.adoc
@@ -90,7 +90,7 @@ include::modules/manually-create-identity-access-management.adoc[leveloffset=+2]
 [id="installing-azure-with-short-term-creds_{context}"]
 === Configuring an Azure cluster to use short-term credentials
 
-To install a cluster that uses Azure AD Workload Identity, you must configure the Cloud Credential Operator utility and create the required Azure resources for your cluster.
+To install a cluster that uses {entra-first}, you must configure the Cloud Credential Operator utility and create the required Azure resources for your cluster.
 
 //Task part 1: Configuring the Cloud Credential Operator utility
 include::modules/cco-ccoctl-configuring.adoc[leveloffset=+3]
diff --git a/installing/installing_azure/installing-azure-private.adoc b/installing/installing_azure/installing-azure-private.adoc
@@ -78,7 +78,7 @@ include::modules/manually-create-identity-access-management.adoc[leveloffset=+2]
 [id="installing-azure-with-short-term-creds_{context}"]
 === Configuring an Azure cluster to use short-term credentials
 
-To install a cluster that uses Azure AD Workload Identity, you must configure the Cloud Credential Operator utility and create the required Azure resources for your cluster.
+To install a cluster that uses {entra-first}, you must configure the Cloud Credential Operator utility and create the required Azure resources for your cluster.
 
 //Task part 1: Configuring the Cloud Credential Operator utility
 include::modules/cco-ccoctl-configuring.adoc[leveloffset=+3]
diff --git a/installing/installing_azure/installing-azure-vnet.adoc b/installing/installing_azure/installing-azure-vnet.adoc
@@ -72,7 +72,7 @@ include::modules/manually-create-identity-access-management.adoc[leveloffset=+2]
 [id="installing-azure-with-short-term-creds_{context}"]
 === Configuring an Azure cluster to use short-term credentials
 
-To install a cluster that uses Azure AD Workload Identity, you must configure the Cloud Credential Operator utility and create the required Azure resources for your cluster.
+To install a cluster that uses {entra-first}, you must configure the Cloud Credential Operator utility and create the required Azure resources for your cluster.
 
 //Task part 1: Configuring the Cloud Credential Operator utility
 include::modules/cco-ccoctl-configuring.adoc[leveloffset=+3]
diff --git a/installing/installing_azure/installing-restricted-networks-azure-installer-provisioned.adoc b/installing/installing_azure/installing-restricted-networks-azure-installer-provisioned.adoc
@@ -79,7 +79,7 @@ include::modules/manually-create-identity-access-management.adoc[leveloffset=+2]
 [id="installing-azure-with-short-term-creds_{context}"]
 === Configuring an Azure cluster to use short-term credentials
 
-To install a cluster that uses Azure AD Workload Identity, you must configure the Cloud Credential Operator utility and create the required Azure resources for your cluster.
+To install a cluster that uses {entra-first}, you must configure the Cloud Credential Operator utility and create the required Azure resources for your cluster.
 
 //Task part 1: Configuring the Cloud Credential Operator utility
 include::modules/cco-ccoctl-configuring.adoc[leveloffset=+3]
diff --git a/modules/cco-ccoctl-creating-at-once.adoc b/modules/cco-ccoctl-creating-at-once.adoc
@@ -400,7 +400,7 @@ openshift-ingress-operator-cloud-credentials-credentials.yaml
 openshift-machine-api-azure-cloud-credentials-credentials.yaml
 ----
 +
-You can verify that the Azure AD service accounts are created by querying Azure. For more information, refer to Azure documentation on listing AD service accounts.
+You can verify that the Microsoft Entra ID service accounts are created by querying Azure. For more information, refer to Azure documentation on listing Entra ID service accounts.
 endif::azure-workload-id[]
 
 //Platforms that must use `ccoctl`
diff --git a/modules/cco-determine-mode-cli.adoc b/modules/cco-determine-mode-cli.adoc
@@ -57,7 +57,7 @@ ifdef::update[]
 If the cluster is specifically configured to use mint mode or uses mint mode by default, you must determine if the root secret is present on the cluster before updating.
 endif::update[]
 
-An AWS, GCP, or global Microsoft Azure cluster that uses manual mode might be configured to create and manage cloud credentials from outside of the cluster with AWS STS, GCP Workload Identity, or Azure AD Workload Identity. You can determine whether your cluster uses this strategy by examining the cluster `Authentication` object.
+An AWS, GCP, or global Microsoft Azure cluster that uses manual mode might be configured to create and manage cloud credentials from outside of the cluster with AWS STS, GCP Workload Identity, or {entra-first}. You can determine whether your cluster uses this strategy by examining the cluster `Authentication` object.
 ====
 
 ifdef::about-cco[]
diff --git a/modules/cco-determine-mode-gui.adoc b/modules/cco-determine-mode-gui.adoc
@@ -56,7 +56,7 @@ ifdef::update[]
 If the cluster is specifically configured to use mint mode or uses mint mode by default, you must determine if the root secret is present on the cluster before updating.
 endif::update[]
 
-An AWS, GCP, or global Microsoft Azure cluster that uses manual mode might be configured to create and manage cloud credentials from outside of the cluster with AWS STS, GCP Workload Identity, or Azure AD Workload Identity. You can determine whether your cluster uses this strategy by examining the cluster `Authentication` object.
+An AWS, GCP, or global Microsoft Azure cluster that uses manual mode might be configured to create and manage cloud credentials from outside of the cluster with AWS STS, GCP Workload Identity, or {entra-first}. You can determine whether your cluster uses this strategy by examining the cluster `Authentication` object.
 ====
 
 ifdef::about-cco[]
diff --git a/modules/cco-short-term-creds-auth-flow-azure.adoc b/modules/cco-short-term-creds-auth-flow-azure.adoc
@@ -4,9 +4,9 @@
 
 :_mod-docs-content-type: REFERENCE
 [id="cco-short-term-creds-auth-flow-azure_{context}"]
-= Azure AD Workload Identity authentication process
+= {entra-first} authentication process
 
-The following diagram details the authentication flow between Azure and the {product-title} cluster when using Azure AD Workload Identity.
+The following diagram details the authentication flow between Azure and the {product-title} cluster when using {entra-first}.
 
-.Azure AD Workload Identity authentication flow
-image::347_OpenShift_credentials_with_STS_updates_1023_Azure.png[Detailed authentication flow between Azure and the cluster when using Azure AD Workload Identity]
+.{entra-short} authentication flow
+image::347_OpenShift_credentials_with_STS_updates_1023_Azure.png[Detailed authentication flow between Azure and the cluster when using {entra-short}]
diff --git a/modules/cco-short-term-creds-azure-olm.adoc b/modules/cco-short-term-creds-azure-olm.adoc
@@ -4,6 +4,6 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="cco-short-term-creds-azure-olm_{context}"]
-= OLM-managed Operator support for authentication with Azure AD Workload Identity
+= OLM-managed Operator support for authentication with {entra-first}
 
-In addition to {product-title} cluster components, some Operators managed by the Operator Lifecycle Manager (OLM) on Azure clusters can use manual mode with Azure AD Workload Identity. These Operators authenticate with short-term credentials that are managed outside the cluster. To determine if an Operator supports authentication with Azure AD Workload Identity, see the Operator description in OperatorHub.
+In addition to {product-title} cluster components, some Operators managed by the Operator Lifecycle Manager (OLM) on Azure clusters can use manual mode with {entra-first}. These Operators authenticate with short-term credentials that are managed outside the cluster. To determine if an Operator supports authentication with {entra-short}, see the Operator description in OperatorHub.
diff --git a/modules/cco-short-term-creds-format-azure.adoc b/modules/cco-short-term-creds-format-azure.adoc
@@ -6,7 +6,7 @@
 [id="cco-short-term-creds-format-azure_{context}"]
 = Azure component secret formats
 
-Using manual mode with AD Workload Identity changes the content of the Azure credentials that are provided to individual {product-title} components. Compare the following secret formats:
+Using manual mode with {entra-first} changes the content of the Azure credentials that are provided to individual {product-title} components. Compare the following secret formats:
 
 .Azure secret format using long-term credentials
 
@@ -29,12 +29,12 @@ type: Opaque
 ----
 <1> The namespace for the component.
 <2> The name of the component secret.
-<3> The client ID of the Azure AD identity that the component uses to authenticate.
-<4> The component secret that is used to authenticate with Azure AD for the `<client_id>` identity.
+<3> The client ID of the Microsoft Entra ID identity that the component uses to authenticate.
+<4> The component secret that is used to authenticate with Microsoft Entra ID for the `<client_id>` identity.
 <5> The resource group prefix.
 <6> The resource group. This value is formed by the `<resource_group_prefix>` and the suffix `-rg`.
 
-.Azure secret format using AD Workload Identity
+.Azure secret format using {entra-first}
 
 [source,yaml]
 ----
diff --git a/modules/cert-manager-acme-dns-providers.adoc b/modules/cert-manager-acme-dns-providers.adoc
@@ -13,7 +13,7 @@ The {cert-manager-operator} supports the following DNS-01 providers for ACME iss
 +
 [NOTE]
 ====
-The {cert-manager-operator} does not support using Azure Active Directory (Azure AD) pod identities to assign a managed identity to a pod.
+The {cert-manager-operator} does not support using Microsoft Entra ID pod identities to assign a managed identity to a pod.
 ====
 * Google Cloud DNS
 * Webhook
diff --git a/modules/installation-azure-permissions.adoc b/modules/installation-azure-permissions.adoc
@@ -12,6 +12,6 @@ An {product-title} cluster requires an Azure identity to create and manage Azure
 * The Azure account that you use to create the identity is assigned the `User Access Administrator` and `Contributor` roles. These roles are required when:
 ** Creating a service principal or user-assigned managed identity.
 ** Enabling a system-assigned managed identity on a virtual machine.
-* If you are going to use a service principal to complete the installation, verify that the Azure account that you use to create the identity is assigned the `microsoft.directory/servicePrincipals/createAsOwner` permission in Azure Active Directory.
+* If you are going to use a service principal to complete the installation, verify that the Azure account that you use to create the identity is assigned the `microsoft.directory/servicePrincipals/createAsOwner` permission in Microsoft Entra ID.
 
 To set roles on the Azure portal, see the link:https://docs.microsoft.com/en-us/azure/role-based-access-control/role-assignments-portal[Manage access to Azure resources using RBAC and the Azure portal] in the Azure documentation.
diff --git a/modules/logging-identity-federation.adoc b/modules/logging-identity-federation.adoc
@@ -11,7 +11,7 @@ Workload identity federation enables authentication to cloud-based log stores us
 * {logging-uc} 5.9 and later
 
 .Procedure
-* If you use the {product-title} web console to install the {loki-op}, STS clusters are automatically detected. You are prompted to create roles and supply the data required for the {loki-op} to create a `CredentialsRequest` object, which populates a secret.
+* If you use the {product-title} web console to install the {loki-op}, clusters that use short-lived tokens are automatically detected. You are prompted to create roles and supply the data required for the {loki-op} to create a `CredentialsRequest` object, which populates a secret.
 
 * If you use the {oc-first} to install the {loki-op}, you must manually create a subscription object using the appropriate template for your storage provider, as shown in the following examples. This authentication strategy is only supported for the storage providers indicated.
 
diff --git a/modules/logging-loki-storage-azure.adoc b/modules/logging-loki-storage-azure.adoc
@@ -26,10 +26,10 @@ $ oc create secret generic logging-loki-azure \
 ----
 <1> Supported environment values are `AzureGlobal`, `AzureChinaCloud`, `AzureGermanCloud`, or `AzureUSGovernment`.
 
-[id="Azure_storage_STS_{context}"]
-== Azure storage for STS enabled clusters
+[id="azure_storage_workload_id_{context}"]
+== Azure storage for {entra-first} enabled clusters
 
-If your cluster has STS enabled, the Cloud Credential Operator (CCO) supports short-term authentication using Azure AD Workload Identity.
+If your cluster has {entra-first} enabled, the Cloud Credential Operator (CCO) supports short-term authentication using {entra-short}.
 
 You can create the Loki object storage secret manually by running the following command:
 
diff --git a/modules/olm-installing-from-operatorhub-using-cli.adoc b/modules/olm-installing-from-operatorhub-using-cli.adoc
@@ -188,7 +188,7 @@ spec:
 ----
 <1> Include the role ARN details.
 
-* If the cluster is in {azure-id} mode, include the following fields:
+* If the cluster is in {entra-first} mode, include the following fields:
 +
 [source,yaml]
 ----
diff --git a/modules/olm-installing-from-operatorhub-using-web-console.adoc b/modules/olm-installing-from-operatorhub-using-web-console.adoc
@@ -81,12 +81,12 @@ endif::[]
 .. For clusters on cloud providers with token authentication enabled:
 +
 --
-* If the cluster is in AWS STS mode, enter the Amazon Resource Name (ARN) of the AWS IAM role of your service account in the *role ARN* field.
+* If the cluster uses {aws-short} {sts-short} (*STS Mode* in the web console), enter the Amazon Resource Name (ARN) of the AWS IAM role of your service account in the *role ARN* field.
 +
 image::oadp-install-operator-role-arn.png[Entering the ARN]
 To create the role's ARN, follow the procedure described in link:https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html/tutorials/cloud-experts-deploy-api-data-protection#prepare-aws-account_cloud-experts-deploy-api-data-protection[Preparing AWS account].
 
-* If the cluster is in {azure-id} mode, add the client ID, tenant ID, and subscription ID in the appropriate field.
+* If the cluster uses {entra-first} (*Workload Identity / Federated Identity Mode* in the web console), add the client ID, tenant ID, and subscription ID in the appropriate field.
 --
 
 .. If more than one update channel is available, select an *Update channel*.
@@ -95,7 +95,7 @@ To create the role's ARN, follow the procedure described in link:https://access.
 +
 [IMPORTANT]
 ====
-If the web console shows that the cluster is in AWS STS or {azure-id} mode, you must set *Update approval* to *Manual*.
+If the web console shows that the cluster uses {aws-short} {sts-short} or {entra-first}, you must set *Update approval* to *Manual*.
 
 Subscriptions with automatic update approvals are not recommended because there might be permission changes to make prior to updating. Subscriptions with manual update approvals ensure that administrators have the opportunity to verify the permissions of the later version and take any necessary steps prior to update.
 ====
diff --git a/modules/osdk-cco-azure-enabling.adoc b/modules/osdk-cco-azure-enabling.adoc
diff --git a/observability/logging/log_storage/installing-log-storage.adoc b/observability/logging/log_storage/installing-log-storage.adoc
diff --git a/operators/operator_sdk/token_auth/osdk-cco-azure.adoc b/operators/operator_sdk/token_auth/osdk-cco-azure.adoc
diff --git a/operators/operator_sdk/token_auth/osdk-token-auth.adoc b/operators/operator_sdk/token_auth/osdk-token-auth.adoc

Original file line number	Diff line number	Diff line change
`@@ -400,7 +400,7 @@ openshift-ingress-operator-cloud-credentials-credentials.yaml`
`400`	`400`	`openshift-machine-api-azure-cloud-credentials-credentials.yaml`
`401`	`401`	`----`
`402`	`402`	`+`
`403`		`-You can verify that the Azure AD service accounts are created by querying Azure. For more information, refer to Azure documentation on listing AD service accounts.`
	`403`	`+You can verify that the Microsoft Entra ID service accounts are created by querying Azure. For more information, refer to Azure documentation on listing Entra ID service accounts.`
`404`	`404`	`endif::azure-workload-id[]`
`405`	`405`
`406`	`406`	//Platforms that must use `ccoctl`