On 12/03/2012 07:14 PM, Peter Solagna wrote:
> Dear Adrian,
> please, find some answers inline.
Hi and thanks for taking time for answering,
> On 3 December 2012 16:15, Adrian Sevcenco <[log in to unmask]
> <mailto:[log in to unmask]>> wrote:
>
> Well this is something to be discussed between WLCG and EGI.
>
>
> There is a WLCG representative in the EGI Security Policy Group, who
> defined the policy, we all want that the main user of EGI infrastructure
> is aware of the policies we produce.
ok.. If the feedback from VOs and especially from WLCG VOs was ok i have
nothing to say on this .. maybe i missed the mails when the VOs
communicated to their contributors the results of this discussions.
> More on the technical point i dont understand why this is something
> to be done OVERALL !! This should be done at VO level and accepted
> and signed at the moment of entry in VO (user) or at the moment of
> participation acceptance (site).
> To account personal information by parties which are NOT the VOs is
> insane (IMHO). This should be enabled at VO level and only at VO
> request.
>
>
> VO users must be aware of the policies currently affecting their usage
> of the EGI infrastructure, as expressed in the AUP:
> << Members and Managers of the VO agree to be bound by the Grid
> Acceptable Usage Rules, VO Security Policy and other relevant Grid
> Policies, and to use the Grid only in the furtherance of the stated goal
> of the VO. >>
ok
> The Grid Policy on the Handling of User-Level Job Accounting Data says:
> <<Each site is responsible for sending its accounting records on a
> regular basis, e.g. daily, with at least user DNs encrypted in
> transport, to a central data base defined by the Grid.>> and
> <<Access to a portal that allows the decoding of the anonymised name
> into a person’s DN is restricted to individuals in the VO appointed to
> be VO Resource Managers.>>
>
> That means that users are aware of the fact that the accounting data can
where is this meaning in the paragraph above? Unless is written
explicitly in their AUP the users dont know.
> be stored centrally including the User DN of their jobs, nevertheless
> the user level data is not going to be disclosed to entities external
> from the VO, if not specific members of EGI Operations and Security, but
> only for very specific use cases.
>
>
> Why sites must do anything if "we do not know who" ask as to do it?
>
> well the submitter is EGI Operations Officer so is not someone unknown..
>
>
> Yes, this requirement is coming from EGI Operations, the policies should
> be known to sites participating to the infrastructure.
>
> In the document refereed to in ticket
> (https://documents.egi.eu/__public/ShowDocument?docid=85
> <https://documents.egi.eu/public/ShowDocument?docid=85>) i see a
> problem at page 5 :
> "VO Resource Managers and the Grid Operations personnel who have
> access to the user-level accounting from more than one site."
>
> "1. For the VOs to understand and control how many and which
> individuals within the VO, group or role are using resources."
> 2. For VOs, Grid Management and Sites to report on anonymised and
> aggregated statistics to their funding bodies.
> 3. For Grid Operations during operational troubleshooting and debugging.
> 4. For Grid Security Operations in forensic analysis of security
> incidents. "
>
> Point 1. : is VO only related.
>
>
> VO use the accounting portal to access the data, how are VOs supposed to
> access accounting data if this information is not provided to the
> repository?
hmm, i might hit a technical misunderstanding of mine here:
doesn't the VO have the only jobs submitter machine (WMS) for the
respective VO? If so, the WMS can log directly the user DN and the
associated job information that can lead to more detailed accounting.
It is in my opinion that all this over-sized and over complex
information system of EMI(gLite) is not needed .. beside accounting info
that a vo can gather from a site through some simple means, a site
should not need to do such extensive information reporting.
>
> Point 2. : have no relation to user-level info
>
>
> Not user level, but information to aggregate accounting information in a
> meaningful way are in the user DN. This, as specified by the policy,
> does not mean that user level accounting data will be disclosed.
>
> Point 3. : i am not aware of specific user-level support
> (troubleshooting and debugging) outside the VO ...
>
>
> The point says that accounting data could be used for this purpose,
> which means that they could be used by a very restricted set of people
> for critical testing.
>
> Point 4. : this also should be done only at VO level. The VO should
> be able (if it choose to) to record the user-level jobs sent. OTOH
> the VO have also the submission mechanism so it has all the data
> from start .. so why should the site record the same data?
>
>
> What you mean that VO has the data from the start? Does, for example,
> the "gridifin" VO has the accounting tools to provide user level
> accounting details to the EGI security team, in case of incident
> originated by that VO?
> In case of a security incident, is very likely that the submission of
> jobs does not pass throught the usual VO submission frameworks, so it's
> likely that there are no accounting data available in the VOs accounting
> repositories, if any.
so, my above question about submission point is back again ... i had a
brief encounter with GRID security incident handling at Gridka 2012 and
it was in my opinion that most attacks wouldn't have been be possible if
servers had been secured. Last exercise was with an attack that was a
job lunched from an outside UI directly to my CREAM server .. i remember
that i was very surprised then about this but i forgot as i had other
things to do.
So .. is it possible to send a job to a site with some VO
credentials directly? well, that mean IMHO that EMI is deeply _broken_
from a security point of view!! a site should receive jobs ONLY from an
authenticated submission server of the VO and no other! (and the UI part
of job submission should connect only to this central(VO) submission
mechanism)
> Overall it is in my opinion that this is something to be done at VO
> level and ONLY at VO level (both legal and technical) ..
>
>
> Not all the VOs are able to set up an accounting infrastructure, neither
if the VO cannot have an accounting infrastructure, you cannot ask of
this from a contributing site .. you would but a big legal burden on
their back (think about a scenario when a user say : "ok,my jobs were
executed to you site. that is private information and i wanted deleted."
and we would have to say : "you know is true that we acquired your data
but we don't have it") it is about difference of legal entity between VO
and a contributing site.
> should a site configure several different accounting frameworks if they
> are supporting multiple VOs with different accounting mechanisms. For
> example I'm a VO Manager for the ops vo, and without this data I can't
> trace these information.
>
> The completeness of the accounting data is often crucial to make it
> meaningful and useful for VOs and NGIs. The EGI policies and technical
> solutions ensure that this data is not disclosed to entities not
> authorized to access them.
>
> EGI asks to sites part of the infrastructure to publish centrally the
> User DNs in order to provide a complete service to VOs and NGIs.
>
>
> Please, let me know if there are more questions.
Well, i am still not satisfied with this "centrally" and the submission
mechanism should be fast repaired. The thing is that we are a small
institute and we cannot afford any "potential" legal problems.
I will iterate the subject with my (senior) colleague from NIHAM and i
will see how it goes ... until then i will put ticket on hold.
Also, i am sure that with some good will, all this information and
reporting system can be made simpler, safer and flexible in its components.
Thank you for all your explanation!
Adrian
>
>
> Regards
> Peter
>
> --
> Peter Solagna
> EGI.eu - Operations Manager
> email: [log in to unmask] <mailto:[log in to unmask]>
> skype: peter.solagna.egi
--
----------------------------------------------
Adrian Sevcenco |
Institute of Space Sciences - ISS, Romania |
adrian.sevcenco at {cern.ch,spacescience.ro} |
----------------------------------------------
