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/03/17 14:52]
jamil chawki
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 13: Line 13:
 A security management system integrates mechanisms of different security aspects. This project will firstly propose security manager that specifies users’ security requirements. ​ A security management system integrates mechanisms of different security aspects. This project will firstly propose security manager that specifies users’ security requirements. ​
 It will also enforce the security managers through various mechanisms like authorization for access control, firewall for networking, isolation for storage, logging for tractability,​ etc.  ​ It will also enforce the security managers through various mechanisms like authorization for access control, firewall for networking, isolation for storage, logging for tractability,​ etc.  ​
-{{ :​moon_nfv_architecture.png |}}+{{ :​moon_nfv_architecture.png?600 |}} 
 + 
 +  *   **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 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 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.
 ===== Scope ===== ===== Scope =====
  
Line 20: Line 26:
   * **Architecture**:​ The security management system can be considered as a management layer over the NFV/​OpenStack infrastructure. Users can dynamically create security modules and assign these modules to protect different VNF instances which are regrouped into tenants.   * **Architecture**:​ The security management system can be considered as a management layer over the NFV/​OpenStack infrastructure. Users can dynamically create security modules and assign these modules to protect different VNF instances which are regrouped into tenants.
  
-{{ :​moon_architecture.png |}}+{{ :​moon_architecture.png?600 |}}
    
   * **Project mechanisms**:​ Moon proposes a dynamic solution to project each tenant. We will also propose different protection mechanisms to enrich the project catalog:   * **Project mechanisms**:​ Moon proposes a dynamic solution to project each tenant. We will also propose different protection mechanisms to enrich the project catalog:
Line 29: Line 35:
      * Storage enforcement:​ storage protection being another important aspect, access to storage blocks or files will be controlled by Moon.       * Storage enforcement:​ storage protection being another important aspect, access to storage blocks or files will be controlled by Moon. 
      * Other protections mechanism can also be completed to this security management system      * Other protections mechanism can also be completed to this security management system
 +The first draft code of moon is available over:
 +[[https://​github.com/​rebirthmonkey/​moon|Moon Github]]
  
   * **Relations with other ongoing projects**   * **Relations with other ongoing projects**
-  ​*    Moon vs. OpenStack/​Keystone:​ Moon is based on Keystone, the next release of Moon will be built as a new API (backend service) for Keystone. In the near future, we also want to upstream Moon to Keystone as its authorization solution.  +    ​*    Moon vs. OpenStack/​Keystone:​ Moon is based on Keystone, the next release of Moon will be built as a new API (backend service) for Keystone. In the near future, we also want to upstream Moon to Keystone as its authorization solution.  
-  *   Moon vs. OpenStack/​Congress,​ OPNFV/​Copper:​ As a security management system, Moon uses security policies and enforces them through various protection mechanisms. However, Moon doesn’t create by itself a new policy engine. It is designed to support different policies engines. Currently, a project in Moon is ongoing to aliment Congress as one of Moon’s policy engines. So, Moon can also support OPNFV/​Copper policy engine in the future.+    *   Moon vs. OpenStack/​Congress,​ OPNFV/​Copper:​ As a security management system, Moon uses security policies and enforces them through various protection mechanisms. However, Moon doesn’t create by itself a new policy engine. It is designed to support different policies engines. Currently, a project in Moon is ongoing to aliment Congress as one of Moon’s policy engines. So, Moon can also support OPNFV/​Copper policy engine in the future
 +    *   Moon and European H2020 Project SuperCloud: The H2020 project [[http://​www.supercloud-project.eu/​|SUPERCLOUD ]] proposes new security and dependability management paradigms for multi-cloud infrastructures. It will notably provide a set of open source security enforcement mechanisms to protect the cloud infrastructure. These security mechanisms will be integrated with Moon to extend the protection scope to intrusion detection, usage supervision,​ or data protection.
  
 ===== Documentation ===== ===== Documentation =====
Line 39: Line 48:
  
  
-===== Committers and Contributors ===== +===== Contributors =====
- +
-  * Ruan HE (ruan.he@orange.com)  +
-  * Jamil CHAWKI (jamil.chawki@orange.com) +
-  * Loic LAGADEC (loic.lagadec@ensta-bretagne.fr)+
  
 +  * Ruan HE (ruan.he_ _AT_ _orange.com) ​
 +  * Jamil CHAWKI (jamil.chawki_ _AT_ _orange.com)
 +  * Thomas DUVAL (thomas.duval_ _AT_ _orange.com)
 +  * Loic LAGADEC (loic.lagadec_ _AT_ _ensta-bretagne.fr)
 +  * 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