diff options
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 317 |
1 files changed, 203 insertions, 114 deletions
@@ -1,118 +1,207 @@ # Moon -__Version 4.3__ +__Version 5.4__ This directory contains all the modules for running the Moon platform. -## Platform -### Setup -- [Docker installation](tools/moon_kubernetes/README.md) -- [kubeadm installation](tools/moon_kubernetes/README.md) -- [Moon deployment](tools/moon_kubernetes/README.md) -- [OpenStack deployment](tools/openstack/README.md) - -### Micro-service Architecture -The Moon platform is composed on the following components/containers: -- *consul*: a Consul configuration server -- *db*: a MySQL database server -- *keystone*: a Keystone authentication server -- [gui](moon_gui/README.md): a Moon web interface -- [manager](moon_manager/README.md): the Moon manager for the database -- [orchestrator](moon_orchestrator/README.md): the Moon component that manage pods in te K8S platform -- [wrapper](moon_wrapper/README.md): the Moon endpoint where OpenStack component connect to. - - -## Manipulation -### moon_gui -The web access of Moon is through the URL `http://$MOON_HOST:30002` with the login and password of Keystone. -The default login and password can be found here: `http://$MOON_HOST:30005/ui/#/dc1/kv/openstack/keystone/edit`. - -**WARNING: the password is in clear text, this is a known security issue.** - -### moon_manager -The REST access of Moon is through `http://$MOON_HOST:30001` - -**WARNING: By default, no login/password will be needed because of the configuration which is in DEV mode.** - -For more security, update `http://$MOON_HOST:30005/ui/#/dc1/kv/openstack/keystone/edit` by modifying the `check_token` argument to `yes` -Requests to Moon API must include a valid token taken from Keystone in the header of `X-Auth-Token`. - -Check if the Manager API is running with: -```bash -curl http://$MOON_HOST:30001 -curl http://$MOON_HOST:30001/pdp -curl http://$MOON_HOST:30001/policies -``` - -The Moon platform is fully installed and configured when you have no error with the `moon_get_keystone_projects`: -```bash -sudo pip install python_moonclient --upgrade -moon project list -``` - -### moon_wrapper -The moon_wrapper component is used to connect OpenStack to the Moon platform. -You need to load one wrapper before connecting OpenStack to Moon. -First of all, get the names of all available slaves: -```bash -moon slave list -``` -Select the slave you want to configure: -```bash -moon slave set <name_of_the_slave> -``` -If you don't put a name here, by default, the script will use `kubernetes-admin@kubernetes` -which is the master. - -If you need to unload the slave, use the following command: -```bash -moon slave delete <name_of_the_slave> -``` -If you don't put a name here, by default, the script will use `kubernetes-admin@kubernetes`. - -### inport/export of the moon database -Using the moon python client, it is possible to export and import the content of the moon database. The format of the file must be json. Examples of files that can be imported are found in the moon_manager package (rbac.json and mls.json) - -The relations between different elements of the json in made using their names. Therefore, the name acts, for now, as a unique identifier in the json files. Importing several times the same json file can lead to unexpected behavior. It is advised to import json file in an empty database. - -Two particular entries in the json description are used to specify the way of performing the import: - - "mandatory": it can be true or false. This field is only valid for policies description. The policy having this field set to true, will be automatically added to the other elements of the json file that have an empty "policy" field (subject data for instance) or that have a "policies" field which does not already contain the mandatory policy name (such as subjects). - - "override" : it can be true or false. This field is only valid for policies and models. If set to true and a policy/model with an identical name already exists in the database, it will be overwritten. - - -## Tests -- [Python Unit Test](tests/python_unit/README.md) -- [Functional Test](tests/functional/README.md) - - -## Annexe -### Authentication -If you configured the authentication in the Moon platform: -```bash -curl -i \ - -H "Content-Type: application/json" \ - -d ' -{ "auth": { - "identity": { - "methods": ["password"], - "password": { - "user": { - "name": "admin", - "domain": { "id": "default" }, - "password": "<set_your_password_here>" - } - } - }, - "scope": { - "project": { - "name": "admin", - "domain": { "id": "default" } - } - } - } -}' \ - "http://moon_hostname:30006/v3/auth/tokens" ; echo - -curl --header "X-Auth-Token: <token_retrieve_from_keystone>" http://moon_hostname:30001 -curl --header "X-Auth-Token: <token_retrieve_from_keystone>" http://moon_hostname:30001/pdp -curl --header "X-Auth-Token: <token_retrieve_from_keystone>" http://moon_hostname:30001/policies -``` +## What is Moon + +The Moon platform is a security policy engine with the following characteristics: + +* centralized (or not) + * Moon can centralize all authorization requests for multiple VIMs (Virtual Infrastructure Managers) at one time + * Moon can centralize all security policies for multiple VIMs + * with fully customizable security policies +* Moon can work on RBAC (Role based Access Control) policies or MLS (Multi Layer Security) policies + * Moon can also create and use a new custom policy +* with a user centric management + * The end user (administrator of the VIM) is able to generate his/her own policies and manage them + +The Moon platform can also be a security orchestrator which can: + +* dynamically assign and manage policies +* integrate OpenStack and OpenDaylight +* theorically integrate more systems (like VIMs, IoT, ...) + +If you want to install the platform see [here](moon_manager/README.md) + +## Software Architecture + +Moon platform is composed on several API servers written in Python. Those servers can be installed on a bare metal system or on Docker, Kubernetes, OpenStack, ... + +The communication between those servers is done by classic client/server connections (HTTP REST API) so the different components can be located on different and non homogenous systems. + +The Moon platform is build on a plugins architecture so it is easy to customize the platform. + +## Deployment Architecture + +Moon is based on "Control Plane" and "Data Plane". The "Control Plane" manages the security policies, The "Data Plane" applies those policies. + + + +Each project on a VIM will be connected to a specific PDP (Policy Decision Point) which is the main and the only entry point for this project. + +The Moon "Control Plane" and "Data Planes" can be theoretically located everywhere as shown in the figure below: + + + +A "Data plane" could be located: + +* in the same server as the "Control plane" +* in a totally different server +* in a virtual machine in an OpenStack VIM +* in a different server managing 2 different OpenStack + +## Data Models + +### Introduction + +The Moon data model is based on a ABAC policy model (Attribute Based Access Control) which allow us to modeling every security policies. + +When a connect like OpenStack need an authorization response, it sends to Moon a request with 3 elements (plus the project ID): + +* the subject ID (user who do the action) +* the object ID (object which is the destination of the action) +* the action ID (action done by the user on the object) + +For example, the "admin" (subject) wants to "start" (action) a specific virtual machine (object). + +In the Moon data model, those elements are called "perimeter" elements. + +To be able to write rules for authorization requests, the Moon data model uses 3 other elements, called "data". + +For example, the role "admin" (subject) can do the action "start" (action) on a specific virtual machine (object). + +The Moon data model objective is to 'map' perimeter elements with data elements given a specific data model. + + + + +### Examples + +#### OpenStack + +For example, the RBAC policy of OpenStack can be modeling with the following model: + +* a user (perimeter subject) is mapped to a specific role (data subject) +* an virtual machine (perimeter object) is mapped to a specific ID (data object) +* an action, like "start a virtual machine" (perimeter action) is mapped to a specific ID (data action) + +#### Multi Layer Security + +The confidential defense, secret defense, ... policy (which are security level) could be modeling with a MLS policy like this: + +* a user (perimeter subject) is linked to a specific security level (data subject) +* an virtual machine (perimeter object) is linked to a specific security level (data object) +* an action, like "start a virtual machine" (perimeter action) is linked to a specific ID (data action) + +#### A more complex example + +The Moon data model can be used to create more complex policies. For example, you need to set a different role for your users and you need also to tag them with a security level (high, medium and low). You also need to reduce the number of OpenStack commands to manage. At last, you need to reduce the number of managed objects and you want to tag each object with a security level. The model can be created with the following meta rule: + +* the user name is linked to a role and to a security level +* the object ID is linked to a security level +* the action name is linked to a type of action + +Here are some examples of data we can have in the perimeter items: + +* subject: user_1, user_2, ... +* object: vm_1, vm_2, all_vm, glance_image_1, network_id1, ... +* action: compute:create, image_list, network::list, ... + +Here are some examples of data we can have in the data items + +* subject, role: admin, user, readonly, ... +* subject, security level: high, low +* object, security level: high, low +* action, type of action: nova_read, nova_write, glance_read, glance_write, neutron_read, ... + +Linking perimeter with data is essential, in this example, we can have such assignments: + +* subject, role: user_1 → admin +* subject, security level: user_1 → high +* subject, role: user_2 → admin +* subject, security level: user_1 → low +* object, security level: vm_1 → high +* object, security level: vm_2 → low +* object, security level: all_vm → low +* object, security level: glance_image_1 → low +* action, type of action: compute:create → nova_write +* action, type of action: image_list → glance_read +* action, type of action: network::list → neutron_read + +At last, here are some examples of rules: + +* (admin, high), (high), (nova_read) +* (admin, high), (high), (nova_write) +* (admin, low), (high), (nova_read) +* (admin, low), (low), (nova_read) +* (admin, low), (low), (nova_write) +* ... + +## Components + +The Moon platform is composed on 3 components: + +* Manager +* Engine/Wrapper +* Engine/Pipeline + +The first one can be considered as the master and the latest ones as slaves. Each components is a micro-service and is independent from other components. + + + +As shown in the previous diagram, the Manager manages several wrappers which can themselves manage several pipelines. + +A more complete architecture applied for OpenStack can be this figure: + + + + +### Manager + +The manager is responsible of managing (read, write, delete) all data in the platform. It is connected to the main database (SQLite, MySQL, ...) and is the entry point for every requests concerning data inside the platform. + +### Engine/Wrapper + +The Wrapper is the entry point for the Manager to the slaves. + +The main objective of the wrapper is to route every requests from the Manager or from the outside connector (like OpenStack, OpenDaylight, ...) to the correct Pipeline. + +### Engine/Pipeline + +The Pipeline contains the effective authorization engine of the Moon platform, if needed, it can work on its own without the need to contact the Manager. A user/developer can only use the engine if he/she doesn't need the whole Moon framework. + +The Pipeline listen to requests from its dedicated wrapper or from outside connector, compute the result and send it back. + +### Open Sourced + +For the Open Source community, we released the following elements: + +* a security policy engine +* a driver for + * OpenStack + * OpenDaylight +* a hook in Oslo_Policy (to be able to connect to external PDP) +* a web GUI integrated in the official OpenStack dashboard: Horizon + +## Industrialization + +Since 2018, a big effort has been done to transform the platform for industrialization requirements: + +* Continuous integration with Gitlab-CI +* Project management with Jira +* Documentation management with Confluence + +## Team + +Actually the team is composed of: + +* Administrative project leader: Philippe Calvez & Sok-Yen Loui (Orange) +* Technical project leader: Christophe Le Toquin (Orange) +* Consultant : Thomas Duval (Orange) +* Developpers: + * Dimitri Darthenay (Orange) + * Gregory Quere (Orange) + +The Egypt team contract ended in march/april 2019. + |