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

_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,7 +9,14 @@ 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.
 
@@ -17,15 +24,23 @@ To interact with an {product-title} cluster, users must first authenticate to th
 ====
 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,8 +20,15 @@ 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]
@@ -26,6 +36,12 @@ ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 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]

authentication/sd-configuring-identity-providers.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[]

authentication/understanding-and-managing-pod-security-admission.adoc

@@ -30,8 +30,11 @@ include::modules/security-context-constraints-psa-label.adoc[leveloffset=+1]
 // About pod security admission alerts
 include::modules/security-context-constraints-psa-rectifying.adoc[leveloffset=+1]
 
+// OSD and ROSA dedicated-admin users cannot use the must-gather tool.
+ifndef::openshift-dedicated,openshift-rosa[]
 // Identifying pod security violations
 include::modules/security-context-constraints-psa-alert-eval.adoc[leveloffset=+2]
+endif::openshift-dedicated,openshift-rosa[]
 
 [role="_additional-resources"]
 [id="additional-resources_managing-pod-security-admission"]

authentication/using-rbac.adoc

@@ -18,16 +18,27 @@ include::modules/rbac-viewing-local-roles.adoc[leveloffset=+1]
 
 include::modules/rbac-adding-roles.adoc[leveloffset=+1]
 
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
 include::modules/rbac-creating-local-role.adoc[leveloffset=+1]
 
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
 include::modules/rbac-creating-cluster-role.adoc[leveloffset=+1]
 endif::[]
 
 include::modules/rbac-local-role-binding-commands.adoc[leveloffset=+1]
 
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
 include::modules/rbac-cluster-role-binding-commands.adoc[leveloffset=+1]
-
-include::modules/rbac-creating-cluster-admin.adoc[leveloffset=+1]
 endif::[]
+
+ifndef::openshift-dedicated,openshift-rosa[]
+include::modules/rbac-creating-cluster-admin.adoc[leveloffset=+1]
+endif::openshift-dedicated,openshift-rosa[]
+
+ifdef::openshift-rosa[]
+include::modules/rosa-create-cluster-admins.adoc[leveloffset=+1]
+include::modules/rosa-create-dedicated-cluster-admins.adoc[leveloffset=+1]
+endif::openshift-rosa[]
+
+ifdef::openshift-dedicated[]
+include::modules/osd-grant-admin-privileges.adoc[leveloffset=+1]
+endif::openshift-dedicated[]

modules/authentication-authorization-common-terms.adoc

@@ -17,8 +17,11 @@ Authorization determines whether the identified user has permissions to perform
 bearer token::
 Bearer token is used to authenticate to API with the header `Authorization: Bearer <token>`.
 
+// In OSD and ROSA, the CCO is managed by Red Hat SRE.
+ifndef::openshift-dedicated,openshift-rosa[]
 Cloud Credential Operator::
 The Cloud Credential Operator (CCO) manages cloud provider credentials as custom resource definitions (CRDs).
+endif::openshift-dedicated,openshift-rosa[]
 
 config map::
 A config map provides a way to inject configuration data into the pods. You can reference the data stored in a config map in a volume of type `ConfigMap`. Applications running in a pod can use this data.
@@ -41,11 +44,15 @@ Keystone is an {rh-openstack-first} project that provides identity, token, catal
 Lightweight directory access protocol (LDAP)::
 LDAP is a protocol that queries user information.
 
+ifndef::openshift-dedicated,openshift-rosa[]
 manual mode::
 In manual mode, a user manages cloud credentials instead of the Cloud Credential Operator (CCO).
+endif::openshift-dedicated,openshift-rosa[]
 
+ifndef::openshift-dedicated,openshift-rosa[]
 mint mode::
 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.
+endif::openshift-dedicated,openshift-rosa[]
 
 namespace::
 A namespace isolates specific system resources that are visible to all processes. Inside a namespace, only processes that are members of that namespace can see those resources.
@@ -62,8 +69,10 @@ The {product-title} control plane includes a built-in OAuth server that determin
 OpenID Connect::
 The OpenID Connect is a protocol to authenticate the users to use single sign-on (SSO) to access sites that use OpenID Providers.
 
+ifndef::openshift-dedicated,openshift-rosa[]
 passthrough mode::
 In passthrough mode, the Cloud Credential Operator (CCO) passes the provided cloud credential to the components that request cloud credentials.
+endif::openshift-dedicated,openshift-rosa[]
 
 pod::
 A pod is the smallest logical unit in Kubernetes. A pod is comprised of one or more containers to run in a worker node.

modules/bound-sa-tokens-configuring-externally.adoc

@@ -8,7 +8,12 @@
 
 .Prerequisites
 
+ifndef::openshift-dedicated,openshift-rosa[]
 * You have access to the cluster as a user with the `cluster-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `dedicated-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
 * You have created a service account. This procedure assumes that the service account is named `build-robot`.
 
 .Procedure

modules/bound-sa-tokens-configuring.adoc

@@ -10,11 +10,17 @@ You can configure pods to request bound service account tokens by using volume p
 
 .Prerequisites
 
+ifndef::openshift-dedicated,openshift-rosa[]
 * You have access to the cluster as a user with the `cluster-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `dedicated-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
 * You have created a service account. This procedure assumes that the service account is named `build-robot`.
 
 .Procedure
 
+ifndef::openshift-dedicated,openshift-rosa[]
 . Optional: Set the service account issuer.
 +
 This step is typically not required if the bound tokens are used only within the cluster.
@@ -92,6 +98,7 @@ $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {en
       sleep 1; \
       done
 ----
+endif::openshift-dedicated,openshift-rosa[]
 
 . Configure a pod to use a bound service account token by using volume projection.
 

modules/ldap-syncing-activedir.adoc

@@ -48,6 +48,12 @@ during search and returned to the client, but not committed to the database.
 .Prerequisites
 
 * Create the configuration file.
+ifndef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `cluster-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `dedicated-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
 
 .Procedure
 

modules/ldap-syncing-augmented-activedir.adoc

@@ -58,6 +58,12 @@ member: cn=Jim,ou=users,dc=example,dc=com
 .Prerequisites
 
 * Create the configuration file.
+ifndef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `cluster-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `dedicated-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
 
 .Procedure
 

modules/ldap-syncing-nesting.adoc

@@ -136,6 +136,12 @@ of https://msdn.microsoft.com/en-us/library/aa746475(v=vs.85).aspx[`LDAP_MATCHIN
 .Prerequisites
 
 * Create the configuration file.
+ifndef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `cluster-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `dedicated-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
 
 .Procedure
 

modules/ldap-syncing-rfc2307-user-defined-error.adoc

@@ -118,6 +118,12 @@ member of a group is out of scope.
 .Prerequisites
 
 * Create the configuration file.
+ifndef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `cluster-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `dedicated-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
 
 .Procedure
 

modules/ldap-syncing-rfc2307-user-defined.adoc

@@ -48,6 +48,12 @@ fine-grained  filtering, use the whitelist / blacklist method.
 .Prerequisites
 
 * Create the configuration file.
+ifndef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `cluster-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `dedicated-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
 
 .Procedure
 

modules/ldap-syncing-rfc2307.adoc

@@ -65,6 +65,12 @@ the group.
 .Prerequisites
 
 * Create the configuration file.
+ifndef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `cluster-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `dedicated-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
 
 .Procedure
 

modules/ldap-syncing-running-all-ldap.adoc

@@ -11,6 +11,12 @@ You can sync all groups from the LDAP server with {product-title}.
 .Prerequisites
 
 * Create a sync configuration file.
+ifndef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `cluster-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `dedicated-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
 
 .Procedure
 

modules/ldap-syncing-running-openshift.adoc

@@ -12,6 +12,12 @@ LDAP server specified in the configuration file.
 .Prerequisites
 
 * Create a sync configuration file.
+ifndef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `cluster-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `dedicated-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
 
 .Procedure
 

modules/ldap-syncing-running-subset.adoc

@@ -21,6 +21,12 @@ present in {product-title}.
 .Prerequisites
 
 * Create a sync configuration file.
+ifndef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `cluster-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `dedicated-admin` role.
+endif::openshift-dedicated,openshift-rosa[]
 
 .Procedure
 

modules/ldap-syncing-running.adoc

@@ -5,7 +5,5 @@
 [id="ldap-syncing-running_{context}"]
 = Running LDAP sync
 
-Once you have created a sync configuration file,
+Once you have created a sync configuration file, you can begin to sync. {product-title} allows administrators to perform a number of different sync types with the same server.
-you can begin to sync. {product-title} allows administrators to perform a number of
-different sync types with the same server.
 

modules/osd-grant-admin-privileges.adoc

@@ -1,6 +1,7 @@
 // Module included in the following assemblies:
 //
 // * osd_getting_started/osd-getting-started.adoc
+// * using-rbac.adoc
 
 :_mod-docs-content-type: PROCEDURE
 [id="osd-grant-admin-privileges_{context}"]

modules/rbac-cluster-role-binding-commands.adoc

@@ -3,7 +3,7 @@
 // * authentication/using-rbac.adoc
 // * post_installation_configuration/preparing-for-users.adoc
 
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
 
 [id="cluster-role-binding-commands_{context}"]
 = Cluster role binding commands

modules/rbac-creating-local-role.adoc

@@ -4,7 +4,7 @@
 // * post_installation_configuration/preparing-for-users.adoc
 
 :_mod-docs-content-type: PROCEDURE
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
 [id="creating-local-role_{context}"]
 = Creating a local role
 

modules/rbac-overview.adoc

@@ -11,11 +11,12 @@ Role-based access control (RBAC) objects determine whether a user is allowed to
 perform a given action within a project.
 
 ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
-Cluster
+Cluster administrators
 endif::[]
-administrators can use the cluster roles and
+ifdef::openshift-dedicated,openshift-rosa[]
-bindings to control who has various access levels to the {product-title}
+Administrators with the `dedicated-admin` role
-platform itself and all projects.
+endif::openshift-dedicated,openshift-rosa[]
+can use the cluster roles and bindings to control who has various access levels to the {product-title} platform itself and all projects.
 
 Developers can use local roles and bindings to control who has access
 to their projects. Note that authorization is a separate step from
@@ -37,7 +38,7 @@ to multiple roles.
 |Bindings |Associations between users and/or groups with a role.
 |===
 
-ifdef::openshift-origin,openshift-enterprise[]
+ifdef::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa[]
 There are two levels of RBAC roles and bindings that control authorization:
 
 [cols="1,4",options="header"]
@@ -102,6 +103,7 @@ every action on every resource in the project.
 
 |`cluster-reader` | A user that can get or view most of the objects but
 cannot modify them.
+
 |`edit` |A user that can modify most objects in a project but does not have the
 power to view or modify roles or bindings.
 
@@ -117,13 +119,7 @@ Be mindful of the difference between local and cluster bindings. For example,
 if you bind the `cluster-admin` role to a user by using a local role binding,
 it might appear that this user has the privileges of a cluster administrator.
 This is not the case. Binding the `cluster-admin` to a user in a project
-grants super administrator privileges for only that
+grants super administrator privileges for only that project to the user. That user has the permissions of the cluster role `admin`, plus a few additional permissions like the ability to edit rate limits, for that project. This binding can be confusing via the web console UI, which does not list cluster role bindings that are bound to true cluster administrators. However, it does list local role bindings that you can use to locally bind `cluster-admin`.
-project to the user. That user has the permissions of the cluster role
-`admin`, plus a few additional permissions like the ability to edit rate limits,
-for that project.
-This binding can be confusing via the web console UI, which does not list
-cluster role bindings that are bound to true cluster administrators. However, it
-does list local role bindings that you can use to locally bind `cluster-admin`.
 
 ////
 If you do, when you upgrade
@@ -175,7 +171,7 @@ apply to the user or their groups.
 . If no matching rule is found, the action is then denied by default.
 
 
-ifdef::openshift-origin,openshift-enterprise[]
+ifdef::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa[]
 
 [TIP]
 ====
@@ -184,33 +180,28 @@ roles at the same time.
 ====
 
 Project administrators can use the CLI to
-endif::openshift-origin,openshift-enterprise[]
+endif::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa[]
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
 view local roles and bindings,
-endif::openshift-enterprise,openshift-webscale,openshift-origin[]
+endif::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
 including a matrix of the verbs and resources each are associated with.
 
-ifdef::openshift-origin,openshift-enterprise[]
+ifdef::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa[]
 [IMPORTANT]
 ====
 The cluster role bound to the project administrator is limited in a project
-through a local binding.
+through a local binding. It is not bound cluster-wide like the cluster roles granted to the *cluster-admin* or *system:admin*.
-It is not bound cluster-wide like the cluster roles granted to the
-*cluster-admin* or *system:admin*.
 
 Cluster roles are roles defined at the cluster level but can be bound either at
 the cluster level or at the project level.
 ====
-endif::openshift-origin,openshift-enterprise[]
+endif::openshift-origin,openshift-enterprise,openshift-dedicated,openshift-rosa[]
 
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
 [id="cluster-role-aggregations_{context}"]
 === Cluster role aggregation
 The default admin, edit, view, and cluster-reader cluster roles support
-link:https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles[cluster role aggregation],
+link:https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles[cluster role aggregation], where the cluster rules for each role are dynamically updated as new rules are created. This feature is relevant only if you extend the Kubernetes API by creating custom resources.
-where the cluster rules for each role are dynamically updated as
-new rules are created. This feature is relevant only if you extend the
-Kubernetes API by creating custom resources.
 
 // NEED NEW LINK TO ASSEMBLY ABOUT making custom resources
 endif::[]

modules/rbac-projects-namespaces.adoc

@@ -54,9 +54,20 @@ Each project scopes its own set of:
 
 |===
 
-Cluster administrators can create projects and delegate administrative rights
+ifndef::openshift-dedicated,openshift-rosa[]
-for the project to any member of the user community. Cluster administrators can
+Cluster administrators
-also allow developers to create their own projects.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+Administrators with the `dedicated-admin` role
+endif::openshift-dedicated,openshift-rosa[]
+can create projects and delegate administrative rights for the project to any member of the user community.
+ifndef::openshift-dedicated,openshift-rosa[]
+Cluster administrators
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+Administrators with the `dedicated-admin` role
+endif::openshift-dedicated,openshift-rosa[]
+can also allow developers to create their own projects.
 
 Developers and administrators can interact with projects by using the CLI or the
 web console.

modules/rbac-viewing-cluster-roles.adoc

@@ -24,7 +24,7 @@ endif::[]
 
 . To view the cluster roles and their associated rule sets:
 +
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
 [source,terminal]
 ----
 $ oc describe clusterrole.rbac
@@ -224,7 +224,7 @@ endif::[]
 . To view the current set of cluster role bindings, which shows the users and
 groups that are bound to various roles:
 +
-ifdef::openshift-enterprise,openshift-webscale,openshift-origin[]
+ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[]
 [source,terminal]
 ----
 $ oc describe clusterrolebinding.rbac

modules/rosa-create-cluster-admins.adoc

@@ -2,6 +2,7 @@
 //
 // * rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-accessing-cluster.adoc
 // * rosa_install_access_delete_clusters/rosa-sts-accessing-cluster.adoc
+// * using-rbac.adoc
 
 
 :_mod-docs-content-type: PROCEDURE

modules/rosa-create-dedicated-cluster-admins.adoc

@@ -2,6 +2,7 @@
 //
 // * rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-accessing-cluster.adoc
 // * rosa_install_access_delete_clusters/rosa-sts-accessing-cluster.adoc
+// * using-rbac.adoc
 
 
 :_mod-docs-content-type: PROCEDURE

modules/security-context-constraints-psa-opting.adoc

@@ -10,7 +10,11 @@ You can enable or disable automatic pod security admission synchronization for m
 
 [IMPORTANT]
 ====
-You cannot enable pod security admission synchronization on some system-created namespaces. For more information, see _Pod security admission synchronization namespace exclusions_.
+You cannot enable pod security admission synchronization on 
+ifndef::openshift-dedicated,openshift-rosa[]
+some
+endif::openshift-dedicated,openshift-rosa[]
+system-created namespaces. For more information, see _Pod security admission synchronization namespace exclusions_.
 ====
 
 .Procedure

modules/security-context-constraints-psa-sync-exclusions.adoc

@@ -7,8 +7,15 @@
 [id="security-context-constraints-psa-sync-exclusions_{context}"]
 = Pod security admission synchronization namespace exclusions
 
+ifndef::openshift-dedicated,openshift-rosa[]
 Pod security admission synchronization is permanently disabled on most system-created namespaces. Synchronization is also initially disabled on user-created `openshift-*` prefixed namespaces, but you can enable synchronization on them later.
+endif::openshift-dedicated,openshift-rosa[]
 
+ifdef::openshift-dedicated,openshift-rosa[]
+Pod security admission synchronization is permanently disabled on system-created namespaces and `openshift-*` prefixed namespaces.
+endif::openshift-dedicated,openshift-rosa[]
+
+ifndef::openshift-dedicated,openshift-rosa[]
 [IMPORTANT]
 ====
 If a pod security admission label (`pod-security.kubernetes.io/<mode>`) is manually modified from the automatically labeled value on a label-synchronized namespace, synchronization is disabled for that label.
@@ -23,6 +30,7 @@ If you force synchronization by adding this label, then any modified pod securit
 
 [discrete]
 == Permanently disabled namespaces
+endif::openshift-dedicated,openshift-rosa[]
 
 Namespaces that are defined as part of the cluster payload have pod security admission synchronization disabled permanently. The following namespaces are permanently disabled:
 
@@ -31,8 +39,12 @@ Namespaces that are defined as part of the cluster payload have pod security adm
 * `kube-system`
 * `kube-public`
 * `openshift`
-* All system-created namespaces that are prefixed with `openshift-`, except for `openshift-operators`
+* All system-created namespaces that are prefixed with `openshift-`
+ifndef::openshift-dedicated,openshift-rosa[]
+, except for `openshift-operators`
+endif::openshift-dedicated,openshift-rosa[]
 
+ifndef::openshift-dedicated,openshift-rosa[]
 [discrete]
 == Initially disabled namespaces
 
@@ -44,3 +56,4 @@ You cannot enable synchronization for any system-created [x-]`openshift-*` names
 ====
 
 If an Operator is installed in a user-created `openshift-*` namespace, synchronization is enabled automatically after a cluster service version (CSV) is created in the namespace. The synchronized label is derived from the permissions of the service accounts in the namespace.
+endif::openshift-dedicated,openshift-rosa[]

modules/tokens-scoping-about.adoc

@@ -12,8 +12,13 @@ For example, a project administrator might want to delegate the
 power to create pods.
 
 A scoped token is a token that identifies as a given user but is limited to
-certain actions by its scope. Only a user with the `cluster-admin` role can create
+certain actions by its scope.
-scoped tokens.
+ifndef::openshift-dedicated,openshift-rosa[]
+Only a user with the `cluster-admin` role can create scoped tokens.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+Only a user with the `dedicated-admin` role can create scoped tokens.
+endif::openshift-dedicated,openshift-rosa[]
 
 Scopes are evaluated by converting the set of scopes for a token into a set of
 `PolicyRules`. Then, the request is matched against those rules. The request

modules/understanding-idp.adoc

@@ -12,6 +12,7 @@
 
 [id="understanding-idp-supported_{context}"]
 == Supported identity providers
+// This section is sourced from authentication/understanding-identity-provider.adoc
 
 You can configure the following types of identity providers:
 
@@ -45,44 +46,3 @@ The htpasswd identity provider option is included only to enable the creation of
 ====
 
 |===
-
-[id="understanding-idp-parameters_{context}"]
-== Identity provider parameters
-
-The following parameters are common to all identity providers:
-
-[cols="2a,8a",options="header"]
-|===
-|Parameter     | Description
-|`name`      | The provider name is prefixed to provider user names to form an
-identity name.
-
-|`mappingMethod`  | Defines how new identities are mapped to users when they log in.
-Enter one of the following values:
-
-claim:: The default value. Provisions a user with the identity's preferred
-user name. Fails if a user with that user name is already mapped to another
-identity.
-lookup:: Looks up an existing identity, user identity mapping, and user,
-but does not automatically provision users or identities. This allows cluster
-administrators to set up identities and users manually, or using an external
-process. Using this method requires you to manually provision users.
-generate:: Provisions a user with the identity's preferred user name. If a
-user with the preferred user name is already mapped to an existing identity, a
-unique user name is generated. For example, `myuser2`. This method should not be
-used in combination with external processes that require exact matches between
-{product-title} user names and identity provider user names, such as LDAP group
-sync.
-add:: Provisions a user with the identity's preferred user name. If a user
-with that user name already exists, the identity is mapped to the existing user,
-adding to any existing identity mappings for the user. Required when multiple
-identity providers are configured that identify the same set of users and map to
-the same user names.
-|===
-
-[NOTE]
-====
-When adding or changing identity providers, you can map identities from the new
-provider to existing users by setting the `mappingMethod` parameter to
-`add`.
-====

osd_install_access_delete_cluster/config-identity-providers.adoc

@@ -9,6 +9,7 @@ toc::[]
 After your {product-title} cluster is created, you must configure identity providers to determine how users log in to access the cluster.
 
 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]

rosa_install_access_delete_clusters/rosa-sts-config-identity-providers.adoc

@@ -11,6 +11,7 @@ After your {product-title} (ROSA) cluster is created, you must configure identit
 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.
 
 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]

rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-config-identity-providers.adoc

@@ -13,6 +13,7 @@ The following topics describe how to configure an identity provider using {clust
 include::snippets/rosa-sts.adoc[]
 
 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]