Security Management Module (Moon)
- Proposed name for the project: Moon Security Management Module
- Proposed name for the repository: moon
- Project Categories: Collaborative Development
This project proposes a security management system called Moon. NFV uses cloud computing technologies to virtualize the resources and automate the control.
The cloud infrastructure is able to provision a set of different cloud resources/services for VNFs (Virtualized Network Functions).
Management of isolation and protection of, and interaction between, these VNFs become a big challenge. In order to avoid losing control over the VNFs in the cloud, Moon aims at designing and developing a security management system for OPNFV.
We can create security managers to protect different layers of the NFV infrastructure, and choose various security project mechanisms “a la cart” to enforcement related security managers.
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.
- 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.
This project works on a security management system to monitor, control and manage VNFs based on the OpenStack infrastructure:
- 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.
- Project mechanisms: Moon proposes a dynamic solution to project each tenant. We will also propose different protection mechanisms to enrich the project catalog:
- Authorization: the first step is to enforce the authorization mechanism. All user operations are controlled and validated the authorization enforcement based on the security module.
- Logging: tractability and accountability will also be handled, operations of each VNF and interactions between VNFs are logged and can be retrieved for any purpose.
- Intrusion Detection System: runtime monitoring is another important issue as the telecommunication network asks for a highly availability.
- Networking enforcement: an important improvement is to enable network project by the security management system. Based on the defined policy, this system will configure Neutron, FWaaS, etc.
- 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
The first draft code of moon is available over:
- 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/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.
- Functional Architecture
- Ruan HE (ruan.he_ AT _orange.com)
- Jamil CHAWKI (jamil.chawki_ AT _orange.com)
- Thomas DUVAL (thomas.duval_ AT _orange.com)
- Alioune BA (alioune.ba_AT _orange.com)
- Maxime COMPASTIE (firstname.lastname@example.org)
- 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)
- ruan (Linux Foundation ID) ruan.he_ AT _orange.com
- asteroide (Linux Foundation ID) email@example.com
- WuKong (Linux Foundation ID) firstname.lastname@example.org
Test suite for continuous integration will be developped.
In the first release we will provide a light-weight security management with only authorization, log as protection mechanisms for all the created VNFs and the whole infrastructure.
Proposed Release Schedule:
Moon OPNFV Rel 2 timeframe: 2S 2015