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.
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.
By default, OSM starts with the following credentials:
- User: admin
- Project assigned to user: admin
- Role assigned to user: system-admin (system-wide privileges)
The configuration can be extended to cover more users, projects and role combinations, following the next sections.
## User management
TODO: Page in elaboration.
Users can be managed through the UI, by selecting Admin --> Users on the menu to the left, or using the OSM CLI:
```bash
osm-user-create creates a new user
osm-user-delete deletes a user
osm-user-list list all users
osm-user-show shows the details of a user
osm-user-update updates user information
```
Most of the commands are intuitive, but options can be checked by using '--help'. For example:
```bash
osm user-update --help
Usage: osm user-update [OPTIONS] USERNAME
Update a user information
USERNAME: name of the user
PASSWORD: new password
SET_USERNAME: new username
SET_PROJECT: creating mappings for project/role(s)
REMOVE_PROJECT: deleting mappings for project/role(s)
ADD_PROJECT_ROLE: adding mappings for project/role(s)
REMOVE_PROJECT_ROLE: removing mappings for project/role(s)
Options:
--password TEXT user password
--set-username TEXT change username
--set-project TEXT create/replace the project,role(s) mapping for this project: 'project,role1,role2,...'
--remove-project TEXT removes project from user: 'project'
--add-project-role TEXT adds project,role(s) mapping: 'project,role1,role2,...'
--remove-project-role TEXT removes project,role(s) mapping: 'project,role1,role2,...'
-h, --help Show this message and exit.
```
## Project management
TODO: Page in elaboration.
Projects can be managed through the UI, by selecting Admin --> Projects on the menu to the left, or using the OSM CLI:
```bash
osm-project-create creates a new project
osm-project-delete deletes a project
osm-project-list list all projects
osm-project-show shows the details of a project
osm-project-update updates a project (only the name can be updated)
```
Most of the commands are intuitive, but options can be checked by using '--help'. For example:
```bash
osm project-update --help
Usage: osm project-update [OPTIONS] PROJECT
Update a project name
:param ctx: :param project: id or name of the project to modify :param name: new name for the project :return:
Options:
--name TEXT new name for the project
-h, --help Show this message and exit.
```
## VIM management
TODO: Page in elaboration.
@@ -24,12 +95,58 @@ Some planned contents:
## Physical Deployment Units
TODO: Page in elaboration.
OSM can handle Physical Network Functions through managing the lifecycle, in particular Day-1/2 configurations, for the Physical Deployments Units (PDUs) that are part of a given PNF.
```text
Some planned contents:
- Description of what is a PDU in OSM
- How to register attached PDUs
Some relevant concepts are:
- PNF: Physical network function. It refers to a HW box that provides a networking function. For example: Routers, firewalls and load balancers.
- PDU: Physical deployment unit. It refers to the instance of the PNF that will be managed.
- HNF: Hybrid network function: Network function composed of both physical and virtual elements.
In OSM, there are no fundamental differences between modelling a VNF, a PNF or a Hybrid Network Function (HNF). In those cases where we want to define NS packages consisting of PNF packages or HNF packages, OSM needs to be instructed about the available PDUs.
Before including a PDU as part of a HNF Descriptor file, which would be similar to a VNFD, the PDU needs to be register.
A PDU can be registered through the UI (Instances --> PDU Instances), for example:
It can also be created through a YAML file which looks like this:
Then, using the OSM CLI, the yaml file is used to register the PDU.
```bash
osm pdu-create --descriptor_file PDU_router.yaml
```
Finally, the PDU is included in the descriptor as it was any VDU (with the applicable parameters), and Day1/2 configurations can be applied to it. For example, a PDU could be modeled like this:
