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.
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.
