 |
 |
On 5 December 2014 at 19:25, Andrew McNab <[log in to unmask]> wrote: > On 5 Dec 2014, at 16:30, Sam Skipsey <[log in to unmask]> wrote: >> As requested in the meeting, here's a presentation-format discussion >> of non-Grid-Proxy mechanisms as an idea. (I think Andy and I were >> talking across purposes for some of our disagreement, so hopefully >> this clarifies the position.) > > The central problem is how a third party service like a storage server can trust that a particular job is acting on behalf of a user. This always requires either giving a secret to the job (e.g. a password, or a proxy in a sandbox) or doing something equivalent to proper proxy delegation in which the private keys never go over the network. > > As I said during the meeting, the problem with your model is that the signature of the job becomes a replayable secret like a password. > No, it doesn't (or rather, "replayable secrets" are pretty much a solved problem - you just embed a sequence number into the secret to prevent it being replayed, and then you just have to save a sequence number, which is less effort than your strawman below). > This means that I have to keep the signature and job a secret, otherwise people can do malicious versions of the transaction(s) allowed by my signature using their own clients. But the job must reveal this secret signature to the services it wants to talk to. The strength of proxies is that there is a secret which never needs to be disclosed or go over the network, and a signature component (the proxy certificate chain) which can safely be disclosed to anyone. > Note that I do address this later in the slides - and, in any case, you can only do "malicious" versions of the writes that you explicitly allow. [A "malicious" read, for WLCG at least, is not anywhere near as much of a problem.] I also strongly question your assertion that proxies are based on a "secret which never needs to be disclosed" - it's very clearly the case that in almost all implementations of proxy delegation systems, the proxy itself is sent over the wire to authorise everything. This is much worse than sending very limited approval. (And you have to trust the CEs in both cases anyway.) > Furthermore, I don’t really buy your answer to minimise the scope of replay attacks on slide 19 that asserts “well written code will always know which files it will need before execution, and which files it expects to produce when complete. We can therefore map these to a series of Transactions: Source -> Destination”. Pilot jobs are so successful because they allow late binding, and moving to event servers pushes that binding even later. We want jobs to have more flexibility not less about what they do when they land on a worker node in response to the available cores, memory, network conditions, and what has already been processed. > Certainly, I accept that there are people who want that. You will have to accept that I disagree as to if this is actually necessary - and certainly as to if it is necessary to use a pilot job mechanism to do it. [Pilot jobs are, removing the ownership issues whereby each experiment gets the ability to feel that they control their own submission architecture, essentially just a pull mechanism for workloads. There's nothing in the presentation that *requires* the job distribution model to be pull... and there's not really any proofs been demonstrated that "VO-specific" pilot mechanisms are globally good (as opposed to locally good for each VO). In addition, the use of throwaway containers for jobs handles most of the VO-specific environment setup that pilots do for their VOs - it would be fairly trivial to map this onto the current enthusiasm for "Experiment Specific VMs", but with container environments giving all the advantages of transparency and efficiency that VMs lack. As regards late binding, I see this as a trade off between security (defined workflows) and convenience (the ability to change what the slot I own does on the fly). I am not convinced that the convenience outweighs the security advantages in this case.] Sam > Cheers > > Andrew > > -- > Dr Andrew McNab, High Energy Physics, > University of Manchester, UK, M13 9PL. > Skype and Google Talk: andrew.mcnab.uk > Web: www.hep.manchester.ac.uk/u/mcnab