From 7cb826b5effd3fc354bbd8f578dbf88e468581e5 Mon Sep 17 00:00:00 2001 From: dfitzmau Date: Mon, 11 May 2026 11:58:33 +0100 Subject: [PATCH] OCPBUGS-85278: Updated the security-command-line-host-access.adoc file for no node reboot --- modules/security-command-line-host-access.adoc | 13 ++++++++----- .../security/security-host-sec.adoc | 4 ++++ 2 files changed, 12 insertions(+), 5 deletions(-) diff --git a/modules/security-command-line-host-access.adoc b/modules/security-command-line-host-access.adoc index 457b3e3665be..01957241c49f 100644 --- a/modules/security-command-line-host-access.adoc +++ b/modules/security-command-line-host-access.adoc @@ -6,16 +6,19 @@ [id="security-command-line-host-access_{context}"] = Command-line host access -Direct access to a host must be restricted to avoid modifying the host or accessing pods that should not be accessed. For users who need direct access to a host, it is recommended to use an external authenticator, like SSSD with LDAP, to manage access. This helps maintain consistency across the cluster through the Machine Config Operator. +[role="_abstract"] +Configure an external authenticator to restrict direct access and prevent unauthorized modifications. The Machine Config Operator (MCO) manages these logins and maintains consistency across your cluster. + +Examples of external authenticators include lightweight directory access protocol (LDAP) and System Security Services Daemon (SSSD). If a node reboot leads to timeout issues, create a node disruption policy. With this policy, you can configure an external authenticator on a host without requiring a node reboot. For more information, see "Using node disruption policies to minimize disruption from machine config changes" in the _Additional resources_ section. [IMPORTANT] ==== Do not configure direct access to the root ID on any {product-title} cluster server. ==== -You can connect to a node in the cluster using the following methods: +You can connect to a node in the cluster by using the following methods: -Using debug pod:: This is the recommended method to access a node. To debug or connect to a node, run the following command: +Using debug pod:: Red{nbsp}Hat recommends this method to access a node. To debug or connect to a node, run the following command: + [source,terminal] ---- @@ -31,7 +34,7 @@ After connecting to the node, run the following command to get access to the roo + This gives you root access within a debug pod on the node. For more information, see "Starting debug pods with root access". -Direct SSH:: Avoid using the root user. Instead, use the core user ID (or your own ID). To connect to the node using SSH, run the following command: +Direct SSH:: Avoid using the root user. Instead, use the core user ID (or your own ID). To connect to the node by using SSH, run the following command: + [source,terminal] ---- @@ -43,7 +46,7 @@ $ ssh core@ The core user ID is initially given `sudo` privileges within the cluster. ==== + -If you cannot connect to a node using SSH, see link:https://access.redhat.com/solutions/4073041[How to connect to {product-title} 4.x Cluster nodes using SSH bastion pod] to add your SSH key to the core user. +If you cannot connect to a node by using SSH, add your SSH key to the core user. For more information, see "How to connect to {product-title} 4.x Cluster nodes using SSH bastion pod" in the _Additional resources_ section. + After connecting to the node using SSH, run the following command to get access to the root shell: + diff --git a/post_installation_configuration/day_2_core_cnf_clusters/security/security-host-sec.adoc b/post_installation_configuration/day_2_core_cnf_clusters/security/security-host-sec.adoc index d05d830f6ef7..f4604473880a 100644 --- a/post_installation_configuration/day_2_core_cnf_clusters/security/security-host-sec.adoc +++ b/post_installation_configuration/day_2_core_cnf_clusters/security/security-host-sec.adoc @@ -22,6 +22,10 @@ include::modules/security-command-line-host-access.adoc[leveloffset=+1] [role="_additional-resources"] .Additional resources +* xref:../../../machine_configuration/machine-config-node-disruption.adoc#machine-configs-configure_machine-config-node-disruption[Using node disruption policies to minimize disruption from machine config changes] + * xref:../../../support/troubleshooting/investigating-pod-issues.adoc#starting-debug-pods-with-root-access_investigating-pod-issues[Starting debug pods with root access] +* link:https://access.redhat.com/solutions/4073041[How to connect to {product-title} 4.x Cluster nodes using SSH bastion pod] + include::modules/security-linux-capabilities-overview.adoc[leveloffset=+1]