openshift · brendan-daly-red-hat · Aug 26, 2026 · Aug 26, 2026 · skopacz1 · Aug 25, 2026
diff --git a/modules/installation-approve-csrs.adoc b/modules/installation-approve-csrs.adoc
@@ -47,7 +47,7 @@ endif::[]
 = Approving the certificate signing requests for your machines
 
 [role="_abstract"]
-To allow newly added machines to join your {product-title} cluster, you can confirm that pending certificate signing requests (CSRs) are approved or approve them yourself. Approve client requests first, then server requests.
+To allow newly added machines to join your {product-title} cluster, confirm that the cluster approves pending certificate signing requests (CSRs), or approve them yourself. Approve client requests first, then server requests.
 
 .Prerequisites
 
@@ -116,12 +116,12 @@ endif::ibm-z,ibm-z-kvm[]
 +
 [NOTE]
 ====
-You must approve your CSRs within an hour of adding the machines to the cluster. If you do not approve them within an hour, the certificates rotate, and more than two certificates are present for each node. You must approve all of these certificates. After the client CSR is approved, the kubelet creates a secondary CSR for the serving certificate, which requires manual approval. The subsequent serving certificate renewal requests are then automatically approved by the `machine-approver` if the Kubelet requests a new certificate with identical parameters.
+You must approve your CSRs within an hour of adding the machines to the cluster. If you do not approve them within an hour, the certificates rotate, and more than two certificates are present for each node. You must approve all of these certificates. After you approve the client CSR, the kubelet creates a secondary CSR for the serving certificate, which requires manual approval. The `machine-approver` then automatically approves later serving certificate renewal requests if the kubelet requests a new certificate with the same parameters.
 ====
 +
 [NOTE]
 ====
-For clusters running on platforms that are not machine API enabled, such as bare metal and other user-provisioned infrastructure, you must implement a method of automatically approving the kubelet serving certificate requests (CSRs). If a request is not approved, then the `oc exec`, `oc rsh`, and `oc logs` commands cannot succeed, because a serving certificate is required when the API server connects to the kubelet. Any operation that contacts the Kubelet endpoint requires this certificate approval to be in place. The method must watch for new CSRs, confirm that the CSR was submitted by the `node-bootstrapper` service account in the `system:node` or `system:admin` groups, and confirm the identity of the node.
+For clusters running on platforms that are not machine API enabled, such as bare metal and other user-provisioned infrastructure, you must implement a method of automatically approving the kubelet serving certificate requests (CSRs). If you do not approve a request, the `oc exec`, `oc rsh`, and `oc logs` commands cannot succeed, because a serving certificate is required when the API server connects to the kubelet. Any operation that contacts the kubelet endpoint requires this certificate approval to be in place. The method must watch for new CSRs, confirm that the `node-bootstrapper` service account in the `system:node` or `system:admin` groups submitted the CSR, and confirm the identity of the node.
 ====
 +
 ** To approve them individually, run the following command for each valid CSR:
@@ -147,7 +147,7 @@ $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}
 Some Operators might not become available until some CSRs are approved. Each node submits two CSRs, so you might need to run the command to approve CSRs multiple times.
 ====
 
-. Now that your client requests are approved, you must review the server requests for each machine that you added to the cluster:
+. After you approve your client requests, review the server requests for each machine that you added to the cluster:
 +
 [source,terminal]
 ----
@@ -183,7 +183,7 @@ where:
 $ oc get csr -o go-template='{{range .items}}{{if not .status}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | xargs oc adm certificate approve
 ----
 
-. After all client and server CSRs have been approved, the machines have the `Ready` status. Verify this by running the following command:
+. After you approve all client and server CSRs, the machines have the `Ready` status. Verify this by running the following command:
 +
 ifndef::ibm-power[]
 [source,terminal]

diff --git a/modules/installation-aws-creating-cloudformation-stack-compute.adoc b/modules/installation-aws-creating-cloudformation-stack-compute.adoc
@@ -5,18 +5,18 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="installation-aws-creating-cloudformation-stack_{context}"]
-= Creating the CloudFormation stack for compute machines
+= Creating the `CloudFormation` stack for compute machines
 
 [role="_abstract"]
-You can create a stack of {aws-short} resources for the compute machines by using the CloudFormation template that was previously shared.
+You can create a stack of {aws-first} resources for the compute machines by using the provided `CloudFormation` template.
 
 [IMPORTANT]
 ====
-When you use the CloudFormation template for the control plane machines, the template provisions all three control plane machines with a single stack; however, when you use the CloudFormation template to deploy the compute machines, you must create the number of stacks based on the number that you defined in the `install-config.yaml` file. Each stack is provisioned once for each machine. To provision a new compute machine, you must change the stack name.
+When you use the `CloudFormation` template for the control plane machines, the template provisions all three control plane machines with a single stack; however, when you use the `CloudFormation` template to deploy the compute machines, you must create the number of stacks based on the number that you defined in the `install-config.yaml` file. You provision each stack once for each machine. To provision a new compute machine, you must change the stack name.
 ====
 
 .Procedure
-* To create the CloudFormation stack for compute machines, run the following command:
+* To create the `CloudFormation` stack for compute machines, run the following command:
 +
 [source,terminal]
 ----
@@ -27,9 +27,9 @@ $ aws cloudformation create-stack --stack-name <name> \
 +
 where:
 
-`<name>`:: Specifies the `<name>` with the name for the CloudFormation stack, such as `cluster-worker-1`. You need the name of this stack if you remove the cluster.
-`<template>`:: Specifies the relative path and the name of the CloudFormation template YAML file that you saved.
-`<parameters>`:: Specifies the relative path and the name of the JSON file for the CloudFormation parameters.
+`<name>`:: Specifies the `<name>` with the name for the `CloudFormation` stack, such as `cluster-worker-1`. You need the name of this stack if you remove the cluster.
+`<template>`:: Specifies the relative path and the name of the `CloudFormation` template YAML file that you saved.
+`<parameters>`:: Specifies the relative path and the name of the JSON file for the `CloudFormation` parameters.
 +
 .Example output
 [source,terminal]

diff --git a/modules/installation-aws-regions-with-no-ami.adoc b/modules/installation-aws-regions-with-no-ami.adoc
@@ -21,41 +21,29 @@ endif::specialized[]
 
 [role="_abstract"]
 ifndef::specialized[]
-You can deploy an {product-title} cluster to Amazon Web Services (AWS) regions
-without native support for a {op-system-first} Amazon Machine Image (AMI) or the
-AWS software development kit (SDK).
-
-If a published AMI is not available for an AWS region, you can upload a custom AMI
-prior to installing the cluster.
-
-If you are deploying to a region not supported by the AWS SDK
-and you do not specify a custom AMI, the installation program
-copies the `us-east-1` AMI to the user account automatically. Then the
-installation program creates the control plane machines with encrypted EBS
-volumes using the default or user-specified Key Management Service (KMS) key.
-This allows the AMI to follow the same process workflow as published {op-system}
-AMIs.
-
-A region without native support for an {op-system} AMI is not available to
-select from the terminal during cluster creation because it is not published.
-However, you can install to this region by configuring the custom AMI in the
-`install-config.yaml` file.
+You can deploy an {product-title} cluster to {aws-first} regions without native support for a {op-system-first} Amazon Machine Image (AMI) or the {aws-short} software development kit (SDK).
+
+If a published AMI is not available for an {aws-short} region, you can upload a custom AMI before installing the cluster.
+
+If you are deploying to a region not supported by the {aws-short} SDK and you do not specify a custom AMI, the installation program copies the `us-east-1` AMI to the user account automatically. Then the installation program creates the control plane machines with encrypted Elastic Block Store (EBS) volumes by using the default or user-specified Key Management Service (KMS) key. This allows the AMI to follow the same process workflow as published {op-system} AMIs.
+
+A region without native support for an {op-system} AMI is not available to select from the terminal during cluster creation because it is not published. However, you can install to this region by configuring the custom AMI in the `install-config.yaml` file.
 endif::specialized[]
 
 ifdef::specialized[]
-Red Hat does not publish a {op-system-first} Amazon Machine Image (AMI) for the AWS China, Secret, or Top Secret regions.
+Red Hat does not publish a {op-system-first} Amazon Machine Image (AMI) for the {aws-first} China, Secret, or Top Secret regions.
 
 Before you can install a cluster into one of these regions, you must:
 
 * Upload a custom {op-system} AMI.
 * Manually create the installation configuration file (`install-config.yaml`).
-* Specify the AWS region, and the accompanying custom AMI, in the installation configuration file.
+* Specify the {aws-short} region, and the accompanying custom AMI, in the installation configuration file.
 
-You cannot use the {product-title} installation program to create the installation configuration file. The installer does not list an AWS region without native support for an {op-system} AMI.
+You cannot use the {product-title} installation program to create the installation configuration file. The installer does not list an {aws-short} region without native support for an {op-system} AMI.
 
 [IMPORTANT]
 ====
-If you install a cluster into a Secret or Top Secret region, you must also define a custom CA certificate in the `additionalTrustBundle` field of the `install-config.yaml` file because the AWS API requires a custom CA trust bundle. To allow the installation program to access the AWS API, the CA certificates must also be defined on the machine that runs the installation program. You must add the CA bundle to the trust store on the machine, use the `AWS_CA_BUNDLE` environment variable, or define the CA bundle in the link:https://docs.aws.amazon.com/credref/latest/refdocs/setting-global-ca_bundle.html[`ca_bundle`] field of the AWS config file.
+If you install a cluster into a Secret or Top Secret region, you must also define a custom CA certificate in the `additionalTrustBundle` field of the `install-config.yaml` file because the {aws-short} API requires a custom CA trust bundle. To allow the installation program to access the {aws-short} API, the CA certificates must also be defined on the machine that runs the installation program. You must add the CA bundle to the trust store on the machine, use the `AWS_CA_BUNDLE` environment variable, or define the CA bundle in the link:https://docs.aws.amazon.com/credref/latest/refdocs/setting-global-ca_bundle.html[`ca_bundle`] field of the {aws-short} config file.
 ====
 
 endif::specialized[]

diff --git a/modules/installation-aws-user-infra-installation.adoc b/modules/installation-aws-user-infra-installation.adoc
@@ -55,7 +55,7 @@ INFO Time elapsed: 1s
 ====
 * The Ignition config files that the installation program generates contain certificates that expire after 24 hours, which are then renewed at that time. If the cluster is shut down before renewing the certificates and the cluster is later restarted after the 24 hours have elapsed, the cluster automatically recovers the expired certificates. The exception is that you must manually approve the pending `node-bootstrapper` certificate signing requests (CSRs) to recover kubelet certificates. See the documentation for _Recovering from expired control plane certificates_ for more information.
 
-* It is recommended that you use Ignition config files within 12 hours after they are generated because the 24-hour certificate rotates from 16 to 22 hours after the cluster is installed. By using the Ignition config files within 12 hours, you can avoid installation failure if the certificate update runs during installation.
+* Use Ignition config files within 12 hours after the installation program generates them because the 24-hour certificate rotates from 16 to 22 hours after you install the cluster. By using the Ignition config files within 12 hours, you can avoid installation failure if the certificate update runs during installation.
 ====
 
 ifdef::restricted[]