openshift · bergerhoffer · Dec 3, 2020 · Nov 18, 2020
diff --git a/modules/about-etcd-encryption.adoc b/modules/about-etcd-encryption.adoc
@@ -11,7 +11,7 @@ By default, etcd data is not encrypted in {product-title}. You can enable etcd e
 When you enable etcd encryption, the following OpenShift API server and Kubernetes API server resources are encrypted:
 
 * Secrets
-* ConfigMaps
+* Config maps
 * Routes
 * OAuth access tokens
 * OAuth authorize tokens

diff --git a/modules/auth-allowing-javascript-access-api-server.adoc b/modules/auth-allowing-javascript-access-api-server.adoc
@@ -17,7 +17,7 @@ to allow.
 
 .Procedure
 
-. Edit the API servers resource:
+. Edit the `APIServer` resource:
 +
 [source,terminal]
 ----

diff --git a/modules/builds-adding-input-secrets-configmaps.adoc b/modules/builds-adding-input-secrets-configmaps.adoc
@@ -3,25 +3,25 @@
 // * builds/creating-build-inputs.adoc
 
 [id="builds-adding-input-secrets-configmaps_{context}"]
-= Adding input secrets and ConfigMaps
+= Adding input secrets and config maps
 
-In some scenarios, build operations require credentials or other configuration data to access dependent resources, but it is undesirable for that information to be placed in source control. You can define input secrets and input ConfigMaps for this purpose.
+In some scenarios, build operations require credentials or other configuration data to access dependent resources, but it is undesirable for that information to be placed in source control. You can define input secrets and input config maps for this purpose.
 
 .Procedure
 
-To add an input secret, ConfigMap, or both to an existing `BuildConfig`:
+To add an input secret, config maps, or both to an existing `BuildConfig` object:
 
-. Create the ConfigMap, if it does not exist:
+. Create the `ConfigMap` object, if it does not exist:
 +
 [source,terminal]
 ----
 $ oc create configmap settings-mvn \
     --from-file=settings.xml=<path/to/settings.xml>
 ----
 +
-This creates a new ConfigMap named `settings-mvn`, which contains the plain text content of the `settings.xml` file.
+This creates a new config map named `settings-mvn`, which contains the plain text content of the `settings.xml` file.
 
-. Create the secret, if it does not exist:
+. Create the `Secret` object, if it does not exist:
 +
 [source,terminal]
 ----
@@ -31,8 +31,8 @@ $ oc create secret generic secret-mvn \
 +
 This creates a new secret named `secret-mvn`, which contains the base64 encoded content of the `id_rsa` private key.
 
-. Add the ConfigMap and secret to the `source` section in the existing
-`BuildConfig`:
+. Add the config map and secret to the `source` section in the existing
+`BuildConfig` object:
 +
 [source,yaml]
 ----
@@ -48,7 +48,7 @@ source:
         name: secret-mvn
 ----
 
-To include the secret and ConfigMap in a new `BuildConfig`, run the following
+To include the secret and config map in a new `BuildConfig` object, run the following
 command:
 
 [source,terminal]
@@ -77,7 +77,7 @@ source:
       destinationDir: ".ssh"
 ----
 
-You can also specify the destination directory when creating a new `BuildConfig`:
+You can also specify the destination directory when creating a new `BuildConfig` object:
 
 [source,terminal]
 ----

diff --git a/modules/builds-input-secrets-configmaps.adoc b/modules/builds-input-secrets-configmaps.adoc
@@ -3,9 +3,9 @@
 // * builds/creating-build-inputs.adoc
 
 [id="builds-input-secrets-configmaps_{context}"]
-= Input Secrets and ConfigMaps
+= Input secrets and config maps
 
-In some scenarios, build operations require credentials or other configuration data to access dependent resources, but it is undesirable for that information to be placed in source control. You can define input secrets and input ConfigMaps for this purpose.
+In some scenarios, build operations require credentials or other configuration data to access dependent resources, but it is undesirable for that information to be placed in source control. You can define input secrets and input config maps for this purpose.
 
 For example, when building a Java application with Maven, you can set up a private mirror of Maven Central or JCenter that is accessed by private keys. To download libraries from that private mirror, you have to supply the
 following:

diff --git a/modules/customize-certificates-add-service-serving-apiservice.adoc b/modules/customize-certificates-add-service-serving-apiservice.adoc
@@ -3,33 +3,33 @@
 // * security/certificates/service-serving-certificate.adoc
 
 [id="add-service-certificate-apiservice_{context}"]
-= Add the service CA bundle to an APIService
+= Add the service CA bundle to an API service
 
-You can annotate an APIService with `service.beta.openshift.io/inject-cabundle=true` to have its `spec.caBundle` field populated with the service CA bundle. This allows the Kubernetes API server to validate the service CA certificate used to secure the targeted endpoint.
+You can annotate an `APIService` object with `service.beta.openshift.io/inject-cabundle=true` to have its `spec.caBundle` field populated with the service CA bundle. This allows the Kubernetes API server to validate the service CA certificate used to secure the targeted endpoint.
 
 .Procedure
 
-. Annotate the APIService with `service.beta.openshift.io/inject-cabundle=true`:
+. Annotate the API service with `service.beta.openshift.io/inject-cabundle=true`:
 +
 [source,terminal]
 ----
-$ oc annotate apiservice <apiservice-name> \//<1>
+$ oc annotate apiservice <api_service_name> \//<1>
      service.beta.openshift.io/inject-cabundle=true
 ----
-<1> Replace `<apiservice-name>` with the name of the APIService to annotate.
+<1> Replace `<api_service_name>` with the name of the API service to annotate.
 +
-For example, use the following command to annotate the APIService `foo`:
+For example, use the following command to annotate the API service `test1`:
 +
 [source,terminal]
 ----
-$ oc annotate apiservice foo service.beta.openshift.io/inject-cabundle=true
+$ oc annotate apiservice test1 service.beta.openshift.io/inject-cabundle=true
 ----
 
-. View the APIService to ensure that the service CA bundle has been injected:
+. View the API service to ensure that the service CA bundle has been injected:
 +
 [source,terminal]
 ----
-$ oc get apiservice <apiservice-name> -o yaml
+$ oc get apiservice <api_service_name> -o yaml
 ----
 +
 The CA bundle is displayed in the `spec.caBundle` field in the YAML output:

diff --git a/modules/customize-certificates-add-service-serving-configmap.adoc b/modules/customize-certificates-add-service-serving-configmap.adoc
@@ -3,51 +3,51 @@
 // * security/certificates/service-serving-certificate.adoc
 
 [id="add-service-certificate-configmap_{context}"]
-= Add the service CA bundle to a ConfigMap
+= Add the service CA bundle to a config map
 
-A Pod can access the service CA certificate by mounting a ConfigMap that
+A Pod can access the service CA certificate by mounting a `ConfigMap` object that
 is annotated with `service.beta.openshift.io/inject-cabundle=true`.
 Once annotated, the cluster automatically injects the service CA
-certificate into the `service-ca.crt` key on the ConfigMap. Access to
+certificate into the `service-ca.crt` key on the config map. Access to
 this CA certificate allows TLS clients to verify connections to
 services using service serving certificates.
 
 [IMPORTANT]
 ====
-After adding this annotation to a ConfigMap all existing data in it is
-deleted. It is recommended to use a separate ConfigMap to contain the
-`service-ca.crt`, instead of using the same ConfigMap that stores your
-Pod's configuration.
+After adding this annotation to a config map all existing data in it is
+deleted. It is recommended to use a separate config map to contain the
+`service-ca.crt`, instead of using the same config map that stores your
+pod configuration.
 ====
 
 .Procedure
 
-. Annotate the ConfigMap with `service.beta.openshift.io/inject-cabundle=true`:
+. Annotate the config map with `service.beta.openshift.io/inject-cabundle=true`:
 +
 [source,terminal]
 ----
-$ oc annotate configmap <configmap-name> \//<1>
+$ oc annotate configmap <config_map_name> \//<1>
      service.beta.openshift.io/inject-cabundle=true
 ----
-<1> Replace `<configmap-name>` with the name of the ConfigMap to annotate.
+<1> Replace `<config_map_name>` with the name of the config map to annotate.
 +
 [NOTE]
 ====
-Explicitly referencing the `service-ca.crt` key in a volumeMount will prevent a Pod from starting until the ConfigMap has been injected with the CA bundle. This behavior can be overridden by setting the `optional` field to `true` for the volume's serving certificate configuration.
+Explicitly referencing the `service-ca.crt` key in a volume mount will prevent a pod from starting until the config map has been injected with the CA bundle. This behavior can be overridden by setting the `optional` field to `true` for the volume's serving certificate configuration.
 ====
 +
-For example, use the following command to annotate the ConfigMap `foo`:
+For example, use the following command to annotate the config map `test1`:
 +
 [source,terminal]
 ----
-$ oc annotate configmap foo service.beta.openshift.io/inject-cabundle=true
+$ oc annotate configmap test1 service.beta.openshift.io/inject-cabundle=true
 ----
 
-. View the ConfigMap to ensure that the service CA bundle has been injected:
+. View the config map to ensure that the service CA bundle has been injected:
 +
 [source,terminal]
 ----
-$ oc get configmap <configmap-name> -o yaml
+$ oc get configmap <config_map_name> -o yaml
 ----
 +
 The CA bundle is displayed as the value of the `service-ca.crt` key in the YAML output:

diff --git a/modules/customize-certificates-add-service-serving-crd.adoc b/modules/customize-certificates-add-service-serving-crd.adoc
@@ -3,9 +3,9 @@
 // * security/certificates/service-serving-certificate.adoc
 
 [id="add-service-certificate-crd_{context}"]
-= Add the service CA bundle to a Custom Resource Definition
+= Add the service CA bundle to a custom resource definition
 
-You can annotate a Custom Resource Definition (CRD) with `service.beta.openshift.io/inject-cabundle=true` to have its `spec.conversion.webhook.clientConfig.caBundle` field populated with the service CA bundle. This allows the Kubernetes API server to validate the service CA certificate used to secure the targeted endpoint.
+You can annotate a `CustomResourceDefinition` (CRD) object with `service.beta.openshift.io/inject-cabundle=true` to have its `spec.conversion.webhook.clientConfig.caBundle` field populated with the service CA bundle. This allows the Kubernetes API server to validate the service CA certificate used to secure the targeted endpoint.
 
 [NOTE]
 ====
@@ -18,23 +18,23 @@ The service CA bundle will only be injected into the CRD if the CRD is configure
 +
 [source,terminal]
 ----
-$ oc annotate crd <crd-name> \//<1>
+$ oc annotate crd <crd_name> \//<1>
      service.beta.openshift.io/inject-cabundle=true
 ----
-<1> Replace `<crd-name>` with the name of the CRD to annotate.
+<1> Replace `<crd_name>` with the name of the CRD to annotate.
 +
-For example, use the following command to annotate the CRD `foo`:
+For example, use the following command to annotate the CRD `test1`:
 +
 [source,terminal]
 ----
-$ oc annotate crd foo service.beta.openshift.io/inject-cabundle=true
+$ oc annotate crd test1 service.beta.openshift.io/inject-cabundle=true
 ----
 
 . View the CRD to ensure that the service CA bundle has been injected:
 +
 [source,terminal]
 ----
-$ oc get crd <crd-name> -o yaml
+$ oc get crd <crd_name> -o yaml
 ----
 +
 The CA bundle is displayed in the `spec.conversion.webhook.clientConfig.caBundle` field in the YAML output:

diff --git a/modules/customize-certificates-add-service-serving-mutating-webhook.adoc b/modules/customize-certificates-add-service-serving-mutating-webhook.adoc
@@ -3,9 +3,9 @@
 // * security/certificates/service-serving-certificate.adoc
 
 [id="add-service-certificate-mutating-webhook_{context}"]
-= Add the service CA bundle to a MutatingWebhookConfiguration
+= Add the service CA bundle to a mutating webhook configuration
 
-You can annotate a MutatingWebhookConfiguration with `service.beta.openshift.io/inject-cabundle=true` to have the `clientConfig.caBundle` field of each webhook populated with the service CA bundle. This allows the Kubernetes API server to validate the service CA certificate used to secure the targeted endpoint.
+You can annotate a `MutatingWebhookConfiguration` object with `service.beta.openshift.io/inject-cabundle=true` to have the `clientConfig.caBundle` field of each webhook populated with the service CA bundle. This allows the Kubernetes API server to validate the service CA certificate used to secure the targeted endpoint.
 
 [NOTE]
 ====
@@ -14,27 +14,27 @@ Do not set this annotation for admission webhook configurations that need to spe
 
 .Procedure
 
-. Annotate the MutatingWebhookConfiguration with `service.beta.openshift.io/inject-cabundle=true`:
+. Annotate the mutating webhook configuration with `service.beta.openshift.io/inject-cabundle=true`:
 +
 [source,terminal]
 ----
-$ oc annotate mutatingwebhookconfigurations <mutatingwebhook-name> \//<1>
+$ oc annotate mutatingwebhookconfigurations <mutating_webhook_name> \//<1>
      service.beta.openshift.io/inject-cabundle=true
 ----
-<1> Replace `<mutatingwebhook-name>` with the name of the MutatingWebhookConfiguration to annotate.
+<1> Replace `<mutating_webhook_name>` with the name of the mutating webhook configuration to annotate.
 +
-For example, use the following command to annotate the MutatingWebhookConfiguration `foo`:
+For example, use the following command to annotate the mutating webhook configuration `test1`:
 +
 [source,terminal]
 ----
-$ oc annotate mutatingwebhookconfigurations foo service.beta.openshift.io/inject-cabundle=true
+$ oc annotate mutatingwebhookconfigurations test1 service.beta.openshift.io/inject-cabundle=true
 ----
 
-. View the MutatingWebhookConfiguration to ensure that the service CA bundle has been injected:
+. View the mutating webhook configuration to ensure that the service CA bundle has been injected:
 +
 [source,terminal]
 ----
-$ oc get mutatingwebhookconfigurations <mutatingwebhook-name> -o yaml
+$ oc get mutatingwebhookconfigurations <mutating_webhook_name> -o yaml
 ----
 +
 The CA bundle is displayed in the `clientConfig.caBundle` field of all webhooks in the YAML output:

diff --git a/modules/customize-certificates-add-service-serving-validating-webhook.adoc b/modules/customize-certificates-add-service-serving-validating-webhook.adoc
@@ -3,9 +3,9 @@
 // * security/certificates/service-serving-certificate.adoc
 
 [id="add-service-certificate-validating-webhook_{context}"]
-= Add the service CA bundle to a ValidatingWebhookConfiguration
+= Add the service CA bundle to a validating webhook configuration
 
-You can annotate a ValidatingWebhookConfiguration with `service.beta.openshift.io/inject-cabundle=true` to have the `clientConfig.caBundle` field of each webhook populated with the service CA bundle. This allows the Kubernetes API server to validate the service CA certificate used to secure the targeted endpoint.
+You can annotate a `ValidatingWebhookConfiguration` object with `service.beta.openshift.io/inject-cabundle=true` to have the `clientConfig.caBundle` field of each webhook populated with the service CA bundle. This allows the Kubernetes API server to validate the service CA certificate used to secure the targeted endpoint.
 
 [NOTE]
 ====
@@ -14,27 +14,27 @@ Do not set this annotation for admission webhook configurations that need to spe
 
 .Procedure
 
-. Annotate the ValidatingWebhookConfiguration with `service.beta.openshift.io/inject-cabundle=true`:
+. Annotate the validating webhook configuration with `service.beta.openshift.io/inject-cabundle=true`:
 +
 [source,terminal]
 ----
-$ oc annotate validatingwebhookconfigurations <validatingwebhook-name> \//<1>
+$ oc annotate validatingwebhookconfigurations <validating_webhook_name> \//<1>
      service.beta.openshift.io/inject-cabundle=true
 ----
-<1> Replace `<validatingwebhook-name>` with the name of the ValidatingWebhookConfiguration to annotate.
+<1> Replace `<validating_webhook_name>` with the name of the validating webhook configuration to annotate.
 +
-For example, use the following command to annotate the ValidatingWebhookConfiguration `foo`:
+For example, use the following command to annotate the validating webhook configuration `test1`:
 +
 [source,terminal]
 ----
-$ oc annotate validatingwebhookconfigurations foo service.beta.openshift.io/inject-cabundle=true
+$ oc annotate validatingwebhookconfigurations test1 service.beta.openshift.io/inject-cabundle=true
 ----
 
-. View the ValidatingWebhookConfiguration to ensure that the service CA bundle has been injected:
+. View the validating webhook configuration to ensure that the service CA bundle has been injected:
 +
 [source,terminal]
 ----
-$ oc get validatingwebhookconfigurations <validatingwebhook-name> -o yaml
+$ oc get validatingwebhookconfigurations <validating_webhook_name> -o yaml
 ----
 +
 The CA bundle is displayed in the `clientConfig.caBundle` field of all webhooks in the YAML output:

diff --git a/modules/customize-certificates-add-service-serving.adoc b/modules/customize-certificates-add-service-serving.adoc
@@ -26,36 +26,36 @@ internal communications.
 +
 [source,terminal]
 ----
-$ oc annotate service <service-name> \//<1>
-     service.beta.openshift.io/serving-cert-secret-name=<secret-name> //<2>
+$ oc annotate service <service_name> \//<1>
+     service.beta.openshift.io/serving-cert-secret-name=<secret_name> //<2>
 ----
-<1> Replace `<service-name>` with the name of the service to secure.
-<2> `<secret-name>` will be the name of the generated secret containing the
+<1> Replace `<service_name>` with the name of the service to secure.
+<2> `<secret_name>` will be the name of the generated secret containing the
 certificate and key pair. For convenience, it is recommended that this
-be the same as `<service-name>`.
+be the same as `<service_name>`.
 +
-For example, use the following command to annotate the service `foo`:
+For example, use the following command to annotate the service `test1`:
 +
 [source,terminal]
 ----
-$ oc annotate service foo service.beta.openshift.io/serving-cert-secret-name=foo
+$ oc annotate service test1 service.beta.openshift.io/serving-cert-secret-name=test1
 ----
 
 . Examine the service to confirm that the annotations are present:
 +
 [source,terminal]
 ----
-$ oc describe service <service-name>
+$ oc describe service <service_name>
 ----
 +
 .Example output
 [source,terminal]
 ----
 ...
-Annotations:              service.beta.openshift.io/serving-cert-secret-name: <service-name>
+Annotations:              service.beta.openshift.io/serving-cert-secret-name: <service_name>
                           service.beta.openshift.io/serving-cert-signed-by: openshift-service-serving-signer@1556850837
 ...
 ----
 
-. After the cluster generates a secret for your service, your PodSpec can
-mount it, and the Pod will run after it becomes available.
+. After the cluster generates a secret for your service, your `Pod` spec can
+mount it, and the pod will run after it becomes available.