User Tools

Site Tools


moon

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
moon [2015/05/06 13:31]
Ruan HE [Project description]
moon [2015/06/29 15:45]
Ruan HE [Committers and Contributors]
Line 1: Line 1:
-====== ​Moon OPNFV Security Management ​System ​======+======Security Management ​Module (Moon) ​======
  
-  * Proposed name for the project: Moon OPNFV Security Management ​System+  * Proposed name for the project: Moon Security Management ​Module
   * Proposed name for the repository: moon   * Proposed name for the repository: moon
   * Project Categories: Collaborative Development   * Project Categories: Collaborative Development
Line 16: Line 16:
  
   *   **Gap Analysis against OpenStack and SDN controllers**   *   **Gap Analysis against OpenStack and SDN controllers**
-    *   No centralized control: The OpenStack platform is divided into different services, like Nova for computing, Swift for storage, etc. Each service uses a configuration file with the corresponding security policy. For SND controllers,​ there exists another control system. For the OPNFV platform, it lacks a synchronization mechanism between these configuration and control systems in order to build a consistent and End-to-End protection system. ​+    *   No centralized control: The OpenStack platform is divided into different services, like Nova for computing, Swift for storage, etc. Each service uses a configuration file with the corresponding security policy. For SDN controllers,​ there exists another control system. For the OPNFV platform, it lacks a synchronization mechanism between these configuration and control systems in order to build a consistent and End-to-End protection system. ​
     *   No dynamic control: Currently, the authentication and authorization in OpenStack are achieved through the token mechanism, but there isn’t any token revocation mechanism. Once a user gets an authorization token, we will not have any control over the user. It lacks dynamic control at runtime in OpenStack and/or SDN controllers.  ​     *   No dynamic control: Currently, the authentication and authorization in OpenStack are achieved through the token mechanism, but there isn’t any token revocation mechanism. Once a user gets an authorization token, we will not have any control over the user. It lacks dynamic control at runtime in OpenStack and/or SDN controllers.  ​
-    *   No customization and flexibility:​ Each user of OpenStack and/​or ​SND controllers consumes their resource pool in their own manner, but it lacks customization for security management system integration. For example, in both OpenStack and OpenDaylight,​ user cannot define their own security policy for each VNF resource pool. +    *   No customization and flexibility:​ Each user of OpenStack and/​or ​SDN controllers consumes their resource pool in their own manner, but it lacks customization for security management system integration. For example, in both OpenStack and OpenDaylight,​ user cannot define their own security policy for each VNF resource pool. 
     *   No fine-granularity:​ Finally, the granularity of authorization in OpenStack and/or SDN controllers is not enough fine. Currently, it’s at the API-level. This means that we can authorize or deny a user from using an API like launch VM in OpenStack. But we need the granularity to be pushed to the resource-level,​ authorize or deny a user from using a specific resource through the API, e.g. allowing a user to launch a dedicated VNF VM.     *   No fine-granularity:​ Finally, the granularity of authorization in OpenStack and/or SDN controllers is not enough fine. Currently, it’s at the API-level. This means that we can authorize or deny a user from using an API like launch VM in OpenStack. But we need the granularity to be pushed to the resource-level,​ authorize or deny a user from using a specific resource through the API, e.g. allowing a user to launch a dedicated VNF VM.
 ===== Scope ===== ===== Scope =====
Line 48: Line 48:
  
  
-===== Committers and Contributors =====+===== Contributors =====
  
-  * Ruan HE (ruan.he@orange.com)  +  * Ruan HE (ruan.he_ _AT_ _orange.com)  
-  * Jamil CHAWKI (jamil.chawki@orange.com) +  * Jamil CHAWKI (jamil.chawki_ _AT_ _orange.com) 
-  * Loic LAGADEC (loic.lagadec@ensta-bretagne.fr) +  * Thomas DUVAL (thomas.duval_ _AT_ _orange.com) 
-  * Ashutosh ​Dutta (ad5939@att.com) +  * Loic LAGADEC (loic.lagadec_ _AT_ _ensta-bretagne.fr) 
-  * Marcel ​Winandy ​(marcel.winandy@huawei.com)+  * Ashutosh ​DUTTA (ad5939_ _AT_ _att.com) 
 +  * Marcel ​WINANDY ​(marcel.winandy_ _AT_ _huawei.com
 +  * Parviz Yegani (pyegani_ _AT_ _juniper.net)
   ​   ​
 +  ​
 +===== Committers =====
 +
 +  * Ruan HE (ruan.he_ _AT_ _orange.com) ​
 +  * asteroide (Linux Foundation ID) dt_linux@domtombox.net
 +  * WuKong (Linux Foundation ID) rebirthmonkey@gmail.com
 ===== Testing ===== ===== Testing =====
 Test suite for continuous integration will be developped. Test suite for continuous integration will be developped.
moon.txt · Last modified: 2015/06/30 16:59 by Ruan HE