From 6d6f98a1d8172705edb3a46ace5762eedf14355a Mon Sep 17 00:00:00 2001 From: tierno Date: Fri, 24 Jul 2020 12:14:32 +0200 Subject: [PATCH] adding role description and quotas for osm_platform_configuration Signed-off-by: tierno --- 06-osm-platform-configuration.md | 57 ++++++++++++++++++++++++++++---- 1 file changed, 50 insertions(+), 7 deletions(-) diff --git a/06-osm-platform-configuration.md b/06-osm-platform-configuration.md index 713f003..9650f2c 100644 --- a/06-osm-platform-configuration.md +++ b/06-osm-platform-configuration.md @@ -5,19 +5,23 @@ Role-Based Access Control (RBAC) is available in OSM to bring different users and projects a controlled access to resources. Authorization is granted if a user has the necessary role to perform an action. For achieving this, two backends are available: -- Internal (default): handles identity and assignment resources locally by NBI. -- Keystone: external component to handle identity and assignment resources, together with out-of-the-box integrations (i.e. LDAP) and more advanced use RBAC cases. +- Internal: handles identity and assignment resources locally by NBI. +- Keystone (default): external component to handle identity and assignment resources, together with out-of-the-box integrations (i.e. LDAP) and more advanced use RBAC cases. ![OSM RBAC Options](assets/800px-OSM_rbac.png) Similar to other platforms like OpenStack, in OSM there are default policies (that can be modified) that apply to a combination of user-project-role. -That means that, in order to obtain privileges to do something in OSM, you should have a user, belonging to a project, with a specific role over the project. +That means that, in order to obtain privileges to do something in OSM, you should have a user, belonging to a project, with a specific role or roles over the project. -By default, OSM starts with the following credentials: +By default, OSM starts with the following users, projects and roles pre-created: -- User: admin -- Project assigned to user: admin -- Role assigned to user: system-admin (system-wide privileges) +- Users: `admin`, assigned to project `admin` with role `system_admin` (system-wide privileges). +- Projects: `admin`. +- Roles: + - `system_admin`: allows all operations. This role cannot be deleted. + - `account_manager`: allows administrative operations, as management of users, projects and roles; but not onboarding packages or instantiate. + - `project_admin`: allows all operations inside the belonging project, but not outside the scope of the projects, neither administrative operations. + - `project_user`: allows package onboarding and instantiation inside the belonging project, but not creation of VIMs, WIMs, etc. The configuration can be extended to cover more users, projects and role combinations, following the next sections. @@ -83,9 +87,48 @@ Usage: osm project-update [OPTIONS] PROJECT Options: --name TEXT new name for the project + --quotas TEXT change quotas. Can be used several times: 'quota1=number|empty[,quota2=...]' (use empty to reset quota to default + -h, --help Show this message and exit. ``` +### Quotas + +Projects can contain quotas to limit the number of elements that can be added in this project. By default there is a quota of 500 for each element type, but this can be changed with the `--quotas` option. +The keywords used for quotas are: `vnfds`, `nsds`, `slice_templates`, `pduds`, `ns_instances`, `slice_instances`, `vim_accounts`, `wim_accounts`, `sdn_controllers`, `k8sclusters`, `k8srepos`, `osmrepos`, `ns_subscriptions` + +## Role management + +Roles can be managed through the UI, by selecting Admin --> Roles on the menu to the left, or using the OSM CLI: + +```bash + role-create creates a new role + role-delete deletes a role + role-list list all roles + role-show show specific role + role-update updates a role +``` + +Most of the commands are intuitive, but options can be checked by using `--help`. Roles contains permissions with a boolean value of `True` (granted) or `False` (denied). If missing it applies the parent permission. + +Global administrative permissions are: + +- `default`: applies by default in case permission is not set. +- `force`: allows to force operations (e.g. deleting with force without checking dependencies). +- `admin`: allows act on behalve of other project different than the one used for logging. It also allows the CLI option `--all-projects` for the commands. +- `public`: allows using public packages, and setting an added package as public. + +The rest permissions are organized in a hierarchical tree with a colon separated list. The the last item in the list is the http method (post, put, patch, delete, get). For example: + +```yaml +nsds: True # grant all operations over nspkgs +nsds:get: True # grant listing nspkgs +nsds:id:get: True # grant showing a concrete nspkg +nsds:id:delete: False # deny deleting a nspkg +``` + +See this [file](https://osm.etsi.org/gitweb/?p=osm/NBI.git;a=blob;f=osm_nbi/resources_to_operations.yml) for a descriptive list of permissions + ## User authentication with external LDAP server When using the Keystone back-end, an external LDAP server may be used for user authentication, whereas the assignment information (RBAC roles/projects) is always stored in the local mysql database. In this working model, two user and project domains are used. -- GitLab