equinix-labs/terraform-equinix-metal-eks-anywhere

Control Plane and Data Plane nodes are configured with a pre existing SSH key

Opened this issue · 3 comments

I used the terraform script to provision a bare metal cluster. The script provisioned an Admin machine with a new SSH key and created a CP and DP nodes with SSH keys of someone else in the account. It should have used my newly created SSH key the same one we use to login admin machine. This i see is an issue in the script.

CP and DP nodes with SSH keys of someone else in the account

The CP and DP operating systems are not configured via Terraform, they are configured with Tinkerbell (which is configured via Terraform). It sounds like we may not be mapping the SSH Key variables correctly.

I ran through this and I believe the SSH keys are configured as intended. I think some of the trickier parts of the configuration are that the SSH key that is configured for access lives in the Terraform users ~/.ssh directory and on the eks-admin nodes /root/.ssh directory (using the same name on both systems). Another point that I tripped over is that the cp/dp nodes may only be accessed using the ec2-user account.

ssh -o "IdentitiesOnly=yes" -i $(terraform output -raw eksa_admin_ssh_key) root@$(terraform output -raw eksa_admin_ip)

Once on eks-admin, you can access the cp node with:

IP=$(kubectl get nodes --selector=node-role.kubernetes.io/control-plane -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}')
ssh -i $(ls ~/.ssh/my-eksa-cluster* | head -n1) ec2-user@$IP # somewhat hard coded the key name

Knowing the cp node IP, you can also access this from where you ran Terraform (I don't have a shorthand way to grab that IP from Terraform - if you can add 1 to the EIP range, you would have it):

ssh -o "IdentitiesOnly=yes" -i $(terraform output -raw eksa_admin_ssh_key) ec2-user@THE_CP_IP

Note: The following doesn't work because the IP address Equinix Metal assigned to the CP node at device creation is discarded when the node is converted to Layer2. The correct IP address to use is the first address in the EIP pool which is assigned to the Gateway device and provided to Tinkerbell.

ssh -o "IdentitiesOnly=yes" -i $(terraform output -raw eksa_admin_ssh_key) ec2-user@$(terraform show -json  | jq -r '.values.root_module.child_modules | .[].resources | .[] | select(.address == "module.eksa.equinix_metal_device.eksa_node_cp[0]").values.access_public_ipv4')

My agent and EM project-configured SSH keys did not have access to the cp and dp nodes. The only key that worked was the one configured by Terraform.

[ec2-user@admin]$ cat ~/.ssh/authorized_keys  | wc -l
1

The eksa-admin node, however, did contain all of the SSH keys configured in my EM project. I don't think this should be considered a bug, but it could use more clarity.

root@eksa-q1cwms-admin:~# [ $(cat ~/.ssh/authorized_keys | wc -l) -gt 1 ] && echo more keys
more keys