Aerospace Industry Community Requirements

This page briefly lists the requirements collected and described in the floowing document

https://edms.cern.ch/file/969962/1.0/ETICS-DSA2.2-969962-New_Infrastructures_Evaluation_Plan-v1.0.pdf

R1. Collaborative use of development environment

Solution: Is already available.

Status: Implemented

R2. Security in interaction between the ETICS client and ETICS server;

Solution: Is in place via x509 certificate.

Status: Implemented

R3. Protection to outside world

  • only authenticated users can access to the projects

Remarks: at the moment all project information registered into the ETICS system are available to all the ETICS users and others by the Guest Role. This means for example that no filter is applied to project information.

Solution: Some changes have to be applied on the Web Service side.

Status: a global Access control has been implemented for the VEGA system. See: https://twiki.cern.ch/twiki/bin/view/ETICS/SA1Privacy for further references. So Status: partially solved.

R4. Legally aspects

  • license restrictions

Remarks: management of multiple contractors sharing a common development environment is needed.

Status: Open

R5. Code protection

Remarks: read protection on Project, Subsystem and Component level is needed
  • It is not feasible to have the code globally accessible for all registered users for reading
  • Only authorized users shall be able to access projects, subsystems, components and project resources

Solution: No Role: no access at all. Roles are more detailled in R6.

Status: Open

R6. Flexibility in composing of groups

Remarks: more roles in addition to the existing Authorisation Service are needed to temporary add or disclosure groups during project cycle

Examples:

  • Debarred, outlocked, excluded
  • Guest shall allow read access

Solution: This requirement can be fulfil simply. At the moment the role Guest enables all the ETICS users to access project information. This can be easily avoided. Remark: The Guest role has been changed (See R3). No changes for the inter project access. So I assume: apparently not so easy.

Status: Open

R7. Control and transparency of development, maintenance and deployment processes

Remarks: None

Solution: is already in place.

Status: Implemented

R8. Attachment of private repositories and worker nodes

Remarks: Most potential customers pointed out the necessity that no external staff, even the administrators of the ETICS system shall be able to access their private code, due to IPR restrictions. This shall not be only a contractual agreement, but should also be a technical restriction.

Solution: This requirement can only be fulfilled by attaching private repositories and worker nodes at the customers location. The ETICS system must be extended to allow the attachments of private resources (Worker nodes and Repositories).

Status: Open

Summary R1 - R8

For requirements R3, R4, R5, R6 and R8 technical changes in the current ETICS systems are needed. In particular the following modifications are suggested:
  • to reduce permissions to the role Guest;
  • to publish filtered information;
  • to define a new web service able to publish only information to which users are authorized to access;
  • to define groups of users to easily add or disclosure groups during project cycle;
  • to allow or extend the ability to attach private resources.

R9; Firewall Restrictions

Network accessibility (proxy, firewall policies, etc.) Current Firewall Restrictions at VEGA corporate Network, Status info:

! No opening of dynamical range of ports allowed from DMZ to Integration Network. 20 Ports for each WN are a minimum. ==> this disallows the usage of condor master + submitter at DMZ and condor worker at the integration NW (behind the Firewall).

! No Webservers in Corporate Network allowed which are accessible from internet. ! No Webservers in Integration Network allowed which are accessible from internet.

==> this disallows move of ETICS behind the firewall and to make it accessible via https over ssh port tunneling from DMZ to the Integration Network. This solution would probably be technical possible, but not allowed from security points of view.

Current temporary solution which is implemented: WN in the DMZ ==> no firewall problem. Sufficient for demos, but not a final integration for a production system.

Long term solution:

Condor web services interface with defined number of open ports (https)? This could be probably established when decision is taken that VEGA uses ETICS as an official development tool.

GCB ???

Question: Are there any better (and more elegant) configuration alternatives which I might have overseen up to now?

Figure in attachment shows our actual setup: The etics server platform also hosts the condor master and submitter as well as the ETICS DB. The red point marks the problem.

Support, "ownership" of ETICS after Feb'2010 -- ValerioVenturi - 18 Dec 2008 migrated from SA23Main

Topic attachments
I Attachment History Action Size Date Who Comment
PowerPointppt ETICS_Firewall_IssueVEGA.ppt r1 manage 55.5 K 2009-10-15 - 09:30 UmWilm Firewall Restrictions
Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2010-01-27 - UmWilm
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    ETICS All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback