With the growing popularity of vSphere 8, more and more customers are starting to adopt vSphere with Tanzu as their de-facto Kubernetes platform since it provides them the flexibility to either: Deploy containers directly onto the hypervisor (vSphere Pods – in a certain deployment topology) or Manage their own Kubernetes cluster (TKCs). Kubernetes aside, vSphere with Tanzu also provides users the ability to declaratively deploy Virtual Machines via VMService about which I have written here.
Diving right into the topic, in today’s fast-paced modernisation era, Kubernetes adoption is increasing and so is the use of Tanzu Kubernetes Clusters or Guest Clusters within a vSphere environment. And for various reasons such as troubleshooting, one might have to SSH into the Master or Worker nodes that form this cluster.
We deploy the this Kubernetes cluster through a manifest file and it gets created from a template that we have already downloaded onto the vSphere environment via a Subscribed Content Library. So, we wouldn’t know the username/password combination to login to any of these nodes. However, there’s a procedure through which the password can be fetched which is well documented.
Now, imagine a situation where you are in the middle of a Sev-1 issue and have already engaged support, they would most certainly want you to login to the guest cluster. At this point, if you go searching for commands to fetch the password, it certainly affects your time to recovery 😛 Though only a few minutes, this script attempts to reduce the effort it takes to retrieve the password. This also helps while you manage 100s of clusters in an environment.
For this script to work, you just need to have “kubectl” installed on the machine from wherever this script will be run. Also, certain permissions on the namespace (More about it in the later section).
#!/bin/bash
#!/bin/sh
read -p 'Username:' k_username
read -sp 'Password:' k_password
echo
export KUBECTL_VSPHERE_PASSWORD="$k_password"
read -p 'Cluster Name:' k_cluster_name
read -p 'Cluster Namespace:' k_cluster_namespace
login_cmd=$(kubectl vsphere login --server=10.220.55.98 --insecure-skip-tls-verify --vsphere-username "$k_username" --tanzu-kubernetes-cluster-namespace "$k_cluster_namespace" 2>login_error.txt 1>login_out.txt)
if [ -s login_error.txt ]; then
echo "Error occured during login:"
cat login_error.txt
rm -f login_error.txt
rm -f login_out.txt
kubectl vsphere logout 2>&1 >/dev/null
else
ns_context=$(kubectl config use-context "$k_cluster_namespace" 2>ns_login_error.txt 1>ns_login_out.txt )
if [ -s ns_login_error.txt ]; then
echo "Error occured while logging in to namespace context:"
cat ns_login_error.txt
rm -f ns_login_error.txt
rm -f ns_login_out.txt
kubectl vsphere logout 2>&1 >/dev/null
else
echo "Logged into Namespace Context"
secretname=$k_cluster_name"-ssh-password"
echo "Retrieving secret value"
get_secret=$((kubectl get secret "$secretname" -o yaml | grep ssh-passwordkey | awk '{print $2}' | base64 -d) 2>getsecret_error.txt 1>getsecret_out.txt)
if [ -s getsecret_error.txt ]; then
echo "Error occured while retrieving secret:"
cat getsecret_error.txt
rm -f getsecret_error.txt
rm -f getsecret_out.txt
kubectl vsphere logout 2>&1 >/dev/null
else
echo "Password for your cluster nodes: $(cat getsecret_out.txt)"
rm -f getsecret_out.txt
rm -f getsecret_error.txt
kubectl vsphere logout 2>&1 >/dev/null
fi
rm -f ns_login_error.txt
rm -f ns_login_out.txt
kubectl vsphere logout 2>&1 >/dev/null
fi
rm -f login_error.txt
rm -f login_out.txt
kubectl vsphere logout 2>&1 >/dev/null
fi
This script attempts to capture all the errors that might occur along the way: Incorrect credentials, incorrect namespace information, incorrect cluster information (thereby secret information). And evidences for those are in the following sections.
Incorrect username/password
In this scenario, “kubectl” login to the supervisor context itself will fail which is captured below
If you notice the screenshot, I have specified incorrect namespace and cluster details as well. However, since the login failed, the script wouldn’t proceed further to check the namespace and cluster info.
Incorrect namespace information
In this scenario, no context would be available with the namespace name that you provided and hence the following error
Incorrect cluster information
In this scenario, the secret will not be found within the namespace and will fail with the following error
Retrieve your secret
When you specify the right credentials, you should be able to retrieve the secret as shown below.
Namespace Permissions
The namespace is configured with the following permissions and the users are assigned read-only permissions on the vCenter.
NSView User
Here’s what happens, when the nsview user runs the command manually. He has the permissions to list clusters, but not the secrets.
So, as you can see, the script will fail too..
NSEditor User
Here’s what happens, when the nseditor user runs the command manually.
So, the script should now succeed as well.
That’s it, the last piece was to show you, the SSO user running the script should bare minimum have “Can edit” permissions on the namespace the cluster is deployed in.
Happy learning! 🙂
One comment