Removing All Support Access
This addendum to Support Access covers how to remove all Crusoe support access to a cluster, going beyond disabling future sessions. Use this procedure when you want to ensure that no Crusoe personnel retain any path into the cluster.
When to Use This Procedure
The standard Disabling Support Access steps prevent new sessions and—when you uninstall the Helm chart—remove the cluster roles and role bindings that support relies on. However, a support engagement may have left behind workloads that retain access to nodes even after the RBAC roles are gone. Removing all access means revoking RBAC and cleaning up any such workloads.
Step 1: Revoke RBAC Access
Follow both methods described in Disabling Support Access:
-
Disable support access via the CLI to prevent new or renewed sessions:
crusoe kubernetes clusters support-access disable <cluster-name> -
Uninstall the Helm chart to immediately remove the support cluster roles and role bindings:
helm uninstall crusoe-support-roles --namespace crusoe-system
Already-minted certificates remain valid until they expire, because Kubernetes does not support certificate revocation. Removing the cluster roles and role bindings (Step 1, item 2) ensures those credentials can no longer authorize any action.
Step 2: Remove Node-Shell and Similar Pods
During troubleshooting, support engineers may run helper pods—such as node-shell pods—that mount host paths or open a shell onto a node. These pods can provide node-level access independent of the RBAC roles you removed in Step 1, so they must be deleted explicitly.
Crusoe support roles are scoped to the following Crusoe-managed namespaces. Sweep each of them for leftover diagnostic pods:
crusoe-systemkube-systemnvidia-gpu-operatornvidia-network-operatorkube-amd-gpukube-amd-networkslinkyslurm
-
Check each Crusoe-managed namespace for any such pods. For example:
kubectl get pods --namespace crusoe-systemTo check all of the namespaces at once:
for ns in crusoe-system kube-system nvidia-gpu-operator nvidia-network-operator kube-amd-gpu kube-amd-network slinky slurm; doecho "== $ns =="kubectl get pods --namespace "$ns"doneLook for pods with names like
node-shell-*, debug/shell pods, or any pod you do not recognize as part of normal cluster operation. -
Delete any node-shell or similar diagnostic pods you find:
kubectl delete pod <pod-name> --namespace <namespace>
Only delete pods that you have confirmed are diagnostic or support-related. Deleting pods that are part of normal cluster operation may disrupt your workloads.
Step 3: Verify
Confirm that support access is fully disabled and no active sessions remain:
crusoe kubernetes clusters support-access get <cluster-name>
Confirm the Helm chart is no longer installed:
helm list --namespace crusoe-system
Confirm no node-shell or diagnostic pods remain in any of the Crusoe-managed namespaces:
for ns in crusoe-system kube-system nvidia-gpu-operator nvidia-network-operator kube-amd-gpu kube-amd-network slinky slurm; do
echo "== $ns =="
kubectl get pods --namespace "$ns"
done
Getting Help
If you have questions about fully revoking support access or identifying which pods are safe to remove, please contact support.