diff --git a/modules/about-etcd-encryption.adoc b/modules/about-etcd-encryption.adoc index 737194148534..c47b9389136e 100644 --- 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 index 5f21960cfa3d..73f44eefb715 100644 --- 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 index 2ac3360efabf..047185bd4b2b 100644 --- a/modules/builds-adding-input-secrets-configmaps.adoc +++ b/modules/builds-adding-input-secrets-configmaps.adoc @@ -3,15 +3,15 @@ // * 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] ---- @@ -19,9 +19,9 @@ $ oc create configmap settings-mvn \ --from-file=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 index 246aece0e386..3a5acaef2cbc 100644 --- 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 index 7c991a0ccca3..589540160bf1 100644 --- 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 \//<1> +$ oc annotate apiservice \//<1> service.beta.openshift.io/inject-cabundle=true ---- -<1> Replace `` with the name of the APIService to annotate. +<1> Replace `` 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 -o yaml +$ oc get apiservice -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 index f78510ee381f..6ea32eb352ba 100644 --- 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 \//<1> +$ oc annotate configmap \//<1> service.beta.openshift.io/inject-cabundle=true ---- -<1> Replace `` with the name of the ConfigMap to annotate. +<1> Replace `` 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 -o yaml +$ oc get configmap -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 index 56bceef3cc0f..85a7eccf5f54 100644 --- 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 \//<1> +$ oc annotate crd \//<1> service.beta.openshift.io/inject-cabundle=true ---- -<1> Replace `` with the name of the CRD to annotate. +<1> Replace `` 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 -o yaml +$ oc get crd -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 index c99e53b4b4bf..e623a79ec4c0 100644 --- 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 \//<1> +$ oc annotate mutatingwebhookconfigurations \//<1> service.beta.openshift.io/inject-cabundle=true ---- -<1> Replace `` with the name of the MutatingWebhookConfiguration to annotate. +<1> Replace `` 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 -o yaml +$ oc get mutatingwebhookconfigurations -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 index 45d66827e173..60c92348555c 100644 --- 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 \//<1> +$ oc annotate validatingwebhookconfigurations \//<1> service.beta.openshift.io/inject-cabundle=true ---- -<1> Replace `` with the name of the ValidatingWebhookConfiguration to annotate. +<1> Replace `` 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 -o yaml +$ oc get validatingwebhookconfigurations -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 index feded8c7e1cf..e9ea8b41f2bb 100644 --- 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 \//<1> - service.beta.openshift.io/serving-cert-secret-name= //<2> +$ oc annotate service \//<1> + service.beta.openshift.io/serving-cert-secret-name= //<2> ---- -<1> Replace `` with the name of the service to secure. -<2> `` will be the name of the generated secret containing the +<1> Replace `` with the name of the service to secure. +<2> `` 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 ``. +be the same as ``. + -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 +$ oc describe service ---- + .Example output [source,terminal] ---- ... -Annotations: service.beta.openshift.io/serving-cert-secret-name: +Annotations: service.beta.openshift.io/serving-cert-secret-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. diff --git a/modules/customize-certificates-replace-default-router.adoc b/modules/customize-certificates-replace-default-router.adoc index b6c6223ce76a..c126771d1576 100644 --- a/modules/customize-certificates-replace-default-router.adoc +++ b/modules/customize-certificates-replace-default-router.adoc @@ -26,7 +26,7 @@ root CA certificate. .Procedure -. Create a ConfigMap that includes only the root CA certificate used to sign the wildcard certificate: +. Create a config map that includes only the root CA certificate used to sign the wildcard certificate: + [source,terminal] ---- @@ -36,7 +36,7 @@ $ oc create configmap custom-ca \ ---- <1> `` is the path to the root CA certificate file on your local file system. -. Update the cluster-wide proxy configuration with the newly created ConfigMap: +. Update the cluster-wide proxy configuration with the newly created config map: + [source,terminal] ---- diff --git a/modules/customize-certificates-rotate-service-serving.adoc b/modules/customize-certificates-rotate-service-serving.adoc index dde820c7a7e8..a6dcee1de1db 100644 --- a/modules/customize-certificates-rotate-service-serving.adoc +++ b/modules/customize-certificates-rotate-service-serving.adoc @@ -22,7 +22,7 @@ annotation, as seen below. + [source,terminal] ---- -$ oc describe service +$ oc describe service ---- + .Example output @@ -46,8 +46,9 @@ step. . Confirm that the certificate has been recreated by obtaining the new secret and examining the `AGE`. + +[source,terminal] ---- -$ oc get secret +$ oc get secret ---- + .Example output diff --git a/modules/disabling-etcd-encryption.adoc b/modules/disabling-etcd-encryption.adoc index d1b80b80b7e3..43fbdcbeec16 100644 --- a/modules/disabling-etcd-encryption.adoc +++ b/modules/disabling-etcd-encryption.adoc @@ -14,7 +14,7 @@ You can disable encryption of etcd data in your cluster. .Procedure -. Modify the API server object: +. Modify the `APIServer` object: + [source,terminal] ---- diff --git a/modules/enabling-etcd-encryption.adoc b/modules/enabling-etcd-encryption.adoc index d4d55520b25e..73108db591bd 100644 --- a/modules/enabling-etcd-encryption.adoc +++ b/modules/enabling-etcd-encryption.adoc @@ -19,7 +19,7 @@ It is not recommended to take a backup of etcd until the initial encryption proc .Procedure -. Modify the API server object: +. Modify the `APIServer` object: + [source,terminal] ---- diff --git a/modules/security-build-inputs.adoc b/modules/security-build-inputs.adoc index 8e02dbfe4b04..70ac9259de4f 100644 --- a/modules/security-build-inputs.adoc +++ b/modules/security-build-inputs.adoc @@ -16,7 +16,7 @@ mirror, you must supply a custom `.npmrc` file for the build that contains a URL, user name, and password. For security reasons, you do not want to expose your credentials in the application image. -Using this example scenario, you can add an input secret to a new `BuildConfig`: +Using this example scenario, you can add an input secret to a new `BuildConfig` object: . Create the secret, if it does not exist: + @@ -28,7 +28,7 @@ $ oc create secret generic secret-npmrc --from-file=.npmrc=~/.npmrc This creates a new secret named `secret-npmrc`, which contains the base64 encoded content of the `~/.npmrc` file. -. Add the secret to the `source` section in the existing `BuildConfig`: +. Add the secret to the `source` section in the existing `BuildConfig` object: + [source,yaml] ---- @@ -41,7 +41,7 @@ source: name: secret-npmrc ---- -. To include the secret in a new `BuildConfig`, run the following command: +. To include the secret in a new `BuildConfig` object, run the following command: + [source,terminal] ---- diff --git a/modules/security-deploy-secrets.adoc b/modules/security-deploy-secrets.adoc index 5670b80c5eb0..e0cf535c731f 100644 --- a/modules/security-deploy-secrets.adoc +++ b/modules/security-deploy-secrets.adoc @@ -3,9 +3,9 @@ // * security/container_security/security-deploy.adoc [id="security-deploy-secrets_{context}"] -= Creating Secrets and ConfigMaps += Creating secrets and config maps -The Secret object type provides a mechanism to hold sensitive information such +The `Secret` object type provides a mechanism to hold sensitive information such as passwords, {product-title} client configuration files, `dockercfg` files, and private source repository credentials. Secrets decouple sensitive content from pods. You can mount secrets into containers using a volume plug-in or the @@ -27,7 +27,7 @@ enter credentials for accessing a private image repository. . When creating a deployment configuration (for example, from the *Add to Project* -> *Deploy Image* page), set the `Pull Secret` to your new secret. -ConfigMaps are similar to secrets, but are designed to support working with +Config maps are similar to secrets, but are designed to support working with strings that do not contain sensitive information. The `ConfigMap` object holds key-value pairs of configuration data that can be consumed in pods or used to store configuration data for system components such as controllers. diff --git a/modules/security-hardening-how.adoc b/modules/security-hardening-how.adoc index 6c26d063b982..42f063613314 100644 --- a/modules/security-hardening-how.adoc +++ b/modules/security-hardening-how.adoc @@ -46,11 +46,11 @@ Contents added in this way are available at each node's first boot. After the {product-title} cluster is up and running, there are several ways to apply hardening features to {op-system}: -* DaemonSet: If you need a service to run on every node, you can add +* Daemon set: If you need a service to run on every node, you can add that service with a -link:https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/[Kubernetes DaemonSet]. -* MachineConfig: `MachineConfig` objects contain a subset of Ignition configs in the same format. -By applying MachineConfigs to all worker or control plane nodes, +link:https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/[Kubernetes `DaemonSet` object]. +* Machine config: `MachineConfig` objects contain a subset of Ignition configs in the same format. +By applying machine configs to all worker or control plane nodes, you can ensure that the next node of the same type that is added to the cluster has the same changes applied. diff --git a/modules/security-monitoring-cluster-logging.adoc b/modules/security-monitoring-cluster-logging.adoc index f0df495e12d2..c0a636333c60 100644 --- a/modules/security-monitoring-cluster-logging.adoc +++ b/modules/security-monitoring-cluster-logging.adoc @@ -5,8 +5,8 @@ [id="security-monitoring-cluster-logging_{context}"] = Logging -Using the `oc log` command, you can view container logs, Buildconfigs and -Deploymentconfigs in real time. Different can users have access different +Using the `oc log` command, you can view container logs, build configs and +deployments in real time. Different can users have access different access to logs: * Users who have access to a project are able to see the logs for that project by default. @@ -15,4 +15,4 @@ access to logs: To save your logs for further audit and analysis, you can enable the `cluster-logging` add-on feature to collect, manage, and view system, container, and audit logs. You can deploy, manage, and upgrade cluster logging through the Elasticsearch Operator -and Cluster Logging Operator. +and Cluster Logging Operator. diff --git a/modules/security-monitoring-events.adoc b/modules/security-monitoring-events.adoc index 05a24058ef9c..b524acb13aed 100644 --- a/modules/security-monitoring-events.adoc +++ b/modules/security-monitoring-events.adoc @@ -5,16 +5,16 @@ [id="security-monitoring-events_{context}"] = Watching cluster events -Cluster administrators are encouraged to familiarize themselves with the _Event_ resource +Cluster administrators are encouraged to familiarize themselves with the `Event` resource type and review the list of system events to determine which events are of interest. Events are associated with a namespace, either the namespace of the resource they are related to or, for cluster events, the `default` namespace. The default namespace holds relevant events for monitoring or auditing a cluster, -such as _Node_ events and resource events related to infrastructure components. +such as node events and resource events related to infrastructure components. The master API and `oc` command do not provide parameters to scope a listing of events to only those -related to nodes. A simple approach would be to use grep: +related to nodes. A simple approach would be to use `grep`: [source,terminal] ---- @@ -29,7 +29,7 @@ $ oc get event -n default | grep Node A more flexible approach is to output the events in a form that other tools can process. For example, the following example uses the `jq` -tool against JSON output to extract only _NodeHasDiskPressure_ events: +tool against JSON output to extract only `NodeHasDiskPressure` events: [source,terminal] ---- diff --git a/modules/security-network-namespaces.adoc b/modules/security-network-namespaces.adoc index 2c6fe9e0b777..3eaa2a678154 100644 --- a/modules/security-network-namespaces.adoc +++ b/modules/security-network-namespaces.adoc @@ -11,6 +11,6 @@ cluster. Network policy mode, by default, makes all pods in a project accessible from other pods and network endpoints. -To isolate one or more pods in a project, you can create NetworkPolicy objects +To isolate one or more pods in a project, you can create `NetworkPolicy` objects in that project to indicate the allowed incoming connections. Using multitenant mode, you can provide project-level isolation for pods and services. diff --git a/modules/security-registries-quay.adoc b/modules/security-registries-quay.adoc index 08aaeea93d78..097cb94fac9a 100644 --- a/modules/security-registries-quay.adoc +++ b/modules/security-registries-quay.adoc @@ -13,7 +13,7 @@ version of Red Hat Quay at link:https://quay.io[Quay.io]. Security-related features of Red Hat Quay include: -* *Time Machine*: Allows images with older tags to expire after a set +* *Time machine*: Allows images with older tags to expire after a set period of time or based on a user-selected expiration time. * *link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/html-single/manage_red_hat_quay/index#repo-mirroring-in-red-hat-quay[Repository mirroring]*: Lets you mirror diff --git a/modules/security-storage-persistent.adoc b/modules/security-storage-persistent.adoc index 857c4c90b315..c7b24eccec2f 100644 --- a/modules/security-storage-persistent.adoc +++ b/modules/security-storage-persistent.adoc @@ -19,7 +19,7 @@ incorporate storage from any storage back end that supports the CSI interface. * Azure File * * OpenStack Cinder * * GCE Persistent Disks * -* VMware vSphere * +* VMware vSphere * * Network File System (NFS) * FlexVolume * Fibre Channel @@ -29,7 +29,7 @@ Plug-ins for those storage types with dynamic provisioning are marked with an asterisk (*). Data in transit is encrypted via HTTPS for all {product-title} components communicating with each other. -You can mount `PersistentVolume` (PV) on a host in any way supported by your +You can mount a persistent volume (PV) on a host in any way supported by your storage type. Different types of storage have different capabilities and each PV's access modes are set to the specific modes supported by that particular volume. diff --git a/security/certificate_types_descriptions/ingress-certificates.adoc b/security/certificate_types_descriptions/ingress-certificates.adoc index e5351160d287..448b7f74758a 100644 --- a/security/certificate_types_descriptions/ingress-certificates.adoc +++ b/security/certificate_types_descriptions/ingress-certificates.adoc @@ -54,7 +54,7 @@ image:darkcircle-8.png[20,20] The custom CA certificate bundle, which instructs image:darkcircle-9.png[20,20] The `trustedCA` field is used to reference the user-provided CA bundle. -image:darkcircle-10.png[20,20] The Cluster Network Operator injects the trusted CA bundle into the `proxy-ca` ConfigMap. +image:darkcircle-10.png[20,20] The Cluster Network Operator injects the trusted CA bundle into the `proxy-ca` config map. image:darkcircle-11.png[20,20] {product-title} {product-version} and newer use `default-ingress-cert`. diff --git a/security/certificate_types_descriptions/proxy-certificates.adoc b/security/certificate_types_descriptions/proxy-certificates.adoc index ddc5dcc1f0b7..8745033310c0 100644 --- a/security/certificate_types_descriptions/proxy-certificates.adoc +++ b/security/certificate_types_descriptions/proxy-certificates.adoc @@ -9,9 +9,9 @@ toc::[] Proxy certificates allow users to specify one or more custom certificate authority (CA) certificates used by platform components when making egress connections. -The `trustedCA` field of the Proxy object is a reference to a ConfigMap that contains a user-provided trusted certificate authority (CA) bundle. This bundle is merged with the {op-system-first} trust bundle and injected into the trust store of platform components that make egress HTTPS calls. For example, `image-registry-operator` calls an external image registry to download images. If `trustedCA` is not specified, only the {op-system} trust bundle is used for proxied HTTPS connections. Provide custom CA certificates to the {op-system} trust bundle if you want to use your own certificate infrastructure. +The `trustedCA` field of the Proxy object is a reference to a config map that contains a user-provided trusted certificate authority (CA) bundle. This bundle is merged with the {op-system-first} trust bundle and injected into the trust store of platform components that make egress HTTPS calls. For example, `image-registry-operator` calls an external image registry to download images. If `trustedCA` is not specified, only the {op-system} trust bundle is used for proxied HTTPS connections. Provide custom CA certificates to the {op-system} trust bundle if you want to use your own certificate infrastructure. -The `trustedCA` field should only be consumed by a proxy validator. The validator is responsible for reading the certificate bundle from required key `ca-bundle.crt` and copying it to a ConfigMap named `trusted-ca-bundle` in the `openshift-config-managed` namespace. The namespace for the ConfigMap referenced by `trustedCA` is `openshift-config`: +The `trustedCA` field should only be consumed by a proxy validator. The validator is responsible for reading the certificate bundle from required key `ca-bundle.crt` and copying it to a config map named `trusted-ca-bundle` in the `openshift-config-managed` namespace. The namespace for the config map referenced by `trustedCA` is `openshift-config`: [source,yaml] ---- @@ -58,7 +58,7 @@ additionalTrustBundle: | == Location -The user-provided trust bundle is represented as a ConfigMap. The ConfigMap is mounted into the file system of platform components that make egress HTTPS calls. Typically, Operators mount the ConfigMap to `/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem`, but this is not required by the proxy. A proxy can modify or inspect the HTTPS connection. In either case, the proxy must generate and sign a new certificate for the connection. +The user-provided trust bundle is represented as a config map. The config map is mounted into the file system of platform components that make egress HTTPS calls. Typically, Operators mount the config map to `/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem`, but this is not required by the proxy. A proxy can modify or inspect the HTTPS connection. In either case, the proxy must generate and sign a new certificate for the connection. Complete proxy support means connecting to the specified proxy and trusting any signatures it has generated. Therefore, it is necessary to let the user specify a trusted root, such that any certificate chain connected to that trusted root is also trusted. @@ -91,10 +91,10 @@ These certificates are managed by the system and not the user. Updating the user-provided trust bundle consists of either: -* updating the PEM-encoded certificates in the ConfigMap referenced by `trustedCA,` or -* creating a ConfigMap in the namespace `openshift-config` that contains the new trust bundle and updating `trustedCA` to reference the name of the new ConfigMap. +* updating the PEM-encoded certificates in the config map referenced by `trustedCA,` or +* creating a config map in the namespace `openshift-config` that contains the new trust bundle and updating `trustedCA` to reference the name of the new config map. -The mechanism for writing CA certificates to the {op-system} trust bundle is exactly the same as writing any other file to {op-system}, which is done through the use of MachineConfigs. When the Machine Config Operator (MCO) applies the new MachineConfig that contains the new CA certificates, the node is rebooted. During the next boot, the service `coreos-update-ca-trust.service` runs on the {op-system} nodes, which automatically update the trust bundle with the new CA certificates. For example: +The mechanism for writing CA certificates to the {op-system} trust bundle is exactly the same as writing any other file to {op-system}, which is done through the use of machine configs. When the Machine Config Operator (MCO) applies the new machine config that contains the new CA certificates, the node is rebooted. During the next boot, the service `coreos-update-ca-trust.service` runs on the {op-system} nodes, which automatically update the trust bundle with the new CA certificates. For example: [source,yaml] ---- diff --git a/security/certificate_types_descriptions/service-ca-certificates.adoc b/security/certificate_types_descriptions/service-ca-certificates.adoc index cf14e0907371..a6fd8131eb55 100644 --- a/security/certificate_types_descriptions/service-ca-certificates.adoc +++ b/security/certificate_types_descriptions/service-ca-certificates.adoc @@ -15,7 +15,7 @@ A custom expiration term is not supported. The self-signed CA is stored in a sec Other services can request a service serving certificate by annotating a service resource with `service.beta.openshift.io/serving-cert-secret-name: `. In response, the Operator generates a new certificate, as `tls.crt`, and private key, as `tls.key` to the named secret. The certificate is valid for two years. -Other services can request that the CA bundle for the service CA be injected into APIService or ConfigMap resources by annotating with `service.beta.openshift.io/inject-cabundle: true` to support validating certificates generated from the service CA. In response, the Operator writes its current CA bundle to the `CABundle` field of APIService or as `service-ca.crt` to a ConfigMap. +Other services can request that the CA bundle for the service CA be injected into API service or config map resources by annotating with `service.beta.openshift.io/inject-cabundle: true` to support validating certificates generated from the service CA. In response, the Operator writes its current CA bundle to the `CABundle` field of an API service or as `service-ca.crt` to a config map. As of {product-title} 4.3.5, automated rotation is supported and is backported to some 4.2.z and 4.3.z releases. For any release supporting automated rotation, the service CA is valid for 26 months and is automatically refreshed when there is less than 13 months validity left. If necessary, you can manually refresh the service CA. diff --git a/security/certificate_types_descriptions/user-provided-certificates-for-default-ingress.adoc b/security/certificate_types_descriptions/user-provided-certificates-for-default-ingress.adoc index 2583edbc178a..c15f5814f157 100644 --- a/security/certificate_types_descriptions/user-provided-certificates-for-default-ingress.adoc +++ b/security/certificate_types_descriptions/user-provided-certificates-for-default-ingress.adoc @@ -16,7 +16,7 @@ The Ingress Operator generates a default certificate for an Ingress Controller t == Location -The user-provided certificates must be provided in a `tls` type Secret resource in the `openshift-ingress` namespace. Update the IngressController CR in the `openshift-ingress-operator` namespace to enable the use of the user-provided certificate. For more information on this process, see xref:../../networking/ingress-operator.adoc#nw-ingress-setting-a-custom-default-certificate_configuring-ingress[Setting a custom default certificate]. +The user-provided certificates must be provided in a `tls` type `Secret` resource in the `openshift-ingress` namespace. Update the `IngressController` CR in the `openshift-ingress-operator` namespace to enable the use of the user-provided certificate. For more information on this process, see xref:../../networking/ingress-operator.adoc#nw-ingress-setting-a-custom-default-certificate_configuring-ingress[Setting a custom default certificate]. == Management diff --git a/security/container_security/security-build.adoc b/security/container_security/security-build.adoc index f9136f49e813..847e64ecc1df 100644 --- a/security/container_security/security-build.adoc +++ b/security/container_security/security-build.adoc @@ -27,7 +27,7 @@ include::modules/security-build-knative.adoc[leveloffset=+1] * xref:../../builds/understanding-image-builds.adoc#understanding-image-builds[Understanding image builds] * xref:../../builds/triggering-builds-build-hooks.adoc#triggering-builds-build-hooks[Triggering and modifying builds] * xref:../../builds/creating-build-inputs.adoc#creating-build-inputs[Creating build inputs] -* xref:../../builds/creating-build-inputs.adoc#builds-input-secrets-configmaps_creating-build-inputs[Input Secrets and ConfigMaps] +* xref:../../builds/creating-build-inputs.adoc#builds-input-secrets-configmaps_creating-build-inputs[Input secrets and config maps] ifndef::openshift-origin[] * xref:../../architecture/cicd_gitops.adoc#cicd_gitops[The CI/CD methodology and practice] * xref:../../serverless/architecture/serverless-serving-architecture.adoc#serverless-serving-architecture[Knative Serving architecture] diff --git a/security/container_security/security-deploy.adoc b/security/container_security/security-deploy.adoc index 8d660d69377c..184e4e7ccb81 100644 --- a/security/container_security/security-deploy.adoc +++ b/security/container_security/security-deploy.adoc @@ -26,4 +26,4 @@ include::modules/security-deploy-secrets.adoc[leveloffset=+1] // Continuous deployment tooling include::modules/security-deploy-continuous.adoc[leveloffset=+1] .Additional resources -* xref:../../builds/creating-build-inputs.adoc#builds-input-secrets-configmaps_creating-build-inputs[Input Secrets and ConfigMaps] +* xref:../../builds/creating-build-inputs.adoc#builds-input-secrets-configmaps_creating-build-inputs[Input secrets and config maps] diff --git a/security/container_security/security-hosts-vms.adoc b/security/container_security/security-hosts-vms.adoc index 8a7db0de0b57..b704bbd190ae 100644 --- a/security/container_security/security-hosts-vms.adoc +++ b/security/container_security/security-hosts-vms.adoc @@ -9,14 +9,14 @@ Both containers and virtual machines provide ways of separating applications running on a host from the operating system itself. Understanding {op-system}, which is the operating system used by {product-title}, will help you see how the host -systems protect containers and hosts from each other. +systems protect containers and hosts from each other. // How containers are secured on {op-system} include::modules/security-hosts-vms-rhcos.adoc[leveloffset=+1] .Additional resources * xref:../../nodes/nodes/nodes-nodes-resources-configuring.adoc#allocate-node-enforcement_nodes-nodes-resources-configuring[How nodes enforce resource constraints] -* xref:../../authentication/managing-security-context-constraints.adoc#managing-pod-security-policies[Managing Security Context Constraints] +* xref:../../authentication/managing-security-context-constraints.adoc#managing-pod-security-policies[Managing security context constraints] * xref:../../architecture/architecture-installation.adoc#available-platforms_architecture-installation[Available platforms] * xref:../../installing/installing_bare_metal/installing-bare-metal.adoc#installation-requirements-user-infra_installing-bare-metal[Machine requirements for a cluster with user-provisioned infrastructure] * xref:../../architecture/architecture-rhcos.adoc#rhcos-configured_architecture-rhcos[Choosing how to configure {op-system}] diff --git a/security/container_security/security-platform.adoc b/security/container_security/security-platform.adoc index 1e521fc07d41..1558da488dc2 100644 --- a/security/container_security/security-platform.adoc +++ b/security/container_security/security-platform.adoc @@ -38,10 +38,10 @@ include::modules/security-platform-certificates.adoc[leveloffset=+1] * xref:../../authentication/using-rbac.adoc#using-rbac[Using RBAC to define and apply permissions] ifndef::openshift-origin[] -* xref:../../architecture/admission-plug-ins.adoc#admission-plug-ins[About Admission plug-ins] +* xref:../../architecture/admission-plug-ins.adoc#admission-plug-ins[About admission plug-ins] endif::[] -* xref:../../authentication/managing-security-context-constraints.adoc#managing-pod-security-policies[Managing Security Context Constraints] +* xref:../../authentication/managing-security-context-constraints.adoc#managing-pod-security-policies[Managing security context constraints] * xref:../../authentication/managing-security-context-constraints.adoc#security-context-constraints-command-reference_configuring-internal-oauth[SCC reference commands] * xref:../../authentication/understanding-and-creating-service-accounts.adoc#service-accounts-granting-roles_understanding-service-accounts[Examples of granting roles to service accounts] * xref:../../authentication/configuring-internal-oauth.adoc#configuring-internal-oauth[Configuring the internal OAuth server] diff --git a/security/container_security/security-registries.adoc b/security/container_security/security-registries.adoc index a6608f524a9f..a175a7446fe6 100644 --- a/security/container_security/security-registries.adoc +++ b/security/container_security/security-registries.adoc @@ -41,7 +41,7 @@ include::modules/security-registries-ecosystem.adoc[leveloffset=+1] // OpenShift Container Registry include::modules/security-registries-openshift.adoc[leveloffset=+1] .Additional resources -* xref:../../registry/architecture-component-imageregistry.adoc#architecture-component-imageregistry[Integrated {product-title} Registry] +* xref:../../registry/architecture-component-imageregistry.adoc#architecture-component-imageregistry[Integrated {product-title} registry] // Quay Container Registry include::modules/security-registries-quay.adoc[leveloffset=+1] diff --git a/security/pod-vulnerability-scan.adoc b/security/pod-vulnerability-scan.adoc index 3a69d6ef91f2..71853c6a5397 100644 --- a/security/pod-vulnerability-scan.adoc +++ b/security/pod-vulnerability-scan.adoc @@ -15,7 +15,7 @@ vulnerability information, provided an image’s registry is running image scanning (such as link:https://quay.io[Quay.io] or a link:https://access.redhat.com/products/red-hat-quay[Red Hat Quay] registry with Clair scanning) -* Exposes vulnerabilities via the ImageManifestVuln object in the Kubernetes API +* Exposes vulnerabilities via the `ImageManifestVuln` object in the Kubernetes API Using the instructions here, the CSO is installed in the `openshift-operators` namespace, so it is available to all namespaces on your OpenShift cluster.