OSDOCS-3209 - Adding OSD wizard updates

Author: pneedle-rh

_topic_maps/_topic_map_osd.yml

@@ -51,7 +51,7 @@ Name: Getting started
 Dir: osd_quickstart
 Distros: openshift-dedicated
 Topics:
-- Name: Quickstart for OpenShift Dedicated
+- Name: Getting started with OpenShift Dedicated
   File: osd-quickstart
 ---
 Name: Red Hat OpenShift Cluster Manager (OCM)
@@ -65,8 +65,12 @@ Name: Creating a cluster
 Dir: osd_cluster_create
 Distros: openshift-dedicated
 Topics:
-- Name: Creating your cluster
-  File: creating-your-cluster
+- Name: Understanding your cloud deployment options
+  File: osd-understanding-your-cloud-deployment-options
+- Name: Creating a cluster on AWS
+  File: creating-an-aws-cluster
+- Name: Creating a cluster on GCP
+  File: creating-a-gcp-cluster
 ---
 Name: Configuring identity providers
 Dir: identity_providers

modules/access-cluster.adoc

@@ -1,28 +1,25 @@
 // Module included in the following assemblies:
 //
-// * assemblies/accessing-cluster.adoc
-// * assemblies/quickstart-osd.adoc
+// * osd_quickstart/osd-quickstart.adoc
+// * identity_providers/config-identity-providers.adoc
 
 :_content-type: PROCEDURE
 [id="access-cluster_{context}"]
 = Accessing your cluster
 
-
-After you have configured your identity providers, users can access the cluster from the {OCM}.
+After you have added a user to your configured identity provider, you can log in to your {product-title} cluster through the web console.
 
 .Prerequisites
 
-* You have created a cluster.
-* Identity providers have been configured for your cluster.
+* You logged in to {OCM}.
+* You created an {product-title} cluster.
+* You configured an identity provider for your cluster.
+* You added your user account to the configured identity provider.
 
 .Procedure
 
-. From {console-redhat-com}, click on the cluster you want to access.
-
-. Click *Open Console*.
-
-. Click on your identity provider and provide your credentials to log into the cluster.
+. Navigate to {console-redhat-com} and select your cluster.
 
-.Verification
+. Click *Open console* to open the web console for your cluster.
 
-* After you have accessed the cluster, you are directed to the console for your {product-title} cluster.
+. Click on your identity provider and provide your credentials to log in to the cluster. Complete any authorization requests that are presented by your provider.

modules/add-user.adoc

@@ -13,7 +13,7 @@ The Customer Cloud Subscription (CCS) model allows Red Hat to deploy and manage
 
 . If the customer is using AWS Organizations, you must either use an AWS account within your organization or link:https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_create.html#orgs_manage_accounts_create-new[create a new one].
 
-. To ensure that Red Hat can perform necessary actions, you must either create a Service Control Policy (SCP) or ensure that none is applied to the AWS account.
+. To ensure that Red Hat can perform necessary actions, you must either create a service control policy (SCP) or ensure that none is applied to the AWS account.
 
 . link:https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html[Attach] the SCP to the AWS account.
 

modules/ccs-aws-customer-procedure.adoc

@@ -13,7 +13,7 @@
 
 * The customer ensures that link:https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html[AWS limits] are sufficient to support {product-title} provisioned within the customer-provided AWS account.
 
-* The customer-provided AWS account should be in the customer's AWS Organization with the applicable Service Control Policy (SCP) applied.
+* The customer-provided AWS account should be in the customer's AWS Organization with the applicable service control policy (SCP) applied.
 +
 [NOTE]
 ====

modules/ccs-aws-customer-requirements.adoc

@@ -35,7 +35,7 @@ IAM policies are subject to modification as the capabilities of {product-title}
 
 ** VPC Peering
 ** VPN Setup
-** Direct Connect (only available if granted through the Service Control Policy)
+** Direct Connect (only available if granted through the service control policy)
 +
 [source,json]
 ----

modules/ccs-aws-iam.adoc

@@ -3,10 +3,10 @@
 // * assemblies/aws-ccs.adoc
 
 [id="ccs-aws-scp_{context}"]
-= Minimum required Service Control Policy (SCP)
+= Minimum required service control policy (SCP)
 
 
-Service Control Policy (SCP) management is the responsibility of the customer. These policies are maintained in the AWS Organization and control what services are available within the attached AWS accounts.
+Service control policy (SCP) management is the responsibility of the customer. These policies are maintained in the AWS Organization and control what services are available within the attached AWS accounts.
 
 [cols="2a,2a,2a,2a",options="header"]
 

modules/ccs-aws-scp.adoc

@@ -11,4 +11,4 @@ To deploy {product-title} into your existing Amazon Web Services (AWS) account u
 
 Red Hat recommends the usage of an AWS Organization to manage multiple AWS accounts. The AWS Organization, managed by the customer, hosts multiple AWS accounts. There is a root account in the organization that all accounts will refer to in the account hierarchy.
 
-It is recommended for the {product-title} cluster using a CCS model to be hosted in an AWS account within an AWS Organizational Unit. A Service Control Policy (SCP) is created and applied to the AWS Organizational Unit that manages what services the AWS sub-accounts are permitted to access. The SCP applies only to available permissions within a single AWS account for all AWS sub-accounts within the Organizational Unit. It is also possible to apply a SCP to a single AWS account. All other accounts in the customer’s AWS Organization are managed in whatever manner the customer requires. Red Hat Site Reliability Engineers (SRE) will not have any control over SCPs within the AWS Organization.
+It is recommended for the {product-title} cluster using a CCS model to be hosted in an AWS account within an AWS Organizational Unit. A service control policy (SCP) is created and applied to the AWS Organizational Unit that manages what services the AWS sub-accounts are permitted to access. The SCP applies only to available permissions within a single AWS account for all AWS sub-accounts within the Organizational Unit. It is also possible to apply a SCP to a single AWS account. All other accounts in the customer’s AWS Organization are managed in whatever manner the customer requires. Red Hat Site Reliability Engineers (SRE) will not have any control over SCPs within the AWS Organization.

modules/ccs-aws-understand.adoc

@@ -6,8 +6,11 @@
 [id="config-idp_{context}"]
 = Configuring an identity provider
 
+After you have installed {product-title}, you must configure your cluster to use an identity provider. You can then add members to your identity provider to grant them access to your cluster.
 
-After your {product-title} cluster is created, you must configure identity providers to determine how users log in to access the cluster. This example configures a GitHub identity provider.
+You can configure different identity provider types for your {product-title} cluster. Supported types include GitHub, GitHub Enterprise, GitLab, Google, LDAP, OpenID Connect, and HTPasswd identity providers.
+
+The following procedure configures a GitHub identity provider as an example.
 
 [WARNING]
 ====
@@ -16,53 +19,72 @@ Configuring GitHub authentication allows users to log in to {product-title} with
 
 .Prerequisites
 
-* The OAuth application must be created directly within the GitHub link:https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/managing-organization-settings[organization settings] by the GitHub organization administrator.
-* link:https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams[GitHub organizations or teams] are set up in your GitHub account.
+* You logged in to {OCM}.
+* You created an {product-title} cluster.
+* You have a GitHub user account.
+* You created a GitHub organization in your GitHub account. For more information, see link:https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/creating-a-new-organization-from-scratch[Creating a new organization from scratch] in the GitHub documentation.
+* If you are restricting user access to a GitHub team, you have created a team within your GitHub organization. For more information, see link:https://docs.github.com/en/organizations/organizing-members-into-teams/creating-a-team[Creating a team] in the GitHub documentation.
 
 .Procedure
 
-. Navigate to the *Clusters* page and select the cluster that you need to configure identity providers for.
+. Navigate to {console-redhat-com} and select your cluster.
+
+. Select *Access control* -> *Identity providers*.
+
+. Select the *GitHub* identity provider type from the *Add identity provider* drop-down menu.
 
-. Click the *Access control* tab.
+. Enter a unique name for the identity provider. The name cannot be changed later.
 
-. Click *Add identity provider*.
+. Register an OAuth application in your GitHub organization by following the steps in the link:https://docs.github.com/en/developers/apps/creating-an-oauth-app[GitHub documentation].
 +
 [NOTE]
 ====
-You can also click the *Add Oauth configuration* link in the warning message displayed after cluster creation to configure your identity providers.
+You must register the OAuth app under your GitHub organization. If you register an OAuth application that is not owned by the organization that contains your cluster users or teams, then user authentication to the cluster will not succeed.
 ====
 
-. Select *GitHub* from the drop-down menu.
-
-. Enter a unique name for the identity provider. This name cannot be changed later.
-** An *OAuth callback URL* is automatically generated in the provided field. You will use this to register the GitHub application.
+* For the homepage URL in your GitHub OAuth app configuration, specify the `\https://oauth-openshift.apps.<cluster_name>.<cluster_domain>` portion of the *OAuth callback URL* that is automatically generated in the *Add a GitHub identity provider* page on {OCM}.
++
+The following is an example of a homepage URL for a GitHub identity provider:
 +
 ----
-https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
+https://oauth-openshift.apps.example-openshift-cluster.com
 ----
-+
-For example:
+
+* For the authorization callback URL in your GitHub OAuth app configuration, specify the full *OAuth callback URL* that is automatically generated in the *Add a GitHub identity provider* page on {OCM}. The full URL has the following syntax:
 +
 ----
-https://oauth-openshift.apps.example-openshift-cluster.com/oauth2callback/github/
+https://oauth-openshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name>
 ----
 
-. link:https://docs.github.com/en/developers/apps/creating-an-oauth-app[Register an application on GitHub].
+. Return to the *Edit identity provider: GitHub* dialog in {OCM} and select *Claim* from the *Mapping method* drop-down menu.
 
-. Return to {product-title} and select a mapping method from the drop-down menu. *Claim* is recommended in most cases.
+. Enter the *Client ID* and *Client secret* for your GitHub OAuth application. The GitHub page for your OAuth app provides the ID and secret.
 
-. Enter the *Client ID* and *Client secret* provided by GitHub.
-
-. Enter a *hostname*. A hostname must be entered when using a hosted instance of GitHub Enterprise.
+. Optional: Enter a *hostname*.
++
+[NOTE]
+====
+A hostname must be entered when using a hosted instance of GitHub Enterprise.
+====
 
-. Optional: You can use a certificate authority (CA) file to validate server certificates for the configured GitHub Enterprise URL. Click *Browse* to locate and attach a *CA file* to the identity provider.
+. Optional: You can specify a certificate authority (CA) file to validate server certificates for a configured GitHub Enterprise URL. Click *Browse* to locate and attach a *CA file* to the identity provider.
 
-. Select *Use organizations* or *Use teams* to restrict access to a particular GitHub organization or a GitHub team.
+. Select *Use organizations* or *Use teams* to restrict access to a GitHub organization or a GitHub team within an organization.
 
-. Enter the name of the organization or team you would like to restrict access to. Click *Add more* to specify multiple organizations or teams that users can be a member of.
+. Enter the name of the organization or team you would like to restrict access to. Click *Add more* to specify multiple organizations or teams.
++
+[NOTE]
+====
+Specified organizations must own an OAuth app that was registered by using the preceding steps. If you specify a team, it must exist within an organization that owns an OAuth app that was registered by using the preceding steps.
+====
 
-. Click *Confirm*.
+. Click *Add* to apply the identity provider configuration.
++
+[NOTE]
+====
+It might take approximately two minutes for the identity provider configuration to become active.
+====
 
 .Verification
 
-* The configured identity provider is now visible on the *Access control* tab of the *Clusters* page.
+* After the configuration becomes active, the identity provider is listed under *Access control* -> *Identity providers* on the {OCM} page for your cluster.