Update: 10-10-2024

Author: cldocid2

access-iam-rbac.md

@@ -2,7 +2,7 @@
 
 copyright: 
   years: 2024, 2024
-lastupdated: "2024-10-07"
+lastupdated: "2024-10-10"
 
 
 keywords: openshift, {{site.data.keyword.openshiftlong_notm}}, kubernetes, infrastructure, rbac, policy, role-based access control
@@ -120,7 +120,7 @@ To create custom RBAC permissions,
     | `rules.apiGroups` | Specify the Kubernetes [API groups](https://kubernetes.io/docs/reference/using-api/#api-groups){: external} that you want users to be able to interact with, such as `"apps"`, `"batch"`, or `"extensions"`. For access to the core API group at REST path `api/v1`, leave the group blank: `[""]`. |
     | `rules.resources` | Specify the Kubernetes [resource types](https://kubernetes.io/docs/reference/kubectl/quick-reference/){: external} to which you want to grant access, such as `"daemonsets"`, `"deployments"`, `"events"`, or `"ingresses"`. If you specify `"nodes"`, then the kind must be `ClusterRole`. |
     | `rules.verbs` | Specify the types of [actions](https://kubectl.docs.kubernetes.io/){: external} that you want users to be able to do, such as `"get"`, `"list"`, `"describe"`, `"create"`, or `"delete"`. |
-    {: caption="Table 3. Understanding the YAML parameters" caption-side="bottom"}
+    {: caption="Understanding the YAML parameters" caption-side="bottom"}
 
 1. Create the role or cluster role in your cluster.
 
@@ -180,7 +180,7 @@ To create custom RBAC permissions,
     | `roleRef.kind` | Enter the same value as the `kind` in the role `.yaml` file: `Role` or `ClusterRole`. |
     | `roleRef.name` | Enter the name of the role `.yaml` file. |
     | `roleRef.apiGroup` | Use `rbac.authorization.k8s.io`. |
-    {: caption="Table 3. Understanding the YAML parameters" caption-side="bottom"}
+    {: caption="Understanding the YAML parameters" caption-side="bottom"}
 
 1. Create the role binding or cluster role binding resource in your cluster.
 
@@ -265,7 +265,7 @@ Before you begin: [Access your {{site.data.keyword.redhat_openshift_notm}} clust
     | `rules.apiGroups` | Specify the Kubernetes [API groups](https://kubernetes.io/docs/reference/using-api/#api-groups){: external} that you want users to be able to interact with, such as `"apps"`, `"batch"`, or `"extensions"`. For access to the core API group at REST path `api/v1`, leave the group blank: `[""]`. |
     | `rules.resources` | Specify the Kubernetes [resource types](https://kubernetes.io/docs/reference/kubectl/quick-reference/){: external} to which you want to grant access, such as `"daemonsets"`, `"deployments"`, `"events"`, or `"ingresses"`. |
     | `rules.verbs` | Specify the types of [actions](https://kubectl.docs.kubernetes.io/){: external} that you want users to be able to do, such as `"get"`, `"list"`, `"describe"`, `"create"`, or `"delete"`. |
-    {: caption="Table 4. Understanding the YAML parameters" caption-side="bottom"}
+    {: caption="Understanding the YAML parameters" caption-side="bottom"}
 
 2. Create the cluster role in your cluster. Any users that have a role binding to the `admin` cluster role now have the additional permissions from the `view-pod-metrics` cluster role.
     ```sh
@@ -369,7 +369,7 @@ The following table shows the Kubernetes resource permissions that are granted b
 | Writer role | When scoped to one namespace: **`edit`** cluster role applied by the **`ibm-edit`** role binding in that namespace. \n \n When scoped to all namespaces: **`edit`** cluster role applied by the **`ibm-edit`** role binding in each namespace of the cluster | - Read/write access to resources in a namespace \n - No read/write access to roles and role bindings< \n - Access the Kubernetes dashboard to view resources in a namespace. |
 | Manager role | When scoped to one namespace: **`admin`** cluster role applied by the **`ibm-operate`** role binding in that namespace \n  \n When scoped to all namespaces: **`cluster-admin`** cluster role applied by the **`ibm-admin`** cluster role binding that applies to all namespaces | When scoped to one namespace: \n - Read/write access to all resources in a namespace but not to resource quota or the namespace itself \n - Create RBAC roles and role bindings in a namespace  \n - Access the Kubernetes dashboard to view all resources in a namespace  \n When scoped to all namespaces: \n - Read/write access to all resources in every namespace \n - Create RBAC roles and role bindings in a namespace or cluster roles and cluster role bindings in all namespaces \n - Access the Kubernetes dashboard \n - Create an Ingress resource that makes apps publicly available \n - Review cluster metrics such as with the `oc top pods`, `oc top nodes`, or `oc get nodes` commands | 
 | Any service access role | All users of a {{site.data.keyword.redhat_openshift_notm}} cluster are given the `basic-users`. | |  - Get basic information about projects that the user has access to. \n - Create authorized resources in the projects that the user has access to. \n - For more information, see the [{{site.data.keyword.redhat_openshift_notm}} docs](https://docs.openshift.com/container-platform/4.16/authentication/using-rbac.html){: external} |
-{: caption="Table 1. Kubernetes resource permissions by service and corresponding RBAC roles" caption-side="bottom"}
+{: caption="Kubernetes resource permissions by service and corresponding RBAC roles" caption-side="bottom"}
 
 ### Kubernetes resource permissions per RBAC role
 {: #rbac_ref}
@@ -436,7 +436,7 @@ The following table shows the permissions that are granted by each RBAC role to
 | `services/proxy` | - | create, delete, `deletecollection`, get, list, patch, update, watch | create, delete, `deletecollection`, get, list, patch, update, watch |
 | `statefulsets.apps` | get, list, watch | create, delete, `deletecollection`, get, list, patch, update, watch | create, delete, `deletecollection`, get, list, patch, update, watch |
 | `statefulsets.apps/scale` | get, list, watch | create, delete, `deletecollection`, get, list, patch, update, watch | create, delete, `deletecollection`, get, list, patch, update, watch |
-{: caption="Table 1. Kubernetes resource permissions granted by each predefined RBAC role" caption-side="bottom"}
+{: caption="Kubernetes resource permissions granted by each predefined RBAC role" caption-side="bottom"}
 
 
 

app-plan.md

@@ -2,7 +2,7 @@
 
 copyright: 
   years: 2014, 2024
-lastupdated: "2024-10-07"
+lastupdated: "2024-10-10"
 
 
 keywords: kubernetes, deploy, app, openshift
@@ -326,7 +326,7 @@ The more widely you distribute your setup across multiple worker nodes and clust
 
 Review the following potential app setups that are ordered with increasing degrees of availability.
 
-![Stages of high availability for an app](images/cs_app_ha_roadmap-mz.png){: caption="Figure 1. Stages of high availability for an app" caption-side="bottom"}
+![Stages of high availability for an app](images/cs_app_ha_roadmap-mz.png){: caption="Stages of high availability for an app" caption-side="bottom"}
 
 1. A deployment with n+2 pods that are managed by a replica set on a single node.
 2. A deployment with n+2 pods that are managed by a replica set and spread across multiple nodes (anti-affinity) in a single zone cluster.

app-update.md

@@ -2,7 +2,7 @@
 
 copyright: 
   years: 2014, 2024
-lastupdated: "2024-08-06"
+lastupdated: "2024-10-10"
 
 
 keywords: kubernetes, openshift, red hat, red hat openshift, update, upgrade, openshift
@@ -78,7 +78,7 @@ To scale your apps:
     | `--cpu-percent` | The average CPU utilization that is maintained by the Horizontal Pod Autoscaler, which is specified as a percentage. |
     | `--min` | The minimum number of deployed pods that are used to maintain the specified CPU utilization percentage. |
     | `--max` | The maximum number of deployed pods that are used to maintain the specified CPU utilization percentage. |
-    {: caption="Table 2. Understanding your command options" caption-side="bottom"}
+    {: caption="Understanding your command options" caption-side="bottom"}
 
 ## Managing rolling deployments to update your apps
 {: #app_rolling}
@@ -284,7 +284,3 @@ Before you begin, you need two clusters and the **Manager** [service access role
     oc get all
     ```
     {: pre}
-
-
-
-

benchmarks_415_co.md

@@ -2,7 +2,7 @@
 
 copyright: 
   years: 2024, 2024
-lastupdated: "2024-06-03"
+lastupdated: "2024-10-10"
 
 
 keywords: openshift, benchmarks, 4.15, compliance operator, compliance
@@ -73,7 +73,7 @@ The master node configuration is not stored as a set of files; therefore, rules
 | 1.2.33|Ensure that the `--encryption-provider-config` argument is set as appropriate|Manual|1|[Not checked](#co-benchmark-415-remdiations) |
 | 1.2.34|Ensure that encryption providers are appropriately configured|Manual|1|[Not checked](#co-benchmark-415-remdiations) |
 | 1.2.35|Ensure that the API Server only makes use of Strong Cryptographic Ciphers|Manual|1|Pass |
-{: caption="Table 1. Benchmarks for api server." caption-side="top"}
+{: caption="Benchmarks for api server." caption-side="top"}
 {: caption="Section 1.2 API server benchmark results"}
 
 ### 1.3 Controller manager
@@ -229,6 +229,3 @@ Follow the instruction in [Using the compliance operator](/docs/openshift?topic=
 | 5.2.8 | {{site.data.keyword.openshiftlong_notm}} installs custom SCCs. |
 | 5.3.2 | {{site.data.keyword.openshiftlong_notm}} has a set of default Calico network policies defined and additional network policies can optionally be added. |
 {: caption="Remediations and explanations"}
-
-
-

cluster-plan-network-classic.md

@@ -2,7 +2,7 @@
 
 copyright: 
   years: 2022, 2024
-lastupdated: "2024-08-12"
+lastupdated: "2024-10-10"
 
 
 keywords: kubernetes, openshift network, classic
@@ -151,7 +151,7 @@ For example, if your worker nodes are connected to a private VLAN only, but you
 In this scenario, you want to run workloads in a classic cluster that are accessible to requests from the Internet so that end users can access your apps. You want the option of isolating public access in your cluster and of controlling what public requests are permitted to your cluster. Additionally, your workers have automatic access to any {{site.data.keyword.cloud_notm}} services that you want to connect with your cluster.
 {: shortdesc}
 
-![Architecture image for a cluster that runs internet-facing workloads.](images/cs_clusters_planning_internet.png){: caption="Figure 1. Network setup for a cluster that runs internet-facing workloads" caption-side="bottom"}
+![Architecture image for a cluster that runs internet-facing workloads.](images/cs_clusters_planning_internet.png){: caption="Network setup for a cluster that runs internet-facing workloads" caption-side="bottom"}
 
 ### Worker-to-worker communication in classic clusters with internet-facing workloads
 {: #internet-facing-worker}
@@ -188,7 +188,7 @@ Ready to get started with a cluster for this scenario? After you plan your [high
 In this scenario, you want to run workloads in a classic cluster that are accessible to services, databases, or other resources in your on-premises data center. However, you might need to provide limited public access to your cluster, and want to ensure that any public access is controlled and isolated in your cluster. For example, you might need your workers to access an {{site.data.keyword.cloud_notm}} service that does not support private cloud service endpoints, and must be accessed over the public network. Or you might need to provide limited public access to an app that runs in your cluster. To achieve this cluster setup, you can configure a gateway appliance, such as a Virtual Router Appliance (Vyatta), as a public gateway and firewall.
 {: shortdesc}
 
-![Architecture image for a cluster that uses a gateway appliance for secure public access.](images/cs_clusters_planning_gateway.png){: caption="Figure 1. Network setup for a cluster that uses a gateway appliance for secure public access" caption-side="bottom"}
+![Architecture image for a cluster that uses a gateway appliance for secure public access.](images/cs_clusters_planning_gateway.png){: caption="Network setup for a cluster that uses a gateway appliance for secure public access" caption-side="bottom"}
 
 ### Worker-to-worker communication, worker-to-master and user-to-master communication with a gateway appliance
 {: #limited-public-gw-worker}

cluster-plan-network-vpc.md

@@ -2,7 +2,7 @@
 
 copyright: 
   years: 2022, 2024
-lastupdated: "2024-09-23"
+lastupdated: "2024-10-10"
 
 
 keywords: kubernetes, openshift network
@@ -189,7 +189,7 @@ In this scenario, you run workloads in a VPC cluster that are accessible to requ
 {: shortdesc}
 
 
-![Network setup for a VPC cluster that runs internet-facing app workloads.](images/roks_ov_vpc_pub.png){: caption="Figure 1. Network setup for a VPC cluster that runs internet-facing app workloads" caption-side="bottom"}
+![Network setup for a VPC cluster that runs internet-facing app workloads.](images/roks_ov_vpc_pub.png){: caption="Network setup for a VPC cluster that runs internet-facing app workloads" caption-side="bottom"}
 
 ### Worker-to-worker communication
 {: #vpc-no-pgw-worker}

costs-reserved.md

@@ -2,7 +2,7 @@
 
 copyright: 
   years: 2014, 2024
-lastupdated: "2024-09-10"
+lastupdated: "2024-10-10"
 
 
 keywords: openshift, reservations, worker node
@@ -40,7 +40,7 @@ A reservation is a type of {{site.data.keyword.cloud_notm}} resource that you se
 
 Review the following diagram for an example scenario of how you might set up your reservation and contracts to use across clusters.
 
-![Overview of reservations for {{site.data.keyword.openshiftlong_notm}}.](images/reservations-ov.png "Overview of reservations for {{site.data.keyword.openshiftlong_notm}}"){: caption="Figure 1. An example scenario of using a reservation for worker nodes in your clusters." caption-side="bottom"}
+![Overview of reservations for {{site.data.keyword.openshiftlong_notm}}.](images/reservations-ov.png "Overview of reservations for {{site.data.keyword.openshiftlong_notm}}"){: caption="An example scenario of using a reservation for worker nodes in your clusters." caption-side="bottom"}
 
 **Reservation**: The reservation contains details such as the container platform, worker node flavor, location, and infrastructure provider.
 

data-security.md

@@ -2,7 +2,7 @@
 
 copyright: 
   years: 2014, 2024
-lastupdated: "2024-02-28"
+lastupdated: "2024-10-10"
 
 
 keywords: openshift dedicated hosts
@@ -28,7 +28,7 @@ For each cluster that you create with {{site.data.keyword.openshiftlong_notm}},
 |-------|----------|
 |Personal information|The email address of the {{site.data.keyword.cloud_notm}} account that created the cluster.|
 |Sensitive information|  - The TLS certificate and secret that is used for the assigned Ingress subdomain.  \n - The certificate authority that is used for the TLS certificate.  \n - The certificate authority, private keys, and TLS certificates for the {{site.data.keyword.redhat_openshift_notm}} master components, including the {{site.data.keyword.redhat_openshift_notm}} API server, etcd data store, and VPN.  \n - A customer root key in {{site.data.keyword.keymanagementservicelong_notm}} for each {{site.data.keyword.cloud_notm}} account that is used to encrypt personal and sensitive information.|
-{: caption="Table 1. Information that is stored with IBM" caption-side="bottom"}
+{: caption="Information that is stored with IBM" caption-side="bottom"}
 
 ## How is my information stored and encrypted?
 {: #pi-storage}
@@ -60,5 +60,3 @@ What options do I have to permanently remove my data?
 
 - **Open an {{site.data.keyword.cloud_notm}} support case**: Contact IBM Support to remove your personal and sensitive information from {{site.data.keyword.openshiftlong_notm}}. For more information, see [Getting support](/docs/get-support?topic=get-support-using-avatar).
 - **End your {{site.data.keyword.cloud_notm}} subscription**: After you end your {{site.data.keyword.cloud_notm}} subscription, {{site.data.keyword.openshiftlong_notm}} removes the customer root key in {{site.data.keyword.keymanagementservicelong_notm}} that IBM created and managed for you as well as all the personal and sensitive information from the etcd data store and {{site.data.keyword.cos_short}} backup.
-
-

document-environment.md

@@ -2,7 +2,7 @@
 
 copyright: 
   years: 2024, 2024
-lastupdated: "2024-08-06"
+lastupdated: "2024-10-10"
 
 
 keywords: kubernetes, help, connectivity, debugging, openshift, apps, support, network
@@ -75,14 +75,14 @@ Each of these VPC ALBs is a part of a separate cluster in the respective region.
 
 Note that some of these connections are over the public network. Some are over a private network in the same VPC, and some use the private network in {{site.data.keyword.cloud_notm}} between components in a VPC and a service in {{site.data.keyword.cloud_notm}}.
 
-![Multi-cluster Diagram](images/multi-cluster-with-glb-architecture.jpg){: caption="Figure 1. Multi-cluster architecture" caption-side="bottom"}
+![Multi-cluster Diagram](images/multi-cluster-with-glb-architecture.jpg){: caption="Multi-cluster architecture" caption-side="bottom"}
 
 ### Example 3: A VSI client contacting a VPC network load balancer with an external service backend
 {: #example-arch-3}
 
 In the following example, the client is a Classic VSI in {{site.data.keyword.cloud_notm}}. The VSI connects via the private network to a private VPC network load balancer (NLB) created for an VPC cluster. This NLB balances traffic to one of the three VPC worker nodes via the NodePort for the cluster Load Balancer service. The cluster Load Balancer service then sends the traffic to one of the app pods which connect to an external cloud service outside of {{site.data.keyword.cloud_notm}} over the public network.
 
-![NLB with an external service](images/vsi-nlb-external-service-architecture.jpg){: caption="Figure 2. NLB with external service" caption-side="bottom"}
+![NLB with an external service](images/vsi-nlb-external-service-architecture.jpg){: caption="NLB with external service" caption-side="bottom"}
 
 
 ## Step 2: Choose a tool

encryption.md

@@ -2,7 +2,7 @@
 
 copyright: 
   years: 2014, 2024
-lastupdated: "2024-08-21"
+lastupdated: "2024-10-10"
 
 
 keywords: openshift, {{site.data.keyword.openshiftlong_notm}}, kubernetes, red hat, encrypt, security, kms, root key, crk
@@ -36,7 +36,7 @@ The following table outlines the encryption options for {{site.data.keyword.open
 | [Worker node disks](#worker-node-encryption) | Yes | Yes | During cluster creation or worker pool creation. | - {{site.data.keyword.hscrypto}}  \n - {{site.data.keyword.keymanagementserviceshort}} | Yes |
 | [Cluster secrets](#cluster-secret-encryption) | No | Yes | After cluster creation by using `kms enable`. | - {{site.data.keyword.hscrypto}}  \n - {{site.data.keyword.keymanagementserviceshort}} | Cross account supported for Classic and VPC clusters only. |
 | [Persistent storage](#persistent-encryption) | Depends on the storage provider. | Depends on provider | After cluster creation, when setting up storage. | - {{site.data.keyword.hscrypto}}  \n - {{site.data.keyword.keymanagementserviceshort}} | Depends on the storage provider. |
-{: caption="Table 1. Default and optional data encryption" caption-side="bottom"}
+{: caption="Default and optional data encryption" caption-side="bottom"}