Merge pull request #27398 from bergerhoffer/term-updates-auth

Terminology style updates for auth book

Author: bergerhoffer

_topic_map.yml

@@ -603,7 +603,7 @@ Topics:
   File: tokens-scoping
 - Name: Using bound service account tokens
   File: bound-service-account-tokens
-- Name: Managing Security Context Constraints
+- Name: Managing security context constraints
   File: managing-security-context-constraints
   Distros: openshift-enterprise,openshift-webscale,openshift-origin
 - Name: Impersonating the system:admin user

authentication/identity_providers/configuring-basic-authentication-identity-provider.adoc

@@ -1,12 +1,12 @@
 [id="configuring-basic-authentication-identity-provider"]
-= Configuring an basic authentication identity provider
+= Configuring a basic authentication identity provider
 include::modules/common-attributes.adoc[]
 :context: configuring-basic-authentication-identity-provider
 toc::[]
 
 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.
+Basic authentication is a generic back-end integration mechanism.
 
 include::modules/identity-provider-overview.adoc[leveloffset=+1]
 

authentication/managing-security-context-constraints.adoc

@@ -1,5 +1,5 @@
 [id="managing-pod-security-policies"]
-= Managing Security Context Constraints
+= Managing security context constraints
 include::modules/common-attributes.adoc[]
 :context: configuring-internal-oauth
 toc::[]

modules/bound-sa-tokens-configuring.adoc

@@ -18,7 +18,7 @@ You can configure pods to request bound service account tokens by using volume p
 +
 This step is typically not required if the bound tokens are used only within the cluster.
 
-.. Edit the `cluster` authentication object:
+.. Edit the `cluster` `Authentication` object:
 +
 [source,terminal]
 ----

modules/identity-provider-about-basic-authentication.adoc

@@ -5,7 +5,7 @@
 [id="identity-provider-about-basic-authentication_{context}"]
 = About basic authentication
 
-Basic authentication is a generic backend integration mechanism that allows
+Basic authentication is a generic back-end integration mechanism that allows
 users to log in to {product-title} with credentials validated against a remote
 identity provider.
 

modules/identity-provider-about-request-header.adoc

@@ -70,7 +70,7 @@ https://access.redhat.com/support/offerings/techpreview/.
 
 endif::[]
 
-`oc` supports the Security Support Provider Interface (SSPI) to allow for SSO
+The OpenShift CLI (`oc`) supports the Security Support Provider Interface (SSPI) to allow for SSO
 flows on Microsft Windows. If you use the request header identity provider with a
 GSSAPI-enabled proxy to connect an Active Directory server to {product-title},
 users can automatically authenticate to {product-title} by using the `oc`  command

modules/identity-provider-add.adoc

@@ -34,7 +34,7 @@ users can authenticate.
 .Prerequisites
 
 * Create an {product-title} cluster.
-* Create the Custom Resource (CR) for your identity providers.
+* Create the custom resource (CR) for your identity providers.
 * You must be logged in as an administrator.
 
 .Procedure

modules/identity-provider-apache-custom-proxy-configuration.adoc

@@ -29,6 +29,6 @@ proxy to `\https://<namespace_route>/oauth/authorize/approve?...`.
 
 [NOTE]
 ====
-The `\https://<namespace_route>` address is the Route to the OAuth server and
+The `\https://<namespace_route>` address is the route to the OAuth server and
 can be obtained by running `oc get route -n openshift-authentication`.
 ====

modules/identity-provider-basic-authentication-CR.adoc

@@ -5,7 +5,7 @@
 [id="identity-provider-basic-authentication-CR_{context}"]
 = Sample basic authentication CR
 
-The following Custom Resource (CR) shows the parameters and acceptable values for an
+The following custom resource (CR) shows the parameters and acceptable values for a
 basic authentication identity provider.
 
 .Basic authentication CR
@@ -32,12 +32,12 @@ spec:
 ----
 <1> This provider name is prefixed to the returned user ID to form an identity
 name.
-<2> Controls how mappings are established between this provider's identities and user objects.
+<2> Controls how mappings are established between this provider's identities and `User` objects.
 <3> URL accepting credentials in Basic authentication headers.
-<4> Optional: Reference to an {product-title} ConfigMap containing the
+<4> Optional: Reference to an {product-title} `ConfigMap` object containing the
 PEM-encoded certificate authority bundle to use in validating server
 certificates for the configured URL.
-<5> Optional: Reference to an {product-title} Secret containing the client
+<5> Optional: Reference to an {product-title} `Secret` object containing the client
 certificate to present when making requests to the configured URL.
-<6> Reference to an {product-title} Secret containing the key for the
+<6> Reference to an {product-title} `Secret` object containing the key for the
 client certificate. Required if `tlsClientCert` is specified.

modules/identity-provider-config-map.adoc

@@ -8,15 +8,15 @@
 // * authentication/identity_providers/configuring-request-header-identity-provider.adoc
 
 [id="identity-provider-creating-configmap_{context}"]
-= Creating a ConfigMap
+= Creating a config map
 
-Identity providers use {product-title} ConfigMaps in the `openshift-config`
+Identity providers use {product-title} `ConfigMap` objects in the `openshift-config`
 namespace to contain the certificate authority bundle. These are primarily
 used to contain certificate bundles needed by the identity provider.
 
-* Define an {product-title} ConfigMap containing the
+* Define an {product-title} `ConfigMap` object containing the
 certificate authority by using the following command. The certificate
-authority must be stored in the `ca.crt` key of the ConfigMap.
+authority must be stored in the `ca.crt` key of the `ConfigMap` object.
 +
 [source,terminal]
 ----