Computer Notes/Security Services Platform/Accessing the K8 Cluster: Difference between revisions

From Cramsession
Jump to navigationJump to search
✍️ Verified Author: Mflavell • Click to view professional profile & credentials
(Created page with "'''SSH key pair authentication''' is a public-key cryptographic mechanism used within the Secure Shell (SSH) protocol to authenticate users or machines attempting to establish a remote network connection. Unlike traditional password-based authentication, key pair authentication relies on asymmetric cryptography, utilizing a mathematically linked pair of cryptographic keys: a '''public key''' and a '''private key'''. == Mechanism and Architecture == SSH key authenticatio...")
 
No edit summary
Line 1: Line 1:
'''SSH key pair authentication''' is a public-key cryptographic mechanism used within the Secure Shell (SSH) protocol to authenticate users or machines attempting to establish a remote network connection. Unlike traditional password-based authentication, key pair authentication relies on asymmetric cryptography, utilizing a mathematically linked pair of cryptographic keys: a '''public key''' and a '''private key'''.
'''Accessing Security Services Platform (SSP) Kubernetes Cluster Nodes from SSPI using Key Pair Authentication''' is a operational procedure used by system administrators to establish secure, passwordless SSH sessions between a VMware Security Services Platform Installer (SSPI) appliance and its managed Kubernetes (K8s) cluster nodes.  


== Mechanism and Architecture ==
Utilizing public-key cryptography eliminates the reliance on static passwords, simplifies automated node administration, and aligns with security best practices for infrastructure management.
SSH key authentication operates on a challenge-response model designed to verify identity without ever transmitting sensitive credential data over the network.


* '''Private Key:''' Kept strictly confidential on the client machine. It is protected by local file permissions (typically <code>chmod 600</code>) and can be further secured using a passphrase.
== Prerequisites ==
* '''Public Key:''' Placed on the target server, where it is stored in the remote user's configuration file (commonly <code>~/.ssh/authorized_keys</code>).


When a client requests an SSH session:
Before configuring key pair authentication, ensure the following requirements are met:
# The client sends a signal to the server identifying the public key it wishes to use for authentication.
* Administrative shell access (`sysadmin` or `root`) to the deployment SSPI appliance.
# The server checks its <code>authorized_keys</code> file to confirm the key is authorized for the requested account.
* Operational access to the `kubectl` command-line utility configured on the SSPI host.
# The server generates a cryptographic challenge (a random string of data) and sends it to the client.
* Network connectivity on TCP port 22 (SSH) between the SSPI appliance and all target Kubernetes nodes (Control Plane and Worker nodes).
# The client uses its local private key to sign the challenge, generating a digital signature, which is sent back to the server.
# The server uses the stored public key to verify the signature. If valid, the session is established.


== Common Algorithms and Key Generation ==
== Step 1: Generate an SSH Key Pair on SSPI ==
Key pairs are generated using software utilities such as OpenSSH's <code>ssh-keygen</code>. The security and performance of the key pair depend on the underlying mathematical algorithm:


* '''Ed25519:''' An Elliptic Curve Digital Signature Algorithm (EdDSA) scheme offering high performance, immunity to side-channel attacks, and a fixed key length of 256 bits. It is widely considered the modern standard.
If an SSH key pair does not already exist on the SSPI appliance, generate a high-entropy key pair (such as Ed25519) from the SSPI terminal shell.
* '''ECDSA:''' An elliptic curve implementation based on NIST curves. While secure, implementation flaws in random number generation can compromise private keys.
* '''RSA:''' A historical standard based on the integer factorization problem. Modern security guidelines mandate key lengths of 3072 or 4096 bits, as shorter lengths (e.g., 2048-bit) are increasingly vulnerable to advancing computational power.


== Advantages and Applications ==
# Log into the SSPI host via SSH:
SSH key pair authentication offers significant operational benefits over standard passwords:
#: <code>ssh sysadmin@<SSPI_IP_ADDRESS></code>
# Switch to the root account if required for system-level node administration:
#: <code>sudo -i</code>
# Generate a new Ed25519 key pair:
#: <code>ssh-keygen -t ed25519 -C "sspi-k8s-admin"</code>
# Press {{Key|Enter}} to accept the default file location (<code>~/.ssh/id_ed25519</code>).
# Optionally enter a passphrase to secure the private key on disk.


* '''Mitigation of Brute-Force Attacks:''' Modern SSH keys possess high entropy, rendering dictionary and online brute-force attacks mathematically infeasible.
== Step 2: Retrieve Target Kubernetes Node IP Addresses ==
* '''Non-Interactive Automation:''' Keys facilitate secure, automated execution of administrative scripts, deployment pipelines (CI/CD), and infrastructure management tools without human intervention.
 
* '''Granular Access Control:''' System administrators can grant or revoke specific user access instantly by adding or removing individual public keys from a server, eliminating the need to reset global account passwords.
Query the Kubernetes API server from the SSPI command line to identify the internal IP addresses of the cluster nodes:
 
<code>kubectl get nodes -o wide</code>
 
Note the values in the <code>INTERNAL-IP</code> column for the target Control Plane or Worker nodes.
 
== Step 3: Distribute the Public Key to Cluster Nodes ==
 
To establish trust, copy the generated public key (<code>id_ed25519.pub</code>) to the <code>~/.ssh/authorized_keys</code> file on the target node.
 
=== Method A: Using <code>ssh-copy-id</code> (Automated) ===
If password authentication is temporarily enabled on the nodes, run:
 
<code>ssh-copy-id -i ~/.ssh/id_ed25519.pub root@<NODE_INTERNAL_IP></code>
 
Enter the node's password when prompted to append the key automatically.
 
=== Method B: Manual Injection (Pre-deployment or Cluster Spec) ===
If direct password access to the nodes is disabled, inject the public key content directly into the cluster specification or pre-seed file during initial provision:
 
# Display the public key:
#: <code>cat ~/.ssh/id_ed25519.pub</code>
# Copy the string output and append it to <code>/root/.ssh/authorized_keys</code> on the target node file system.
# Ensure correct file permissions on the target node:
#: <code>chmod 700 /root/.ssh && chmod 600 /root/.ssh/authorized_keys</code>
 
== Step 4: Establish Passwordless SSH Connection ==
 
Verify the key pair authentication setup by opening a new SSH connection from the SSPI appliance to the target node:
 
<code>ssh -i ~/.ssh/id_ed25519 root@<NODE_INTERNAL_IP></code>
 
Upon successful authentication, the terminal prompt will update to reflect the target node's hostname without prompting for a password.
 
== Security Best Practices ==
 
* '''Restrict Root File Permissions:''' Verify that the private key on the SSPI appliance maintains strict permissions (<code>chmod 600 ~/.ssh/id_ed25519</code>) to prevent unauthorized read access by non-privileged local users.
* '''Audit Authorized Keys:''' Periodically audit the <code>/root/.ssh/authorized_keys</code> file on cluster nodes to remove obsolete or unauthorized public keys.
* '''Least Privilege:''' Limit direct node SSH access to emergency troubleshooting and diagnostic operations. Standard cluster administrative operations should be performed via `kubectl` or API endpoints.
 
== Troubleshooting ==
 
=== Permission Denied (publickey) ===
If connection fails with a <code>Permission denied (publickey)</code> error:
* Verify key permissions on the SSPI host: <code>chmod 600 ~/.ssh/id_ed25519</code>.
* Check remote permissions on the node: <code>chmod 700 /root/.ssh</code> and <code>chmod 600 /root/.ssh/authorized_keys</code>.
* Verbose SSH output can be reviewed by appending <code>-vvv</code> to the SSH command:
*: <code>ssh -vvv -i ~/.ssh/id_ed25519 root@<NODE_INTERNAL_IP></code>


== See Also ==
== See Also ==
* [[Secure Shell]]
* [[Secure Shell]]
* [[Kubernetes]]
* [[Public-key cryptography]]
* [[Public-key cryptography]]
* [[ssh-keygen]]
* [[ssh-keygen]]


[[Category:Computer access control]]
[[Category:Kubernetes]]
[[Category:Network security]]
[[Category:System Administration]]
[[Category:VMware]]
[[Category:Network Security]]

Revision as of 00:03, 10 September 2026

Accessing Security Services Platform (SSP) Kubernetes Cluster Nodes from SSPI using Key Pair Authentication is a operational procedure used by system administrators to establish secure, passwordless SSH sessions between a VMware Security Services Platform Installer (SSPI) appliance and its managed Kubernetes (K8s) cluster nodes.

Utilizing public-key cryptography eliminates the reliance on static passwords, simplifies automated node administration, and aligns with security best practices for infrastructure management.

Prerequisites

Before configuring key pair authentication, ensure the following requirements are met:

  • Administrative shell access (`sysadmin` or `root`) to the deployment SSPI appliance.
  • Operational access to the `kubectl` command-line utility configured on the SSPI host.
  • Network connectivity on TCP port 22 (SSH) between the SSPI appliance and all target Kubernetes nodes (Control Plane and Worker nodes).

Step 1: Generate an SSH Key Pair on SSPI

If an SSH key pair does not already exist on the SSPI appliance, generate a high-entropy key pair (such as Ed25519) from the SSPI terminal shell.

  1. Log into the SSPI host via SSH:
    ssh sysadmin@<SSPI_IP_ADDRESS>
  2. Switch to the root account if required for system-level node administration:
    sudo -i
  3. Generate a new Ed25519 key pair:
    ssh-keygen -t ed25519 -C "sspi-k8s-admin"
  4. Press Template:Key to accept the default file location (~/.ssh/id_ed25519).
  5. Optionally enter a passphrase to secure the private key on disk.

Step 2: Retrieve Target Kubernetes Node IP Addresses

Query the Kubernetes API server from the SSPI command line to identify the internal IP addresses of the cluster nodes:

kubectl get nodes -o wide

Note the values in the INTERNAL-IP column for the target Control Plane or Worker nodes.

Step 3: Distribute the Public Key to Cluster Nodes

To establish trust, copy the generated public key (id_ed25519.pub) to the ~/.ssh/authorized_keys file on the target node.

Method A: Using ssh-copy-id (Automated)

If password authentication is temporarily enabled on the nodes, run:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@<NODE_INTERNAL_IP>

Enter the node's password when prompted to append the key automatically.

Method B: Manual Injection (Pre-deployment or Cluster Spec)

If direct password access to the nodes is disabled, inject the public key content directly into the cluster specification or pre-seed file during initial provision:

  1. Display the public key:
    cat ~/.ssh/id_ed25519.pub
  2. Copy the string output and append it to /root/.ssh/authorized_keys on the target node file system.
  3. Ensure correct file permissions on the target node:
    chmod 700 /root/.ssh && chmod 600 /root/.ssh/authorized_keys

Step 4: Establish Passwordless SSH Connection

Verify the key pair authentication setup by opening a new SSH connection from the SSPI appliance to the target node:

ssh -i ~/.ssh/id_ed25519 root@<NODE_INTERNAL_IP>

Upon successful authentication, the terminal prompt will update to reflect the target node's hostname without prompting for a password.

Security Best Practices

  • Restrict Root File Permissions: Verify that the private key on the SSPI appliance maintains strict permissions (chmod 600 ~/.ssh/id_ed25519) to prevent unauthorized read access by non-privileged local users.
  • Audit Authorized Keys: Periodically audit the /root/.ssh/authorized_keys file on cluster nodes to remove obsolete or unauthorized public keys.
  • Least Privilege: Limit direct node SSH access to emergency troubleshooting and diagnostic operations. Standard cluster administrative operations should be performed via `kubectl` or API endpoints.

Troubleshooting

Permission Denied (publickey)

If connection fails with a Permission denied (publickey) error:

  • Verify key permissions on the SSPI host: chmod 600 ~/.ssh/id_ed25519.
  • Check remote permissions on the node: chmod 700 /root/.ssh and chmod 600 /root/.ssh/authorized_keys.
  • Verbose SSH output can be reviewed by appending -vvv to the SSH command:
    ssh -vvv -i ~/.ssh/id_ed25519 root@<NODE_INTERNAL_IP>

See Also

Retrieved from "https://cramsession.net/index.php?title=Computer_Notes/Security_Services_Platform/Accessing_the_K8_Cluster&oldid=1836"