Merge pull request #41230 from jeana-redhat/OSDOCS-3132_Stop_mining_Azure_ServicePrincipals

OSDOCS-3132: Removing references to CCO mint mode on Azure for 4.10

Author: jeana-redhat

authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc

@@ -40,7 +40,7 @@ Mint mode is the default and recommended best practice setting for the CCO to us
 
 
 |Microsoft Azure
-|X ^[1]^
+|
 |X ^[1]^
 |X
 
@@ -76,11 +76,6 @@ For platforms on which multiple modes are supported (AWS, Azure, and GCP), when
 
 By default, the CCO determines whether the credentials are sufficient for mint mode, which is the preferred mode of operation, and uses those credentials to create appropriate credentials for components in the cluster. If the credentials are not sufficient for mint mode, it determines whether they are sufficient for passthrough mode. If the credentials are not sufficient for passthrough mode, the CCO cannot adequately process `CredentialsRequest` CRs.
 
-[NOTE]
-====
-The CCO cannot verify whether Azure credentials are sufficient for passthrough mode. If Azure credentials are insufficient for mint mode, the CCO operates with the assumption that the credentials are sufficient for passthrough mode.
-====
-
 If the provided credentials are determined to be insufficient during installation, the installation fails. For AWS, the installer fails early in the process and indicates which required permissions are missing. Other providers might not provide specific information about the cause of the error until errors are encountered.
 
 If the credentials are changed after a successful installation and the CCO determines that the new credentials are insufficient, the CCO puts conditions on any new `CredentialsRequest` CRs to indicate that it cannot process them because of the insufficient credentials.

authentication/managing_cloud_provider_credentials/cco-mode-mint.adoc

@@ -6,18 +6,13 @@ include::modules/common-attributes.adoc[]
 
 toc::[]
 
-Mint mode is supported for Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).
+Mint mode is supported for Amazon Web Services (AWS) and Google Cloud Platform (GCP).
 
-Mint mode is the default and recommended best practice setting for the Cloud Credential Operator (CCO) to use on the platforms for which it is supported. In this mode, the CCO uses the provided administrator-level cloud credential to create new credentials for components in the cluster with only the specific permissions that are required.
+Mint mode is the default mode on the platforms for which it is supported. In this mode, the Cloud Credential Operator (CCO) uses the provided administrator-level cloud credential to create new credentials for components in the cluster with only the specific permissions that are required.
 
 If the credential is not removed after installation, it is stored and used by the CCO to process `CredentialsRequest` CRs for components in the cluster and create new credentials for each with only the specific permissions that are required. The continuous reconciliation of cloud credentials in mint mode allows actions that require additional credentials or permissions, such as upgrading, to proceed.
 
-If the requirement that mint mode stores the administrator-level credential in the cluster `kube-system` namespace does not suit the security requirements of your organization, see _Alternatives to storing administrator-level secrets in the kube-system project_ for xref:../../installing/installing_aws/manually-creating-iam.adoc#alternatives-to-storing-admin-secrets-in-kube-system_manually-creating-iam-aws[AWS], xref:../../installing/installing_azure/manually-creating-iam-azure.adoc#alternatives-to-storing-admin-secrets-in-kube-system_manually-creating-iam-azure[Azure], or xref:../../installing/installing_gcp/manually-creating-iam-gcp.adoc#alternatives-to-storing-admin-secrets-in-kube-system_manually-creating-iam-gcp[GCP].
-
-[NOTE]
-====
-xref:../../authentication/managing_cloud_provider_credentials/cco-mode-manual.adoc#cco-mode-manual[Manual mode] is the only supported CCO configuration for Microsoft Azure Stack Hub.
-====
+Mint mode stores the administrator-level credential in the cluster `kube-system` namespace. If this approach does not meet the security requirements of your organization, see _Alternatives to storing administrator-level secrets in the kube-system project_ for xref:../../installing/installing_aws/manually-creating-iam.adoc#alternatives-to-storing-admin-secrets-in-kube-system_manually-creating-iam-aws[AWS] or xref:../../installing/installing_gcp/manually-creating-iam-gcp.adoc#alternatives-to-storing-admin-secrets-in-kube-system_manually-creating-iam-gcp[GCP].
 
 [id="mint-mode-permissions"]
 == Mint mode permissions requirements
@@ -39,10 +34,6 @@ The credential you provide for mint mode in AWS must have the following permissi
 * `iam:TagUser`
 * `iam:SimulatePrincipalPolicy`
 
-[id="mint-mode-permissions-azure"]
-=== Microsoft Azure permissions
-The credential you provide for mint mode in Azure must have a service principal with the permissions specified in xref:../../installing/installing_azure/installing-azure-account.adoc#installation-azure-service-principal_installing-azure-account[Creating a service principal].
-
 [id="mint-mode-permissions-gcp"]
 === Google Cloud Platform (GCP) permissions
 The credential you provide for mint mode in GCP must have the following permissions:
@@ -71,6 +62,4 @@ include::modules/manually-removing-cloud-creds.adoc[leveloffset=+2]
 == Additional resources
 
 * xref:../../installing/installing_aws/manually-creating-iam.adoc#alternatives-to-storing-admin-secrets-in-kube-system_manually-creating-iam-aws[Alternatives to storing administrator-level secrets in the kube-system project] for AWS
-* xref:../../installing/installing_azure/manually-creating-iam-azure.adoc#alternatives-to-storing-admin-secrets-in-kube-system_manually-creating-iam-azure[Alternatives to storing administrator-level secrets in the kube-system project] for Azure
 * xref:../../installing/installing_gcp/manually-creating-iam-gcp.adoc#alternatives-to-storing-admin-secrets-in-kube-system_manually-creating-iam-gcp[Alternatives to storing administrator-level secrets in the kube-system project] for GCP
-* xref:../../installing/installing_azure/installing-azure-account.adoc#installation-azure-service-principal_installing-azure-account[Creating a service principal] in Azure

installing/installing_azure/manually-creating-iam-azure.adoc

@@ -20,8 +20,6 @@ include::modules/admin-credentials-root-secret-formats.adoc[leveloffset=+1]
 
 include::modules/manually-maintained-credentials-upgrade.adoc[leveloffset=+1]
 
-include::modules/mint-mode.adoc[leveloffset=+1]
-
 [id="manually-creating-iam-azure-next-steps"]
 == Next steps
 

modules/admin-credentials-root-secret-formats.adoc

@@ -12,14 +12,19 @@ ifeval::["{context}" == "manually-creating-iam-gcp"]
 :google-cloud-platform:
 endif::[]
 
+:_content-type: REFERENCE
 [id="admin-credentials-root-secret-formats_{context}"]
 = Admin credentials root secret format
 
 Each cloud provider uses a credentials root secret in the `kube-system`
 namespace by convention, which is then used to satisfy all credentials requests
-and create their respective secrets. This is done either by minting new
-credentials, with _mint mode_, or by copying the credentials root secret, with
-_passthrough mode_.
+and create their respective secrets.
+ifndef::azure[]
+This is done either by minting new credentials with _mint mode_, or by copying the credentials root secret with _passthrough mode_.
+endif::azure[]
+ifdef::azure[]
+This is done by copying the credentials root secret with _passthrough mode_.
+endif::azure[]
 
 The format for the secret varies by cloud, and is also used for each
 `CredentialsRequest` secret.
@@ -63,9 +68,7 @@ stringData:
   azure_region: <Region>
 ----
 
-On Microsoft Azure, the credentials secret format includes two properties that must
-contain the cluster's infrastructure ID, generated randomly for each cluster
-installation. This value can be found after running create manifests:
+On Microsoft Azure, the credentials secret format includes two properties that must contain the cluster's infrastructure ID, generated randomly for each cluster installation. This value can be found after running create manifests:
 
 [source,terminal]
 ----

modules/manually-rotating-cloud-creds.adoc

@@ -22,19 +22,14 @@ You can also use the command line interface to complete all parts of this proced
 
 * Your cluster is installed on a platform that supports rotating cloud credentials manually with the CCO mode that you are using:
 
-** For mint mode, AWS, Azure, and GCP are supported.
+** For mint mode, AWS and GCP are supported.
 
 ** For passthrough mode, AWS, Azure, GCP, {rh-openstack-first}, {rh-virtualization-first}, and VMware vSphere are supported.
 
 * You have changed the credentials that are used to interface with your cloud provider.
 
 * The new credentials have sufficient permissions for the mode CCO is configured to use in your cluster.
 
-[NOTE]
-====
-When rotating the credentials for an Azure cluster that is using mint mode, do not delete or replace the service principal that was used during installation. Instead, generate new Azure service principal client secrets and update the {product-title} secrets accordingly.
-====
-
 .Procedure
 
 . In the *Administrator* perspective of the web console, navigate to *Workloads* -> *Secrets*.
@@ -88,7 +83,6 @@ Where `<provider_spec>` is the corresponding value for your cloud provider: `AWS
   "name": "cloud-credential-operator-iam-ro-creds",
   "namespace": "openshift-cloud-credential-operator"
 }
-...
 ----
 
 .. Delete each of the referenced component secrets:
@@ -109,11 +103,13 @@ $ oc delete secret ebs-cloud-credentials -n openshift-cluster-csi-drivers
 +
 You do not need to manually delete the credentials from your provider console. Deleting the referenced component secrets will cause the CCO to delete the existing credentials from the platform and create new ones.
 
-. To verify that the credentials have changed:
+.Verification
+
+To verify that the credentials have changed:
 
-.. In the *Administrator* perspective of the web console, navigate to *Workloads* -> *Secrets*.
+. In the *Administrator* perspective of the web console, navigate to *Workloads* -> *Secrets*.
 
-.. Verify that the contents of the *Value* field or fields are different than the previously recorded information.
+. Verify that the contents of the *Value* field or fields have changed.
 
 ////
 // Provider-side verification also possible, though cluster-side is cleaner process.

modules/mint-mode.adoc

@@ -1,13 +1,13 @@
 // Module included in the following assemblies:
 //
 // * installing/installing_aws/manually-creating-iam.adoc
-// * installing/installing_azure/manually-creating-iam-azure.adoc
 // * installing/installing_gcp/manually-creating-iam-gcp.adoc
 
+:_content-type: CONCEPT
 [id="mint-mode_{context}"]
 = Mint mode
 
-Mint mode is the default and recommended Cloud Credential Operator (CCO) credentials mode for {product-title}. In this mode, the CCO uses the provided administrator-level cloud credential to run the cluster. Mint mode is supported for AWS, GCP, and Azure.
+Mint mode is the default Cloud Credential Operator (CCO) credentials mode for {product-title} on platforms that support it. In this mode, the CCO uses the provided administrator-level cloud credential to run the cluster. Mint mode is supported for AWS and GCP.
 
 In mint mode, the `admin` credential is stored in the `kube-system` namespace and then used by the CCO to process the `CredentialsRequest` objects in the cluster and create users for each with specific permissions.