Merge pull request #85814 from mletalie/OSDOCS-11922

[OSDOCS-11922]:Update "SRE and service account access" page to include GCP Private Service Connect-based access

Author: jab-rh

modules/sre-cluster-access.adoc

@@ -28,6 +28,10 @@ The information presented below is an overview of the process an SRE must perfor
 
 *** Accessing a PrivateLink cluster: Request is sent to the Red Hat Transit Gateway, which then connects to a Red Hat VPC per region. The VPC that receives the request will be dependent on the target private cluster's region. Within the VPC, there is a private subnet that contains the PrivateLink endpoint to the customer's PrivateLink cluster.
 
+ifdef::openshift-dedicated[]
+*** Accessing a Private Service Connect (PSC) cluster: Request is sent to Red Hat's internal backend infrastructure, which routes the traffic through a secured, trusted network to Red Hat's Management project in GCP. The Red Hat Management project includes VPC, which is configured with subnets in multiple regions, each containing a PSC endpoint that provides private access to the customer's cluster in the respective region. The traffic is routed through the appropriate regional subnet, ensuring secure and private access to the cluster without traversing the public internet.
+endif::openshift-dedicated[]
+
 ifdef::openshift-rosa[]
 SREs access ROSA clusters through the web console or command line interface (CLI) tools. Authentication requires multi-factor authentication (MFA) with industry-standard requirements for password complexity and account lockouts. SREs must authenticate as individuals to ensure auditability. All authentication attempts are logged to a Security Information and Event Management (SIEM) system.
 
@@ -64,7 +68,7 @@ Each of these access types have different levels of access to components:
 == SRE access to AWS accounts
 Red Hat personnel do not access AWS accounts in the course of routine {product-title} operations. For emergency troubleshooting purposes, the SREs have well-defined and auditable procedures to access cloud infrastructure accounts.
 
-In the isolated backplane flow, SREs request access to a customer's support role. This request is just-in-time (JIT) processed by the backplane API which dynamically updates the organization role's permissions to a specific SRE personnel's account. This SRE's account is given access to a specific Red Hat customer's environment. SRE access to a Red Hat customer's environment is a temporary, short-lived access that is only established at the time of the access request. 
+In the isolated backplane flow, SREs request access to a customer's support role. This request is just-in-time (JIT) processed by the backplane API which dynamically updates the organization role's permissions to a specific SRE personnel's account. This SRE's account is given access to a specific Red Hat customer's environment. SRE access to a Red Hat customer's environment is a temporary, short-lived access that is only established at the time of the access request.
 
 Access to the STS token is audit-logged and traceable back to individual users. Both STS and non-STS clusters use the AWS STS service for SRE access. Access control uses the unified backplane flow when the `ManagedOpenShift-Technical-Support-Role` has the `ManagedOpenShift-Support-Access` policy attached, and this role is used for administration. Access control uses the isolated backplane flow when the `ManagedOpenShift-Support-Role` has the `ManagedOpenShift-Technical-Support-<org_id>` policy attached. See the KCS article link:https://access.redhat.com/solutions/7045629[Updating Trust Policies for ROSA clusters] for more information.