> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
> [log in to unmask]] On Behalf Of Stephen Jones
>
> Is it "documented" that the grid should have an automatic global banning
> mechanism?
>
> Everything else is just implementation details - you can do it with a list,
> or some central server or by bouncing an XML file off the surface of the
> moon and transferring it to the server by pony express.
>
> The question remains - are we resolved that the grid must have a mechanism
> for this?
Yes, we are. Linda posted the link to the policy document upthread,
but it's here:
https://documents.egi.eu/public/ShowDocument?docid=1475
The key bit is section 1.9:
"You must implement automated procedures to download the security
emergency suspension lists defined centrally by Security Operations
and should take appropriate actions based on these lists, to be
effective within the specified time period."
However, neither the policy nor the practice should require a site to have
or use a local ARGUS server. For most of us, I think an ARGUS server will
be a good choice - it'll be the mainstream option, it'll be easy to make
work, and ARGUS servers only need relatively modest little VMs and not much
effort. If someone's currently using an NFS shared gridmapdir, it's pretty
easy to switch to a shared ARGUS server instead. If someone's got two
systems (say a departmental cluster and a university shared cluster) that
currently would need two shared gridmapdirs (one each), they might need two
ARGUS servers, but that's OK, because they're small and simple.
If a site doesn't want to use ARGUS at all locally, that's still OK; there's
support for downloading the list of suspended DNs from the NGI ARGUS server
and just stuffing it into whatever local banning solution the site has.
There's some documentation and example script(s) for that here:
http://wiki.nikhef.nl/grid/Argus_Global_Banning_Setup_Overview#Site_runs_no_Argus
So, the policy requirement is that you must have a thing. The basic
recommendation if you don't have a strong preference to do otherwise, is to
just use the off the shelf thing, which is ARGUS. If you want to write your
own thing and plumb it into your CEs and glexec and whatnot, that's fine too.
As for services that don't do their authorisation decisions through a site
ARGUS (i.e. mostly the SEs), my current understanding is that they're each
likely to grow some version of the 'download the DN list' idea and use it
in their own way - that certainly seems to be the shape of the DPM solution.
And finally, on the "this doesn't happen much" point; I can think of several
occasions when it might have been nice to have this, but the DN in question
wasn't suspended because doing it at the moment it a right pain, and it's
slow. Possibly more to the point, reversing it is a pain, slow, and
unreliable, all of which makes it a less attractive option. With a
co-ordinated way to suspend (and un-suspend) a DN, there should be a lower
bar to doing so at all.
Ewan
|