Merge pull request #27852 from bergerhoffer/pr-27398-cp-45

Terminology style updates for auth book

_topic_map.yml

@@ -575,7 +575,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]
 ----

modules/identity-provider-configuring-apache-request-header.adoc

@@ -21,20 +21,20 @@ You must have the following packages installed on your local machine:
 ** `mod_auth_gssapi`
 
 * Generate a CA for validating requests that submit the trusted header. Define
-an {product-title} ConfigMap containing the CA. This is done by running:
+an {product-title} `ConfigMap` object containing the CA. This is done by running:
 +
 [source,terminal]
 ----
 $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config
 ----
 +
-The CA must be stored in the `ca.crt` key of the ConfigMap.
+The CA must be stored in the `ca.crt` key of the `ConfigMap` object.
 
 * Generate a client certificate for the proxy. You can generate this certificate
 by using any x509 certificate tooling. The client certificate must be signed by
 the CA you generated for validating requests that submit the trusted header.
 
-* Create the Custom Resource (CR) for your identity providers.
+* Create the custom resource (CR) for your identity providers.
 
 .Procedure
 
@@ -139,11 +139,11 @@ RequestHeader unset X-Remote-User
 +
 [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`.
 ====
 
-. Update the `identityProviders` stanza in the Custom Resource (CR):
+. Update the `identityProviders` stanza in the custom resource (CR):
 +
 [source,yaml]
 ----
@@ -192,7 +192,7 @@ requesting a token without the certificate:
 +
 Copy the `challengeURL` redirect to use in the next step.
 
-.. Run this command to show a 401 response with a `WWW-Authenticate` basic
+.. Run this command to show a `401` response with a `WWW-Authenticate` basic
 challenge, a negotiate challenge, or both challenges:
 +
 [source,terminal]

modules/identity-provider-default-CR.adoc

@@ -6,7 +6,7 @@
 [id="identity-provider-default-CR_{context}"]
 = Sample identity provider CR
 
-The following Custom Resource (CR) shows the parameters and default
+The following custom resource (CR) shows the parameters and default
 values that you use to configure an identity provider. This example
 uses the HTPasswd identity provider.
 
@@ -30,6 +30,6 @@ spec:
 <1> This provider name is prefixed to provider user names to form an
 identity name.
 <2> Controls how mappings are established between this provider's
-identities and user objects.
+identities and `User` objects.
 <3> An existing secret containing a file generated using
 link:http://httpd.apache.org/docs/2.4/programs/htpasswd.html[`htpasswd`].

modules/identity-provider-github-CR.adoc

@@ -5,7 +5,7 @@
 [id="identity-provider-github-CR_{context}"]
 = Sample GitHub CR
 
-The following Custom Resource (CR) shows the parameters and acceptable values for a
+The following custom resource (CR) shows the parameters and acceptable values for a
 GitHub identity provider.
 
 .GitHub CR
@@ -37,20 +37,20 @@ spec:
 ----
 <1> This provider name is prefixed to the GitHub numeric user ID to form an
 identity name. It is also used to build the callback URL.
-<2> Controls how mappings are established between this provider's identities and user objects.
-<3> Optional: Reference to an {product-title} ConfigMap containing the
+<2> Controls how mappings are established between this provider's identities and `User` objects.
+<3> 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. Only for use in GitHub Enterprise
 with a non-publicly trusted root certificate.
 <4> The client ID of a
 link:https://github.com/settings/applications/new[registered GitHub OAuth
 application]. The application must be configured with a callback URL of
 `\https://oauth-openshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name>`.
-<5> Reference to an {product-title} Secret containing the client secret
+<5> Reference to an {product-title} `Secret` object containing the client secret
 issued by GitHub.
 <6> For GitHub Enterprise, you must provide the host name of your instance, such as
 `example.com`. This value must match the GitHub Enterprise `hostname` value in
-in the *_/setup/settings_* file and cannot include a port number. If this
+in the `/setup/settings` file and cannot include a port number. If this
 value is not set, then either `teams` or `organizations` must be defined.
 For GitHub, omit this parameter.
 <7> The list of organizations. Either the `organizations` or `teams` field must be set unless the `hostname` field is set, or if `mappingMethod` is set to `lookup`. Cannot be used in combination with the `teams` field.

modules/identity-provider-gitlab-CR.adoc

@@ -5,7 +5,7 @@
 [id="identity-provider-gitlab-CR_{context}"]
 = Sample GitLab CR
 
-The following Custom Resource (CR) shows the parameters and acceptable values for a
+The following custom resource (CR) shows the parameters and acceptable values for a
 GitLab identity provider.
 
 .GitLab CR
@@ -31,15 +31,15 @@ spec:
 ----
 <1> This provider name is prefixed to the GitLab numeric user ID to form an
 identity name. It is also used to build the callback URL.
-<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> The client ID of a
 link:https://docs.gitlab.com/ce/api/oauth2.html[registered GitLab OAuth application].
 The application must be configured with a callback URL of
 `\https://oauth-openshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name>`.
-<4> Reference to an {product-title} Secret containing the client secret
+<4> Reference to an {product-title} `Secret` object containing the client secret
 issued by GitLab.
 <5> The host URL of a GitLab provider. This could either be `\https://gitlab.com/`
 or any other self hosted instance of GitLab.
-<6> Optional: Reference to an {product-title} ConfigMap containing the 
+<6> 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.

modules/identity-provider-google-CR.adoc

@@ -5,7 +5,7 @@
 [id="identity-provider-google-CR_{context}"]
 = Sample Google CR
 
-The following Custom Resource (CR) shows the parameters and acceptable
+The following custom resource (CR) shows the parameters and acceptable
 values for a Google identity provider.
 
 .Google CR
@@ -29,11 +29,11 @@ spec:
 ----
 <1> This provider name is prefixed to the Google numeric user ID to form an
 identity name. It is also used to build the redirect URL.
-<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> The client ID of a link:https://console.developers.google.com/[registered
 Google project]. The project must be configured with a redirect URI of
 `\https://oauth-openshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name>`.
-<4> Reference to an {product-title} Secret containing the client secret
+<4> Reference to an {product-title} `Secret` object containing the client secret
 issued by Google.
 <5> A
 link:https://developers.google.com/identity/protocols/OpenIDConnect#hd-param[hosted domain]

modules/identity-provider-htpasswd-CR.adoc

@@ -5,7 +5,7 @@
 [id="identity-provider-htpasswd-CR_{context}"]
 = Sample HTPasswd 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 an
 HTPasswd identity provider.
 
 .HTPasswd CR
@@ -27,6 +27,6 @@ spec:
 ----
 <1> This provider name is prefixed to provider user names 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> An existing secret containing a file generated using
 link:http://httpd.apache.org/docs/2.4/programs/htpasswd.html[`htpasswd`].

modules/identity-provider-htpasswd-secret.adoc

@@ -14,7 +14,7 @@ contains the HTPasswd user file.
 
 .Procedure
 
-* Create an {product-title} Secret that contains the HTPasswd users file.
+* Create an {product-title} `Secret` object that contains the HTPasswd users file.
 +
 [source,terminal]
 ----

modules/identity-provider-htpasswd-update-users.adoc

@@ -9,14 +9,14 @@ You can add or remove users from an existing HTPasswd identity provider.
 
 .Prerequisites
 
-* You have created a secret that contains the HTPasswd user file. This procedure assumes that it is named `htpass-secret`.
+* You have created a `Secret` object that contains the HTPasswd user file. This procedure assumes that it is named `htpass-secret`.
 * You have configured an HTPasswd identity provider. This procedure assumes that it is named `my_htpasswd_provider`.
 * You have access to the `htpasswd` utility. On Red Hat Enterprise Linux this is available by installing the `httpd-tools` package.
 * You have cluster administrator privileges.
 
 .Procedure
 
-. Retrieve the HTPasswd file from the `htpass-secret` secret and save the file to your file system:
+. Retrieve the HTPasswd file from the `htpass-secret` `Secret` object and save the file to your file system:
 +
 [source,terminal]
 ----
@@ -51,7 +51,7 @@ $ htpasswd -D users.htpasswd <username>
 Deleting password for user <username>
 ----
 
-. Replace the `htpass-secret` secret with the updated users in the `users.htpasswd` file:
+. Replace the `htpass-secret` `Secret` object with the updated users in the `users.htpasswd` file:
 +
 [source,terminal]
 ----
@@ -60,7 +60,7 @@ $ oc create secret generic htpass-secret --from-file=htpasswd=users.htpasswd --d
 
 . If you removed one or more users, you must additionally remove existing resources for each user.
 
-.. Delete the user:
+.. Delete the `User` object:
 +
 [source,terminal]
 ----
@@ -75,7 +75,7 @@ user.user.openshift.io "<username>" deleted
 +
 Be sure to remove the user, otherwise the user can continue using their token as long as it has not expired.
 
-.. Delete the identity for the user:
+.. Delete the `Identity` object for the user:
 +
 [source,terminal]
 ----

modules/identity-provider-keystone-CR.adoc

@@ -5,7 +5,7 @@
 [id="identity-provider-keystone-CR_{context}"]
 = Sample Keystone CR
 
-The following Custom Resource (CR) shows the parameters and acceptable values for a
+The following custom resource (CR) shows the parameters and acceptable values for a
 Keystone identity provider.
 
 .Keystone CR
@@ -32,14 +32,14 @@ spec:
         name: client-key-secret
 ----
 <1> This provider name is prefixed to provider user names 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> Keystone domain name. In Keystone, usernames are domain-specific. Only a single domain is supported.
 <4> The URL to use to connect to the Keystone server (required). This must
 use https.
-<5> Optional: Reference to an {product-title} ConfigMap containing the
+<5> 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.
-<6> Optional: Reference to an {product-title} Secret containing the client
+<6> Optional: Reference to an {product-title} `Secret` object containing the client
 certificate to present when making requests to the configured URL.
-<7> Reference to an {product-title} Secret containing the key for the
+<7> Reference to an {product-title} `Secret` object containing the key for the
 client certificate. Required if `tlsClientCert` is specified.