OSDOCS-3984: Port Authentication and authorization book to OSD and ROSA

Author: bhardesty

_topic_maps/_topic_map_osd.yml

@@ -265,8 +265,6 @@ Name: Cluster administration
 Dir: osd_cluster_admin
 Distros: openshift-dedicated
 Topics:
-- Name: Managing administration roles and users
-  File: osd-admin-roles
 - Name: Configuring private connections
   Dir: osd_private_connections
   Distros: openshift-dedicated
@@ -305,8 +303,80 @@ Name: Authentication and authorization
 Dir: authentication
 Distros: openshift-dedicated
 Topics:
+- Name: Authentication and authorization overview
+  File: index
+- Name: Understanding authentication
+  File: understanding-authentication
+# - Name: Configuring the internal OAuth server
+#   File: configuring-internal-oauth
+# - Name: Configuring OAuth clients
+#   File: configuring-oauth-clients
+- Name: Managing user-owned OAuth access tokens
+  File: managing-oauth-access-tokens
+# - Name: Understanding identity provider configuration
+#   File: understanding-identity-provider
+- Name: Configuring identity providers
+  File: sd-configuring-identity-providers
+# - Name: Configuring identity providers
+#   Dir: identity_providers
+#   Topics:
+#   - Name: Configuring an htpasswd identity provider
+#     File: configuring-htpasswd-identity-provider
+#   - Name: Configuring a Keystone identity provider
+#     File: configuring-keystone-identity-provider
+#   - Name: Configuring an LDAP identity provider
+#     File: configuring-ldap-identity-provider
+#   - Name: Configuring a basic authentication identity provider
+#     File: configuring-basic-authentication-identity-provider
+#   - Name: Configuring a request header identity provider
+#     File: configuring-request-header-identity-provider
+#   - Name: Configuring a GitHub or GitHub Enterprise identity provider
+#     File: configuring-github-identity-provider
+#   - Name: Configuring a GitLab identity provider
+#     File: configuring-gitlab-identity-provider
+#   - Name: Configuring a Google identity provider
+#     File: configuring-google-identity-provider
+#   - Name: Configuring an OpenID Connect identity provider
+#     File: configuring-oidc-identity-provider
+- Name: Managing administration roles and users
+  File: osd-admin-roles
+- Name: Using RBAC to define and apply permissions
+  File: using-rbac
+# - Name: Removing the kubeadmin user
+#   File: remove-kubeadmin
+#- Name: Configuring LDAP failover
+#  File: configuring-ldap-failover
+- Name: Understanding and creating service accounts
+  File: understanding-and-creating-service-accounts
+- Name: Using service accounts in applications
+  File: using-service-accounts-in-applications
+- Name: Using a service account as an OAuth client
+  File: using-service-accounts-as-oauth-client
+- Name: Scoping tokens
+  File: tokens-scoping
+- Name: Using bound service account tokens
+  File: bound-service-account-tokens
 - Name: Managing security context constraints
   File: managing-security-context-constraints
+- Name: Understanding and managing pod security admission
+  File: understanding-and-managing-pod-security-admission
+# - Name: Impersonating the system:admin user
+#   File: impersonating-system-admin
+- Name: Syncing LDAP groups
+  File: ldap-syncing
+# - Name: Managing cloud provider credentials
+#   Dir: managing_cloud_provider_credentials
+#   Topics:
+#   - Name: About the Cloud Credential Operator
+#     File: about-cloud-credential-operator
+#   - Name: Mint mode
+#     File: cco-mode-mint
+#   - Name: Passthrough mode
+#     File: cco-mode-passthrough
+#   - Name: Manual mode with long-term credentials for components
+#     File: cco-mode-manual
+#   - Name: Manual mode with short-term credentials for components
+#     File: cco-short-term-creds
 ---
 Name: Upgrading
 Dir: upgrading

_topic_maps/_topic_map_rosa.yml

@@ -454,10 +454,80 @@ Name: Authentication and authorization
 Dir: authentication
 Distros: openshift-rosa
 Topics:
+- Name: Authentication and authorization overview
+  File: index
+- Name: Understanding authentication
+  File: understanding-authentication
+# - Name: Configuring the internal OAuth server
+#   File: configuring-internal-oauth
+# - Name: Configuring OAuth clients
+#   File: configuring-oauth-clients
+- Name: Managing user-owned OAuth access tokens
+  File: managing-oauth-access-tokens
+# - Name: Understanding identity provider configuration
+#   File: understanding-identity-provider
+- Name: Configuring identity providers
+  File: sd-configuring-identity-providers
+# - Name: Configuring identity providers
+#   Dir: identity_providers
+#   Topics:
+#   - Name: Configuring an htpasswd identity provider
+#     File: configuring-htpasswd-identity-provider
+#   - Name: Configuring a Keystone identity provider
+#     File: configuring-keystone-identity-provider
+#   - Name: Configuring an LDAP identity provider
+#     File: configuring-ldap-identity-provider
+#   - Name: Configuring a basic authentication identity provider
+#     File: configuring-basic-authentication-identity-provider
+#   - Name: Configuring a request header identity provider
+#     File: configuring-request-header-identity-provider
+#   - Name: Configuring a GitHub or GitHub Enterprise identity provider
+#     File: configuring-github-identity-provider
+#   - Name: Configuring a GitLab identity provider
+#     File: configuring-gitlab-identity-provider
+#   - Name: Configuring a Google identity provider
+#     File: configuring-google-identity-provider
+#   - Name: Configuring an OpenID Connect identity provider
+#     File: configuring-oidc-identity-provider
+- Name: Using RBAC to define and apply permissions
+  File: using-rbac
+# - Name: Removing the kubeadmin user
+#   File: remove-kubeadmin
+#- Name: Configuring LDAP failover
+#  File: configuring-ldap-failover
+- Name: Understanding and creating service accounts
+  File: understanding-and-creating-service-accounts
+- Name: Using service accounts in applications
+  File: using-service-accounts-in-applications
+- Name: Using a service account as an OAuth client
+  File: using-service-accounts-as-oauth-client
 - Name: Assuming an AWS IAM role for a service account
   File: assuming-an-aws-iam-role-for-a-service-account
+- Name: Scoping tokens
+  File: tokens-scoping
+- Name: Using bound service account tokens
+  File: bound-service-account-tokens
 - Name: Managing security context constraints
   File: managing-security-context-constraints
+- Name: Understanding and managing pod security admission
+  File: understanding-and-managing-pod-security-admission
+# - Name: Impersonating the system:admin user
+#   File: impersonating-system-admin
+- Name: Syncing LDAP groups
+  File: ldap-syncing
+# - Name: Managing cloud provider credentials
+#   Dir: managing_cloud_provider_credentials
+#   Topics:
+#   - Name: About the Cloud Credential Operator
+#     File: about-cloud-credential-operator
+#   - Name: Mint mode
+#     File: cco-mode-mint
+#   - Name: Passthrough mode
+#     File: cco-mode-passthrough
+#   - Name: Manual mode with long-term credentials for components
+#     File: cco-mode-manual
+#   - Name: Manual mode with short-term credentials for components
+#     File: cco-short-term-creds
 ---
 Name: Upgrading
 Dir: upgrading

authentication/bound-service-account-tokens.adoc

@@ -20,7 +20,10 @@ include::modules/bound-sa-tokens-configuring-externally.adoc[leveloffset=+1]
 [role="_additional-resources"]
 .Additional resources
 
+// This xref target does not exist in the OSD/ROSA docs.
+ifndef::openshift-dedicated,openshift-rosa[]
 * xref:../nodes/nodes/nodes-nodes-rebooting.adoc#nodes-nodes-rebooting-gracefully_nodes-nodes-rebooting[Rebooting a node gracefully]
+endif::openshift-dedicated,openshift-rosa[]
 
 * xref:../authentication/understanding-and-creating-service-accounts.adoc#service-accounts-managing_understanding-service-accounts[Creating service accounts]
 

authentication/index.adoc

@@ -9,23 +9,38 @@ include::modules/authentication-authorization-common-terms.adoc[leveloffset=+1]
 
 [id="authentication-overview"]
 == About authentication in {product-title}
-To control access to an {product-title} cluster, a cluster administrator can configure xref:../authentication/understanding-authentication.adoc#understanding-authentication[user authentication] and ensure only approved users access the cluster.
+To control access to an {product-title} cluster,
+ifndef::openshift-dedicated,openshift-rosa[]
+a cluster administrator
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+an administrator with the `dedicated-admin` role
+endif::openshift-dedicated,openshift-rosa[]
+can configure xref:../authentication/understanding-authentication.adoc#understanding-authentication[user authentication] and ensure only approved users access the cluster.
 
 To interact with an {product-title} cluster, users must first authenticate to the {product-title} API in some way. You can authenticate by providing an xref:../authentication/understanding-authentication.adoc#rbac-api-authentication_understanding-authentication[OAuth access token or an X.509 client certificate] in your requests to the {product-title} API.
 
 [NOTE]
 ====
 If you do not present a valid access token or certificate, your request is unauthenticated and you receive an HTTP 401 error.
 ====
+
+ifdef::openshift-dedicated,openshift-rosa[]
+An administrator can configure authentication by configuring an identity provider. You can define any xref:../authentication/sd-configuring-identity-providers.adoc#understanding-idp-supported_sd-configuring-identity-providers[supported identity provider in {product-title}] and add it to your cluster.
+endif::openshift-dedicated,openshift-rosa[]
+
+ifndef::openshift-dedicated,openshift-rosa[]
 An administrator can configure authentication through the following tasks:
 
 * Configuring an identity provider: You can define any xref:../authentication/understanding-identity-provider.adoc#supported-identity-providers[supported identity provider in {product-title}] and add it to your cluster.
-* xref:../authentication/configuring-internal-oauth.adoc#configuring-internal-oauth[Configuring the internal OAuth server]: The {product-title} control plane includes a built-in OAuth server that determines the user’s identity from the configured identity provider and creates an access token. You can configure the token duration and inactivity timeout, and customize the internal OAuth server URL.
+
+* xref:../authentication/configuring-internal-oauth.adoc#configuring-internal-oauth[Configuring the internal OAuth server]: The {product-title} control plane includes a built-in OAuth server that determines the user's identity from the configured identity provider and creates an access token. You can configure the token duration and inactivity timeout, and customize the internal OAuth server URL.
 +
 [NOTE]
 ====
 Users can xref:../authentication/managing-oauth-access-tokens.adoc#managing-oauth-access-tokens[view and manage OAuth tokens owned by them].
 ====
+
 * Registering an OAuth client: {product-title} includes several xref:../authentication/configuring-oauth-clients.adoc#oauth-default-clients_configuring-oauth-clients[default OAuth clients]. You can xref:../authentication/configuring-oauth-clients.adoc#oauth-register-additional-client_configuring-oauth-clients[register and configure additional OAuth clients].
 +
 [NOTE]
@@ -35,6 +50,7 @@ When users send a request for an OAuth token, they must specify either a default
 
 * Managing cloud provider credentials using the xref:../authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc#about-cloud-credential-operator[Cloud Credentials Operator]: Cluster components use cloud provider credentials to get permissions required to perform cluster-related tasks.
 * Impersonating a system admin user: You can grant cluster administrator permissions to a user by xref:../authentication/impersonating-system-admin.adoc#impersonating-system-admin[impersonating a system admin user].
+endif::openshift-dedicated,openshift-rosa[]
 
 [id="authorization-overview"]
 == About authorization in {product-title}
@@ -49,14 +65,35 @@ Along with controlling user access to a cluster, you can also control the action
 You can manage authorization for {product-title} through the following tasks:
 
 * Viewing xref:../authentication/using-rbac.adoc#viewing-local-roles_using-rbac[local] and xref:../authentication/using-rbac.adoc#viewing-cluster-roles_using-rbac[cluster] roles and bindings.
+
 * Creating a xref:../authentication/using-rbac.adoc#creating-local-role_using-rbac[local role] and assigning it to a user or group.
+
+ifndef::openshift-dedicated,openshift-rosa[]
 * Creating a cluster role and assigning it to a user or group: {product-title} includes a set of xref:../authentication/using-rbac.adoc#default-roles_using-rbac[default cluster roles]. You can create additional xref:../authentication/using-rbac.adoc#creating-cluster-role_using-rbac[cluster roles] and xref:../authentication/using-rbac.adoc#adding-roles_using-rbac[add them to a user or group].
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+* Assigning a cluster role to a user or group: {product-title} includes a set of xref:../authentication/using-rbac.adoc#default-roles_using-rbac[default cluster roles]. You can xref:../authentication/using-rbac.adoc#adding-roles_using-rbac[add them to a user or group].
+endif::openshift-dedicated,openshift-rosa[]
+
+ifndef::openshift-dedicated,openshift-rosa[]
 * Creating a cluster-admin user: By default, your cluster has only one cluster administrator called `kubeadmin`. You can xref:../authentication/using-rbac.adoc#creating-cluster-admin_using-rbac[create another cluster administrator]. Before creating a cluster administrator, ensure that you have configured an identity provider.
 +
 [NOTE]
 ====
 After creating the cluster admin user, xref:../authentication/remove-kubeadmin.adoc#removing-kubeadmin_removing-kubeadmin[delete the existing kubeadmin user] to improve cluster security.
 ====
+endif::openshift-dedicated,openshift-rosa[]
+
+ifdef::openshift-rosa[]
+* Creating cluster-admin and dedicated-admin users: The user who created the {product-title} cluster can grant access to other xref:../authentication/using-rbac.adoc#rosa-create-cluster-admins_using-rbac[`cluster-admin`] and xref:../authentication/using-rbac.adoc#rosa-create-dedicated-cluster-admins_using-rbac[`dedicated-admin`] users.
+endif::openshift-rosa[]
+
+ifdef::openshift-dedicated[]
+* Granting administrator privileges to users: You can xref:../authentication/using-rbac.adoc#osd-grant-admin-privileges_using-rbac[grant `dedicated-admin` privileges to users].
+endif::openshift-dedicated[]
+
 * Creating service accounts: xref:../authentication/understanding-and-creating-service-accounts.adoc#service-accounts-overview_understanding-service-accounts[Service accounts] provide a flexible way to control API access without sharing a regular user’s credentials. A user can xref:../authentication/understanding-and-creating-service-accounts.adoc#service-accounts-managing_understanding-service-accounts[create and use a service account in applications] and also as xref:../authentication/using-service-accounts-as-oauth-client.adoc#using-service-accounts-as-oauth-client[an OAuth client].
+
 * xref:../authentication/tokens-scoping.adoc#tokens-scoping[Scoping tokens]: A scoped token is a token that identifies as a specific user who can perform only specific operations. You can create scoped tokens to delegate some of your permissions to another user or a service account.
+
 * Syncing LDAP groups: You can manage user groups in one place by xref:../authentication/ldap-syncing.adoc#ldap-syncing[syncing the groups stored in an LDAP server] with the {product-title} user groups.

authentication/ldap-syncing.adoc

@@ -9,6 +9,9 @@ toc::[]
 ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 As an administrator,
 endif::[]
+ifdef::openshift-dedicated,openshift-rosa[]
+As an administrator with the `dedicated-admin` role,
+endif::openshift-dedicated,openshift-rosa[]
 you can use groups to manage users, change
 their permissions, and enhance collaboration. Your organization may have already
 created user groups and stored them in an LDAP server. {product-title} can sync
@@ -17,15 +20,28 @@ your groups in one place. {product-title} currently supports group sync with
 LDAP servers using three common schemas for defining group membership: RFC 2307,
 Active Directory, and augmented Active Directory.
 
+ifndef::openshift-dedicated,openshift-rosa[]
 For more information on configuring LDAP, see
 xref:../authentication/identity_providers/configuring-ldap-identity-provider.adoc#configuring-ldap-identity-provider[Configuring an LDAP identity provider].
+endif::openshift-dedicated,openshift-rosa[]
+
+ifdef::openshift-dedicated,openshift-rosa[]
+For more information on configuring LDAP, see
+xref:../authentication/sd-configuring-identity-providers.adoc#config-ldap-idp_sd-configuring-identity-providers[Configuring an LDAP identity provider].
+endif::openshift-dedicated,openshift-rosa[]
 
 ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 [NOTE]
 ====
 You must have `cluster-admin` privileges to sync groups.
 ====
 endif::[]
+ifdef::openshift-dedicated,openshift-rosa[]
+[NOTE]
+====
+You must have `dedicated-admin` privileges to sync groups.
+====
+endif::openshift-dedicated,openshift-rosa[]
 
 include::modules/ldap-syncing-about.adoc[leveloffset=+1]
 include::modules/ldap-syncing-config-rfc2307.adoc[leveloffset=+2]
@@ -37,6 +53,8 @@ include::modules/ldap-syncing-running-openshift.adoc[leveloffset=+2]
 include::modules/ldap-syncing-running-subset.adoc[leveloffset=+2]
 include::modules/ldap-syncing-pruning.adoc[leveloffset=+1]
 
+// OSD and ROSA dedicated-admins cannot create the cluster roles and cluster role bindings required for this procedure.
+ifndef::openshift-dedicated,openshift-rosa[]
 // Automatically syncing LDAP groups
 include::modules/ldap-auto-syncing.adoc[leveloffset=+1]
 
@@ -45,6 +63,7 @@ include::modules/ldap-auto-syncing.adoc[leveloffset=+1]
 
 * xref:../authentication/identity_providers/configuring-ldap-identity-provider.adoc#configuring-ldap-identity-provider[Configuring an LDAP identity provider]
 * xref:../nodes/jobs/nodes-nodes-jobs.adoc#nodes-nodes-jobs-creating-cron_nodes-nodes-jobs[Creating cron jobs]
+endif::openshift-dedicated,openshift-rosa[]
 
 include::modules/ldap-syncing-examples.adoc[leveloffset=+1]
 include::modules/ldap-syncing-rfc2307.adoc[leveloffset=+2]

osd_cluster_admin/osd-admin-roles.adoc renamed to authentication/osd-admin-roles.adoc

@@ -0,0 +1,33 @@
+:_content-type: ASSEMBLY
+[id="sd-configuring-identity-providers"]
+= Configuring identity providers
+include::_attributes/attributes-openshift-dedicated.adoc[]
+:context: sd-configuring-identity-providers
+
+toc::[]
+
+After your {product-title} cluster is created, you must configure identity providers to determine how users log in to access the cluster.
+
+ifdef::openshift-rosa[]
+The following topics describe how to configure an identity provider using {cluster-manager} console. Alternatively, you can use the ROSA CLI (`rosa`) to configure an identity provider and access the cluster.
+endif::openshift-rosa[]
+
+include::modules/understanding-idp.adoc[leveloffset=+1]
+include::modules/identity-provider-parameters.adoc[leveloffset=+2]
+include::modules/config-github-idp.adoc[leveloffset=+1]
+include::modules/config-gitlab-idp.adoc[leveloffset=+1]
+include::modules/config-google-idp.adoc[leveloffset=+1]
+include::modules/config-ldap-idp.adoc[leveloffset=+1]
+include::modules/config-openid-idp.adoc[leveloffset=+1]
+include::modules/config-htpasswd-idp.adoc[leveloffset=+1]
+ifdef::openshift-dedicated[]
+include::modules/access-cluster.adoc[leveloffset=+1]
+endif::openshift-dedicated[]
+
+ifdef::openshift-rosa[]
+[id="additional-resources-cluster-access-sts"]
+[role="_additional-resources"]
+== Additional resources
+* xref:../rosa_install_access_delete_clusters/rosa-sts-accessing-cluster.adoc#rosa-sts-accessing-cluster[Accessing a cluster]
+* xref:../rosa_getting_started/rosa-sts-getting-started-workflow.adoc#rosa-sts-understanding-the-deployment-workflow[Understanding the ROSA with STS deployment workflow]
+endif::openshift-rosa[]