Merge pull request #55728 from jeana-redhat/AWS-STS-correct-name

jeana-redhat · web-flow · commit 84cddf617d98 · 2023-02-08T16:54:02.000-05:00
[OSDOCS-5271]: Fix AWS STS terms
diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
@@ -1059,7 +1059,7 @@ Topics:
     File: cco-mode-passthrough
   - Name: Using manual mode
     File: cco-mode-manual
-  - Name: Using manual mode with AWS Secure Token Service
+  - Name: Using manual mode with AWS Security Token Service
     File: cco-mode-sts
   - Name: Using manual mode with GCP Workload Identity
     File: cco-mode-gcp-workload-identity
@@ -1153,7 +1153,7 @@ Topics:
     File: understanding-aws-load-balancer-operator
   - Name: Installing the AWS Load Balancer Operator
     File: install-aws-load-balancer-operator
-  - Name: Installing the AWS Load Balancer Operator on Secure Token Service cluster
+  - Name: Installing the AWS Load Balancer Operator on Security Token Service cluster
     File: installing-albo-sts-cluster
   - Name: Creating an instance of the AWS Load Balancer Controller
     File: create-instance-aws-load-balancer-controller
diff --git a/authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc b/authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc
@@ -26,7 +26,7 @@ Mint mode is the default and recommended best practice setting for the CCO to us
 
 * **xref:../../authentication/managing_cloud_provider_credentials/cco-mode-manual.adoc#cco-mode-manual[Manual]**: In manual mode, a user manages cloud credentials instead of the CCO.
 
-** **xref:../../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#cco-mode-sts[Manual with AWS Secure Token Service]**: In manual mode, you can configure an AWS cluster to use Amazon Web Services Secure Token Service (AWS STS). With this configuration, the CCO uses temporary credentials for different components.
+** **xref:../../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#cco-mode-sts[Manual with AWS Security Token Service]**: In manual mode, you can configure an AWS cluster to use Amazon Web Services Security Token Service (AWS STS). With this configuration, the CCO uses temporary credentials for different components.
 
 ** **xref:../../authentication/managing_cloud_provider_credentials/cco-mode-gcp-workload-identity.adoc#cco-mode-gcp-workload-identity[Manual with GCP Workload Identity]**: In manual mode, you can configure a GCP cluster to use GCP Workload Identity. With this configuration, the CCO uses temporary credentials for different components.
 
diff --git a/authentication/managing_cloud_provider_credentials/cco-mode-manual.adoc b/authentication/managing_cloud_provider_credentials/cco-mode-manual.adoc
@@ -17,7 +17,7 @@ For information about configuring your cloud provider to use manual mode, see _M
 [id="manual-mode-sts-blurb"]
 == Manual mode with AWS STS
 
-You can configure an AWS cluster in manual mode to use xref:../../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#cco-mode-sts[Amazon Web Services Secure Token Service (AWS STS)]. With this configuration, the CCO uses temporary credentials for different components.
+You can configure an AWS cluster in manual mode to use xref:../../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#cco-mode-sts[Amazon Web Services Security Token Service (AWS STS)]. With this configuration, the CCO uses temporary credentials for different components.
 
 include::modules/manually-maintained-credentials-upgrade.adoc[leveloffset=+1]
 
diff --git a/authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc b/authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc
@@ -1,6 +1,6 @@
 :_content-type: ASSEMBLY
 [id="cco-mode-sts"]
-= Using manual mode with Amazon Web Services Secure Token Service
+= Using manual mode with Amazon Web Services Security Token Service
 include::_attributes/common-attributes.adoc[]
 :context: cco-mode-sts
 
@@ -14,9 +14,9 @@ This credentials strategy is supported for only new {product-title} clusters and
 ====
 
 [id="sts-mode-about"]
-== About manual mode with AWS Secure Token Service
+== About manual mode with AWS Security Token Service
 
-In manual mode with STS, the individual {product-title} cluster components use AWS Secure Token Service (STS) to assign components IAM roles that provide short-term, limited-privilege security credentials. These credentials are associated with IAM roles that are specific to each component that makes AWS API calls.
+In manual mode with STS, the individual {product-title} cluster components use AWS Security Token Service (STS) to assign components IAM roles that provide short-term, limited-privilege security credentials. These credentials are associated with IAM roles that are specific to each component that makes AWS API calls.
 
 Requests for new and refreshed credentials are automated by using an appropriately configured AWS IAM OpenID Connect (OIDC) identity provider, combined with AWS IAM roles. {product-title} signs service account tokens that are trusted by AWS IAM, and can be projected into a pod and used for authentication. Tokens are refreshed after one hour.
 
diff --git a/modules/bootstrap-aws-load-balancer-operator.adoc b/modules/bootstrap-aws-load-balancer-operator.adoc
@@ -3,7 +3,7 @@
 
 :_content-type: PROCEDURE
 [id="nw-bootstra-albo-on-sts-cluster_{context}"]
-= Bootstrapping AWS Load Balancer Operator on Secure Token Service cluster
+= Bootstrapping AWS Load Balancer Operator on Security Token Service cluster
 
 .Prerequisites
 
diff --git a/modules/configuring-albo-on-sts-cluster-predefined-credentials.adoc b/modules/configuring-albo-on-sts-cluster-predefined-credentials.adoc
@@ -3,7 +3,7 @@
 
 :_content-type: PROCEDURE
 [id="nw-installing-albo-on-sts-cluster-predefined-credentials_{context}"]
-= Configuring the AWS Load Balancer Operator on Secure Token Service cluster by using specific credentials
+= Configuring the AWS Load Balancer Operator on Security Token Service cluster by using specific credentials
 
 You can specify the credential secret by using the `spec.credentials` field in the AWS Load Balancer Controller custom resource (CR). You can use the predefined  `CredentialsRequest` object of the controller to know which roles are required.
 
diff --git a/modules/configuring-albo-on-sts-cluster.adoc b/modules/configuring-albo-on-sts-cluster.adoc
@@ -3,7 +3,7 @@
 
 :_content-type: PROCEDURE
 [id="nw-installing-albo-on-sts-cluster_{context}"]
-= Configuring AWS Load Balancer Operator on Secure Token Service cluster by using managed `CredentialsRequest` objects
+= Configuring AWS Load Balancer Operator on Security Token Service cluster by using managed `CredentialsRequest` objects
 
 .Prerequisites
 
diff --git a/modules/persistent-storage-csi-efs-sts.adoc b/modules/persistent-storage-csi-efs-sts.adoc
@@ -7,9 +7,9 @@
 
 :_content-type: PROCEDURE
 [id="efs-sts_{context}"]
-= Configuring AWS EFS CSI Driver Operator with Secure Token Service
+= Configuring AWS EFS CSI Driver Operator with Security Token Service
 
-This procedure explains how to configure the AWS EFS CSI Driver Operator with {product-title} on AWS Secure Token Service (STS).
+This procedure explains how to configure the AWS EFS CSI Driver Operator with {product-title} on AWS Security Token Service (STS).
 
 Perform this procedure after installing the AWS EFS CSI Operator, but before installing the AWS EFS CSI driver as part of _Installing the AWS EFS CSI Driver Operator_ procedure. If you perform this procedure after installing the driver and creating volumes, your volumes will fail to mount into pods.
 
diff --git a/modules/persistent-storage-csi-olm-operator-install.adoc b/modules/persistent-storage-csi-olm-operator-install.adoc
@@ -47,7 +47,7 @@ Be sure to select the *AWS EFS CSI Driver Operator* and not the *AWS EFS Operato
 After the installation finishes, the {FeatureName} CSI Operator is listed in the *Installed Operators* section of the web console.
 
 ifdef::AWS_EFS[]
-. If you are using {FeatureName} with AWS Secure Token Service (STS), you must configure the {FeatureName} CSI Driver with STS. For more information, see "Configuring AWS EFS CSI Driver with STS".
+. If you are using {FeatureName} with AWS Security Token Service (STS), you must configure the {FeatureName} CSI Driver with STS. For more information, see "Configuring AWS EFS CSI Driver with STS".
 endif::AWS_EFS[]
 
 . Install the {FeatureName} CSI Driver:
diff --git a/networking/aws_load_balancer_operator/installing-albo-sts-cluster.adoc b/networking/aws_load_balancer_operator/installing-albo-sts-cluster.adoc
@@ -1,12 +1,12 @@
 :_content-type: ASSEMBLY
 [id="albo-sts-cluster"]
-= Installing AWS Load Balancer Operator on Secure Token Service cluster
+= Installing AWS Load Balancer Operator on a Security Token Service cluster
 include::_attributes/common-attributes.adoc[]
 :context: albo-sts-cluster
 
 toc::[]
 
-You can install the AWS Load Balancer Operator on the Secure Token Service (STS) cluster.
+You can install the AWS Load Balancer Operator on a Security Token Service (STS) cluster.
 
 The AWS Load Balancer Operator relies on `CredentialsRequest` to bootstrap the Operator and for each `AWSLoadBalancerController` instance. The AWS Load Balancer Operator waits until the required secrets are created and available. The Cloud Credential Operator does not provision the secrets automatically in the STS cluster. You must set the credentials secrets manually by using the `ccoctl` binary.
 
diff --git a/rosa_planning/rosa-sts-ocm-role.adoc b/rosa_planning/rosa-sts-ocm-role.adoc
@@ -17,19 +17,19 @@ The AWS IAM roles required to use {cluster-manager} are:
 
 Whether you manage your clusters using the `rosa` CLI or {cluster-manager} web UI, you must create the account-wide roles, known as `account-roles` in the `rosa` CLI, by using the `rosa` CLI. These account roles are necessary for your first cluster, and these roles can be used across multiple clusters. These required account roles are:
 
-* `Worker-Role` 
-* `Support-Role` 
-* `Installer-Role` 
+* `Worker-Role`
+* `Support-Role`
+* `Installer-Role`
 * `ControlPlane-Role`
 
 [NOTE]
 ====
-Role creation does not request your AWS access or secret keys. AWS Secure Token Service (STS) is used as the basis of this workflow. AWS STS uses temporary, limited-privilege credentials to provide authentication.
+Role creation does not request your AWS access or secret keys. AWS Security Token Service (STS) is used as the basis of this workflow. AWS STS uses temporary, limited-privilege credentials to provide authentication.
 ====
 
 For more information about creating these roles, see xref:../rosa_architecture/rosa-sts-about-iam-resources.adoc#rosa-sts-account-wide-roles-and-policies[Account-wide IAM role and policy reference].
 
-Cluster-specific Operator roles, known as `operator-roles` in the `rosa` CLI, obtain the temporary permissions required to carry out cluster operations, such as managing back-end storage, ingress, and registry. These roles are required by the cluster that you create. These required Operator roles are: 
+Cluster-specific Operator roles, known as `operator-roles` in the `rosa` CLI, obtain the temporary permissions required to carry out cluster operations, such as managing back-end storage, ingress, and registry. These roles are required by the cluster that you create. These required Operator roles are:
 
 * `<cluster_name>-<hash>-openshift-cluster-csi-drivers-ebs-cloud-credentials`
 * `<cluster_name>-<hash>-openshift-cloud-network-config-controller-credentials`
diff --git a/updating/updating-cluster-cli.adoc b/updating/updating-cluster-cli.adoc
@@ -22,7 +22,7 @@ See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permis
 * Ensure all Operators previously installed through Operator Lifecycle Manager (OLM) are updated to their latest version in their latest channel. Updating the Operators ensures they have a valid update path when the default OperatorHub catalogs switch from the current minor version to the next during a cluster update. See xref:../operators/admin/olm-upgrading-operators.adoc#olm-upgrading-operators[Updating installed Operators] for more information.
 * Ensure that all machine config pools (MCPs) are running and not paused. Nodes associated with a paused MCP are skipped during the update process. You can pause the MCPs if you are performing a canary rollout update strategy.
 * If your cluster uses manually maintained credentials, ensure that the Cloud Credential Operator (CCO) is in an upgradeable state. For more information, see xref:../updating/updating-cluster-cli.adoc#manually-maintained-credentials-upgrade_updating-cluster-cli[Upgrading clusters with manually maintained credentials].
-* If your cluster uses manually maintained credentials with the AWS Secure Token Service (STS), obtain a copy of the `ccoctl` utility from the release image being updated to and use it to process any updated credentials. For more information, see xref:../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#sts-mode-upgrading[Upgrading an OpenShift Container Platform cluster configured for manual mode with STS].
+* If your cluster uses manually maintained credentials with the AWS Security Token Service (STS), obtain a copy of the `ccoctl` utility from the release image being updated to and use it to process any updated credentials. For more information, see xref:../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#sts-mode-upgrading[Upgrading an OpenShift Container Platform cluster configured for manual mode with STS].
 * Ensure that you address all `Upgradeable=False` conditions so the cluster allows an update to the next minor version. An alert displays at the top of the *Cluster Settings* page when you have one or more cluster Operators that cannot be upgraded. You can still update to the next available patch update for the minor release you are currently on.
 * Review the list of APIs that were removed in Kubernetes 1.25, migrate any affected components to use the new API version, and provide the administrator acknowledgment. For more information, see xref:../updating/updating-cluster-prepare.adoc#updating-cluster-prepare[Preparing to update to {product-title} 4.12].
 * If you run an Operator or you have configured any application with the pod disruption budget, you might experience an interruption during the upgrade process. If `minAvailable` is set to 1 in `PodDisruptionBudget`, the nodes are drained to apply pending machine configs which might block the eviction process. If several nodes are rebooted, all the pods might run on only one node, and the `PodDisruptionBudget` field can prevent the node drain.
diff --git a/updating/updating-cluster-rhel-compute.adoc b/updating/updating-cluster-rhel-compute.adoc
@@ -17,7 +17,7 @@ See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permis
 * Have a recent xref:../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backup-etcd[etcd backup] in case your update fails and you must xref:../backup_and_restore/control_plane_backup_and_restore/disaster_recovery/scenario-2-restoring-cluster-state.adoc#dr-restoring-cluster-state[restore your cluster to a previous state].
 * Support for {op-system-base}7 workers is removed in {product-title} {product-version}. You must replace {op-system-base}7 workers with {op-system-base}8 or {op-system} workers before upgrading to {product-title} {product-version}. Red Hat does not support in-place {op-system-base}7 to {op-system-base}8 upgrades for {op-system-base} workers; those hosts must be replaced with a clean operating system install.
 * If your cluster uses manually maintained credentials, ensure that the Cloud Credential Operator (CCO) is in an upgradeable state. For more information, see _Upgrading clusters with manually maintained credentials_ for xref:../installing/installing_aws/manually-creating-iam.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-aws[AWS], xref:../installing/installing_azure/manually-creating-iam-azure.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-azure[Azure], or xref:../installing/installing_gcp/manually-creating-iam-gcp.adoc#manually-maintained-credentials-upgrade_manually-creating-iam-gcp[GCP].
-* If your cluster uses manually maintained credentials with the AWS Secure Token Service (STS), obtain a copy of the `ccoctl` utility from the release image being updated to and use it to process any updated credentials. For more information, see xref:../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#sts-mode-upgrading[_Upgrading an OpenShift Container Platform cluster configured for manual mode with STS_].
+* If your cluster uses manually maintained credentials with the AWS Security Token Service (STS), obtain a copy of the `ccoctl` utility from the release image being updated to and use it to process any updated credentials. For more information, see xref:../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#sts-mode-upgrading[_Upgrading an OpenShift Container Platform cluster configured for manual mode with STS_].
 * If you run an Operator or you have configured any application with the pod disruption budget, you might experience an interruption during the upgrade process. If `minAvailable` is set to 1 in `PodDisruptionBudget`, the nodes are drained to apply pending machine configs which might block the eviction process. If several nodes are rebooted, all the pods might run on only one node, and the `PodDisruptionBudget` field can prevent the node drain.
 
 [role="_additional-resources"]
diff --git a/updating/updating-cluster-within-minor.adoc b/updating/updating-cluster-within-minor.adoc
@@ -24,7 +24,7 @@ See xref:../authentication/using-rbac.adoc[Using RBAC to define and apply permis
 //remove this???^ or maybe just add another bullet that you can break up the update?
 * To accommodate the time it takes to update, you are able to do a partial update by updating the worker or custom pool nodes. You can pause and resume within the progress bar of each pool.
 * If your cluster uses manually maintained credentials, ensure that the Cloud Credential Operator (CCO) is in an upgradeable state. For more information, see xref:../updating/updating-cluster-cli.adoc#manually-maintained-credentials-upgrade_updating-cluster-cli[Upgrading clusters with manually maintained credentials].
-* If your cluster uses manually maintained credentials with the AWS Secure Token Service (STS), obtain a copy of the `ccoctl` utility from the release image being updated to and use it to process any updated credentials. For more information, see xref:../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#sts-mode-upgrading[Upgrading an OpenShift Container Platform cluster configured for manual mode with STS].
+* If your cluster uses manually maintained credentials with the AWS Security Token Service (STS), obtain a copy of the `ccoctl` utility from the release image being updated to and use it to process any updated credentials. For more information, see xref:../authentication/managing_cloud_provider_credentials/cco-mode-sts.adoc#sts-mode-upgrading[Upgrading an OpenShift Container Platform cluster configured for manual mode with STS].
 * Review the list of APIs that were removed in Kubernetes 1.25, migrate any affected components to use the new API version, and provide the administrator acknowledgment. For more information, see xref:../updating/updating-cluster-prepare.adoc#updating-cluster-prepare[Preparing to update to {product-title} 4.12].
 * If you run an Operator or you have configured any application with the pod disruption budget, you might experience an interruption during the upgrade process. If `minAvailable` is set to 1 in `PodDisruptionBudget`, the nodes are drained to apply pending machine configs which might block the eviction process. If several nodes are rebooted, all the pods might run on only one node, and the `PodDisruptionBudget` field can prevent the node drain.
 
diff --git a/updating/updating-restricted-network-cluster/restricted-network-update.adoc b/updating/updating-restricted-network-cluster/restricted-network-update.adoc
