...
Let's take the JASMIN cluster service as an example and compare our situation to theirs.First,
- JASMIN is a research facility, so does not have the same availability and integrity concerns as ECMWF.
...
- We can see that it's normal for users to have to go through a non-trivial process to access a cluster: generating an SSH keypair and uploading the public key to a website. This also implies ECMWF running such a service to manage key uploads.
...
- JASMIN "requires" users to secure their key with a passphrase, but there's no way this can be enforced. It's quite likely users don't bother, and the SSH keys are copied around freely and even lost and replaced, while remaining active for access to the facility.
...
- We know from other remote cluster providers that it's common to have to connect to a bastion host, and then hop onwards to the final working node. At ECMWF we much prefer users have a single hop straight to the cluster.
...
- Although our ActivID tokens work well, they are very expensive and the software (at ECMWF's end) is unreliable and troublesome to maintain. We would like to move away from ActivID in the post-BOND timeframe, so any access service should not be bound too tightly to it.
For these reasons, Teleport is a good choice, as it allows separation from ActivID, avoids a complex initiation for the user, avoids maintenance of SSH keys and their inherent security risks, avoids ECMWF running additional web services, and is single-hop client to server.
...