diff --git a/authentication/index.adoc b/authentication/index.adoc index df8b19d3c250..e3c3decef479 100644 --- a/authentication/index.adoc +++ b/authentication/index.adoc @@ -7,95 +7,11 @@ include::_attributes/common-attributes.adoc[] toc::[] -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, -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -a cluster administrator -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -an administrator with the `dedicated-admin` role -endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -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,openshift-rosa-hcp[] -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,openshift-rosa-hcp[] - -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -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. -+ -[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] -==== -When users send a request for an OAuth token, they must specify either a default or custom OAuth client that receives and uses the token. -==== - -* 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,openshift-rosa-hcp[] - -[id="authorization-overview"] -== About authorization in {product-title} -Authorization involves determining whether the identified user has permissions to perform the requested action. +[role="_abstract"] +Learn about authentication and authorization in {product-title}, and how you can control access to your cluster. -Administrators can define permissions and assign them to users using the xref:../authentication/using-rbac.adoc#authorization-overview_using-rbac[RBAC objects, such as rules, roles, and bindings]. To understand how authorization works in {product-title}, see xref:../authentication/using-rbac.adoc#evaluating-authorization_using-rbac[Evaluating authorization]. - -You can also control access to an {product-title} cluster through xref:../authentication/using-rbac.adoc#rbac-projects-namespaces_using-rbac[projects and namespaces]. - -Along with controlling user access to a cluster, you can also control the actions a pod can perform and the resources it can access using xref:../authentication/managing-security-context-constraints.adoc#managing-pod-security-policies[security context constraints (SCCs)]. - -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,openshift-rosa-hcp[] -* 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,openshift-rosa-hcp[] -ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -* 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,openshift-rosa-hcp[] - -ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -* 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,openshift-rosa-hcp[] - -ifdef::openshift-rosa,openshift-rosa-hcp[] -* 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,openshift-rosa-hcp[] - -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]. +include::modules/authentication-authorization-common-terms.adoc[leveloffset=+1] -* 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. +include::modules/authentication-about-authentication.adoc[leveloffset=+1] -* 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. +include::modules/authentication-about-authorization.adoc[leveloffset=+1] diff --git a/authentication/understanding-identity-provider.adoc b/authentication/understanding-identity-provider.adoc index 0e8bac440876..c87fc89ab3ff 100644 --- a/authentication/understanding-identity-provider.adoc +++ b/authentication/understanding-identity-provider.adoc @@ -15,64 +15,7 @@ The {product-title} master includes a built-in OAuth server. include::modules/identity-provider-overview.adoc[leveloffset=+1] -[id="supported-identity-providers"] -== Supported identity providers - -You can configure the following types of identity providers: - -[cols="2a,8a",options="header"] -|=== - -|Identity provider -|Description - -|xref:../authentication/identity_providers/configuring-htpasswd-identity-provider.adoc#configuring-htpasswd-identity-provider[htpasswd] -|Configure the `htpasswd` identity provider to validate user names and passwords -against a flat file generated using -link:http://httpd.apache.org/docs/2.4/programs/htpasswd.html[`htpasswd`]. - -|xref:../authentication/identity_providers/configuring-keystone-identity-provider.adoc#configuring-keystone-identity-provider[Keystone] -|Configure the `keystone` identity provider to integrate -your {product-title} cluster with Keystone to enable shared authentication with -an OpenStack Keystone v3 server configured to store users in an internal -database. - -|xref:../authentication/identity_providers/configuring-ldap-identity-provider.adoc#configuring-ldap-identity-provider[LDAP] -|Configure the `ldap` identity provider to validate user names and passwords -against an LDAPv3 server, using simple bind authentication. - -|xref:../authentication/identity_providers/configuring-basic-authentication-identity-provider.adoc#configuring-basic-authentication-identity-provider[Basic authentication] -|Configure a `basic-authentication` identity provider for users to log in to -{product-title} with credentials validated against a remote identity provider. -Basic authentication is a generic backend integration mechanism. - -|xref:../authentication/identity_providers/configuring-request-header-identity-provider.adoc#configuring-request-header-identity-provider[Request header] -|Configure a `request-header` identity provider to identify users from request -header values, such as `X-Remote-User`. It is typically used in combination with -an authenticating proxy, which sets the request header value. - -|xref:../authentication/identity_providers/configuring-github-identity-provider.adoc#configuring-github-identity-provider[GitHub or GitHub Enterprise] -|Configure a `github` identity provider to validate user names and passwords -against GitHub or GitHub Enterprise's OAuth authentication server. - -|xref:../authentication/identity_providers/configuring-gitlab-identity-provider.adoc#configuring-gitlab-identity-provider[GitLab] -|Configure a `gitlab` identity provider to use -link:https://gitlab.com/[GitLab.com] or any other GitLab instance as an identity -provider. - -|xref:../authentication/identity_providers/configuring-google-identity-provider.adoc#configuring-google-identity-provider[Google] -|Configure a `google` identity provider using -link:https://developers.google.com/identity/protocols/OpenIDConnect[Google's OpenID Connect integration]. - -|xref:../authentication/identity_providers/configuring-oidc-identity-provider.adoc#configuring-oidc-identity-provider[OpenID Connect] -|Configure an `oidc` identity provider to integrate with an OpenID Connect -identity provider using an -link:http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth[Authorization Code Flow]. - -|=== - -Once an identity provider has been defined, you can -xref:../authentication/using-rbac.adoc#authorization-overview_using-rbac[use RBAC to define and apply permissions]. +include::modules/identity-provider-supported-types.adoc[leveloffset=+1] include::modules/authentication-remove-kubeadmin.adoc[leveloffset=+1] diff --git a/modules/authentication-about-authentication.adoc b/modules/authentication-about-authentication.adoc new file mode 100644 index 000000000000..7486deb245ac --- /dev/null +++ b/modules/authentication-about-authentication.adoc @@ -0,0 +1,53 @@ +// Module included in the following assemblies: +// +// * authentication/index.adoc +// +// This file is a navigation file - xrefs are allowed in this type of module, but it must only ever be included from one location + +:_mod-docs-content-type: REFERENCE +[id="authentication-overview_{context}"] += About authentication in {product-title} + +[role="_abstract"] +To control access to an {product-title} cluster, +ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +a cluster administrator +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +an administrator with the `dedicated-admin` role +endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +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,openshift-rosa-hcp[] +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,openshift-rosa-hcp[] + +ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +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_understanding-identity-provider[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. ++ +[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] +==== +When users send a request for an OAuth token, they must specify either a default or custom OAuth client that receives and uses the token. +==== + +* 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,openshift-rosa-hcp[] diff --git a/modules/authentication-about-authorization.adoc b/modules/authentication-about-authorization.adoc new file mode 100644 index 000000000000..279772928df7 --- /dev/null +++ b/modules/authentication-about-authorization.adoc @@ -0,0 +1,54 @@ +// Module included in the following assemblies: +// +// * authentication/index.adoc +// +// This file is a navigation file - xrefs are allowed in this type of module, but it must only ever be included from one location + +:_mod-docs-content-type: REFERENCE +[id="authorization-overview_{context}"] += About authorization in {product-title} + +[role="_abstract"] +Authorization involves determining whether the identified user has permissions to perform the requested action. + +Administrators can define permissions and assign them to users using the xref:../authentication/using-rbac.adoc#authorization-overview_using-rbac[RBAC objects, such as rules, roles, and bindings]. To understand how authorization works in {product-title}, see xref:../authentication/using-rbac.adoc#evaluating-authorization_using-rbac[Evaluating authorization]. + +You can also control access to an {product-title} cluster through xref:../authentication/using-rbac.adoc#rbac-projects-namespaces_using-rbac[projects and namespaces]. + +Along with controlling user access to a cluster, you can also control the actions a pod can perform and the resources it can access using xref:../authentication/managing-security-context-constraints.adoc#managing-pod-security-policies[security context constraints (SCCs)]. + +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,openshift-rosa-hcp[] +* 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,openshift-rosa-hcp[] +ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +* 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,openshift-rosa-hcp[] + +ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] +* 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,openshift-rosa-hcp[] + +ifdef::openshift-rosa,openshift-rosa-hcp[] +* 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,openshift-rosa-hcp[] + +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. diff --git a/modules/authentication-authorization-common-terms.adoc b/modules/authentication-authorization-common-terms.adoc index 467f66138327..b4bb5ff02957 100644 --- a/modules/authentication-authorization-common-terms.adoc +++ b/modules/authentication-authorization-common-terms.adoc @@ -6,6 +6,7 @@ [id="openshift-auth-common-terms_{context}"] = Glossary of common terms for {product-title} authentication and authorization +[role="_abstract"] This glossary defines common terms that are used in {product-title} authentication and authorization. authentication:: @@ -80,7 +81,7 @@ In passthrough mode, the Cloud Credential Operator (CCO) passes the provided clo 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. +A pod is the smallest logical unit in Kubernetes. A pod consists of one or more containers to run in a worker node. regular users:: Users that are created automatically in the cluster upon first login or via the API. diff --git a/modules/identity-provider-supported-types.adoc b/modules/identity-provider-supported-types.adoc new file mode 100644 index 000000000000..468313523f15 --- /dev/null +++ b/modules/identity-provider-supported-types.adoc @@ -0,0 +1,66 @@ +// Module included in the following assemblies: +// +// * authentication/understanding-identity-provider.adoc +// +// This module was created from assembly body content during a CQA pass; it retains the xrefs it inherited per doc_guidelines.adoc's exception for modules split from an assembly, and must only ever be included from one location. + +:_mod-docs-content-type: REFERENCE +[id="supported-identity-providers_{context}"] += Supported identity providers + +[role="_abstract"] +You can configure the following types of identity providers: + +[cols="2a,8a",options="header"] +|=== + +|Identity provider +|Description + +|xref:../authentication/identity_providers/configuring-htpasswd-identity-provider.adoc#configuring-htpasswd-identity-provider[htpasswd] +|Configure the `htpasswd` identity provider to validate user names and passwords +against a flat file generated using +link:http://httpd.apache.org/docs/2.4/programs/htpasswd.html[`htpasswd`]. + +|xref:../authentication/identity_providers/configuring-keystone-identity-provider.adoc#configuring-keystone-identity-provider[Keystone] +|Configure the `keystone` identity provider to integrate +your {product-title} cluster with Keystone to enable shared authentication with +an OpenStack Keystone v3 server configured to store users in an internal +database. + +|xref:../authentication/identity_providers/configuring-ldap-identity-provider.adoc#configuring-ldap-identity-provider[LDAP] +|Configure the `ldap` identity provider to validate user names and passwords +against an LDAPv3 server, using simple bind authentication. + +|xref:../authentication/identity_providers/configuring-basic-authentication-identity-provider.adoc#configuring-basic-authentication-identity-provider[Basic authentication] +|Configure a `basic-authentication` identity provider for users to log in to +{product-title} with credentials validated against a remote identity provider. +Basic authentication is a generic backend integration mechanism. + +|xref:../authentication/identity_providers/configuring-request-header-identity-provider.adoc#configuring-request-header-identity-provider[Request header] +|Configure a `request-header` identity provider to identify users from request +header values, such as `X-Remote-User`. It is typically used in combination with +an authenticating proxy, which sets the request header value. + +|xref:../authentication/identity_providers/configuring-github-identity-provider.adoc#configuring-github-identity-provider[GitHub or GitHub Enterprise] +|Configure a `github` identity provider to validate user names and passwords +against GitHub or GitHub Enterprise's OAuth authentication server. + +|xref:../authentication/identity_providers/configuring-gitlab-identity-provider.adoc#configuring-gitlab-identity-provider[GitLab] +|Configure a `gitlab` identity provider to use +link:https://gitlab.com/[GitLab.com] or any other GitLab instance as an identity +provider. + +|xref:../authentication/identity_providers/configuring-google-identity-provider.adoc#configuring-google-identity-provider[Google] +|Configure a `google` identity provider using +link:https://developers.google.com/identity/protocols/OpenIDConnect[Google's OpenID Connect integration]. + +|xref:../authentication/identity_providers/configuring-oidc-identity-provider.adoc#configuring-oidc-identity-provider[OpenID Connect] +|Configure an `oidc` identity provider to integrate with an OpenID Connect +identity provider using an +link:http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth[Authorization Code Flow]. + +|=== + +Once an identity provider has been defined, you can +xref:../authentication/using-rbac.adoc#authorization-overview_using-rbac[use RBAC to define and apply permissions]. diff --git a/post_installation_configuration/day_2_core_cnf_clusters/troubleshooting/troubleshooting-security.adoc b/post_installation_configuration/day_2_core_cnf_clusters/troubleshooting/troubleshooting-security.adoc index e7e17461ad40..f8b752c94c1e 100644 --- a/post_installation_configuration/day_2_core_cnf_clusters/troubleshooting/troubleshooting-security.adoc +++ b/post_installation_configuration/day_2_core_cnf_clusters/troubleshooting/troubleshooting-security.adoc @@ -13,4 +13,4 @@ include::modules/troubleshooting-security-authentication.adoc[leveloffset=+1] [role="_additional-resources"] .Additional resources -* xref:../../../authentication/understanding-identity-provider.adoc#supported-identity-providers[Supported identity providers] \ No newline at end of file +* xref:../../../authentication/understanding-identity-provider.adoc#supported-identity-providers_understanding-identity-provider[Supported identity providers] \ No newline at end of file diff --git a/welcome/learn_more_about_openshift.adoc b/welcome/learn_more_about_openshift.adoc index f365fc50157a..c7245da161f2 100644 --- a/welcome/learn_more_about_openshift.adoc +++ b/welcome/learn_more_about_openshift.adoc @@ -150,7 +150,7 @@ Managing cluster components:: | xref:../authentication/impersonating-system-admin.adoc#impersonating-system-admin[Impersonating the system:admin user] | xref:../authentication/understanding-authentication.adoc#understanding-authentication[Manage authentication] -| xref:../authentication/understanding-identity-provider.adoc#supported-identity-providers[Supported identity providers] +| xref:../authentication/understanding-identity-provider.adoc#supported-identity-providers_understanding-identity-provider[Supported identity providers] | Manage xref:../security/certificates/replacing-default-ingress-certificate.adoc#replacing-default-ingress[Ingress], xref:../security/certificates/api-server.adoc#api-server-certificates[API server], and xref:../security/certificates/service-serving-certificate.adoc#add-service-serving[service] certificates | xref:../networking/network_security/network-policy-apis.adoc#network-policy-apis[Network security]