This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
moon [2015/05/06 13:05] Ruan HE [Scope] |
moon [2015/05/26 08:53] Ruan HE [Committers and Contributors] |
||
---|---|---|---|
Line 14: | Line 14: | ||
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?600 |}} | {{ :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 44: | Line 50: | ||
===== Committers and Contributors ===== | ===== Committers and 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) |
+ | * Ashutosh DUTTA (ad5939_ _AT_ _att.com) | ||
+ | * Marcel WINANDY (marcel.winandy_ _AT_ _huawei.com) | ||
+ | * Parviz Yegani (pyegani_ _AT_ _juniper.net) | ||
| | ||
===== Testing ===== | ===== Testing ===== |