...
Security Context
The context of this service is that remote users, who we do not know very much about (e.g. researcher in a university who is sponsored by a Member State national weather service), connect to our HPC cluster on which we also run mission-critical operational forecasting.
As these aspects are unavoidable, measures need to be in place to sufficiently secure the access to our HPC facility. 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 does, where products are used in mission critical services around the world.
Second, if we compare our enrollment process to that of JASMIN, we can see that it's normal for users to have to go through a non-trivial process around setup to access a cluster. In the case of JASMIN, a user must create an SSH keypair and upload the public key to a web form to allow access.
JASMIN "requires" users to secure their SSH key with a passphrase, but there is no way this can be enforced. It's quite likely that most users don't bother, and the SSH keys are copied around freely and perhaps even lost and replaced, while still remaining active for access to the facility.
Finally, although our ActivID tokens work well, they are extremely 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.
Understanding ecAccess
A user outside of ECMWF wishes to ssh to one of the Centre's clusters, batch farms, or workstations. This can be done by running:
...