hcgatewood
commented
2 years ago @sabithaatla thank you for the well-written proposal!
While this would be valuable work, at this point in time I don't know that it's a high-impact undertaking, as there's nothing concretely broken wrt the NMS/Orc8r security architecture (or, the parts of it that this proposal references, at least).
We are planning to have one of the Meta SWEs take on a much smaller-scoped version of this task in H1, though for the purpose of codebase simplification as the principal priority. Happy to chat more about this if desired, feel free to use this space or DM me in Slack!
sureshgorijavolu
kaderwavelabs
wendallkaters
Author : Sabitha Atla (sabitha.atla@wavelabs.ai)
Purpose
Intent of this proposal is to address security gaps in Magma NMS and Orc8r leveraging best practices in securing SaaS applications. Proposed solution will be backward compatibile with current version of NMS & orc8r. Proposed soluiton will use open source software framework similar to OPA (Open Policy Agent) for policy and database access layer. Existing RBAC shall be merged into the new UIRP Management service in Magma NMS, While Token middleware, ACL and Policy shall be integrated into the Magma Orc8r through new UIRP proxy service.
Security Gap Analysis on magma Orc8r and NMS
This section summarizes the security gaps in Magma Orc8r and NMS UI.
security gap in Magma NMS
Magma NMS has 3 user roles and does not enforce policy/attributes/advanced role-based access control. Existing NMS implements a very minimal form of RBAC (RoleBased Access Control) limited to the following hard coded user roles:
Super Admin -- READ/WRITE Access + Manage other users
User -- READ/WRITE Access
Read Only User -- READ access
Above roles are enforced only at the MagmaLte level which is a part of NMS. These user roles do not get forwarded to Magma Orc8ras seen in the figure 2.
Security gap in Magma Orchestrator
Magma Orc8r does application-level authentication for 3 identities namely Operator, Gateway and Network using Mutual TLS validation and Access control with accessd service based on the request type and validating the request type with the permissions defined in the stored ACLs (Access Control List) (READ/WRITE/UPDATE).The operator is identified based on the Common Name and SANs in TLS
Currently Orc8r is not exposed to the end user operating behind the application. However there have been some development in this regard with a recently merged PR [Citation Reference: Orc8r Token PR] that introduces a new Token middleware enabling Orc8r to identify the user behind the application using Authorization header. In Magma Orc8r, this limits tenant (organisation) user to have granular control over all the REST API endpoints and attributes of the Orc8r. Hence exposing resources (Magma Orc8r REST API Endpoints, network entity and attributes) to anyone with Superuser access in Magma NMS is a security concern for provisioning, configuration updates and deletion operation. As of now TLS/Certificates between Magma NMS and Orc8r is not helpful for Magma Orc8r to control Add/Update/Delete operation. Any rogue application can use TLS/certificate to add/update/delete Orc8r resources. It is a security threat.
Listed below are some of the unsecured Magma Orc8r resources.
Table 1: examples of Orc8r API Endpoints that do not have access control
However, NMS and Orc8r implement some level of RBAC and Application-level ACLs (Access Control List) respectively but the implementation is not established to support granular authorization of NMS users to Orc8r resources (REST APIs for now) Attribute level authorization is not present in Magma Orc8r or NMS. The risk is any user with Magma NMS superuser access but without knowledge of network entity in Magma Orc8r can provision, delete, modify network entities attributes within Magma Orc8r which is not desirable, and it can disrupt the network of the organization and enterprise tenants. It becomes major security threat by assigning superuser access to an enterprise tenant user to change/delete other network entities of some other fixed wireless network that is not allowed. Lack of policy-based access control on Magma Orc8r resources as well as attribute based access control on network entities like subscriber, access, tenants etc is a security gap, solved in this project. How these security gaps in Magma Orc8r and NMS is resolved is discussed in the next section.
Proposed Solution
Intent of the proposal is to add Policy Based Access Control (PBAC) to control access to the Magma Orc8r resources. All Magma Orc8r resources, routes, services used/accessed through REST API shall be stored in UIRP Database in NMS.
Changes on Magma NMS
The proposal on NMS intends to add extensive user roles, user groups, policy-based access control for Orc8r resources. Add attributes-based access control for the configuration attributes of network Functions of AGW. This proposal intends to add a new service, User Identity Roles Policy (UIRP). This would be an extended service to the existing RBAC (Role-Based Access Control) with full backward compatibility to previous versions of Magma NMS. Figure 4 shows the proposed Authorization flow (from 1 to 10) on how an NMS user gets authorized and has a secure connection for all requests from NMS to Magma Orchestrator. Authentication happens at the new UIRP service upon the user sending a request with valid credentials (Username and Password). If the credentials are valid, a JSON Web Token (JWT) of an open standard RFC 7519 [Citation Reference: RFC 7519] token along with the identity (containing user id, user role, token timestamp) of the user encrypted with private key at JWT Issuer, is sent as a response. Subsequently, all resource access requests made it is mandatory to carry a JWT token and an identity encrypted. Those access requests that have a JWT token will be decrypted and by using a public key and be validated. if successfully validated subsequently policy and permission set for the resources are looked upon based on the identity role provided. Resource access requests that do not carry a valid JWT token or don't qualify the authorization criteria are rejected. All transactions will be logged in to an audit log. An audit log is used to provide documentary evidence of the sequence of activities that have affected at any time a specific operation, procedure, event, or device accesed.
Functional Component
Identities: this module allows Magma NMS superuser to perform CRUD operation on User, Roles, Groups, Organization (tenant). There will be more roles like ProvisionRole (for ADD operation), ConfigRole(Config other than network entities), NetworkConfig(only network entities config), RestrictViewRole(for restricted GET operation). New organizations (tenants) and their users, user groups shall be created, authenticated and then authorized to perform various actions based on his roles and policies assigned.
User & Credentials: An entity that you create represents the person or service who uses the UIRP user to interact with Magma NMS. Typically, its Username and Password.
Group: A user group is a collection of UIRP users managed as a unit. An UIRP groups is authorized to perform same actions/operations.
Roles: in that it is an identity with permission policies that determine what the identity can and cannot do in magma NMS and Orchestrator. However, a role does not have any credentials (password or access keys) associated with it. Instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.
OPA Policy Service: OPA [citation reference Open Policy Agent] provides a high-level declarative language that lets you specify policy as code and simple APIs to offload policy decision-making, in our case OPA supplies the policy upon request to access any Magma NMS resource or Magma Orc8r resource from the UIRP service.
JWT Issuer: It is part of UIRP service that deals with generating JWT token which is digitally signed using JSON Web Signature (JWS) and encrypted along with identity of user using provided private key stored within JWT Issuer
UIRP DB Service: Middleware for UIRP services, which takes care of interactions with the DB and handles all request coming from OPA Policy Services and UIRP DB
UIRP DB: A MySQL Database holds the actual data for user, roles, policy, groups, resources, organizations, permissions etc.
Orchestrator & Permissions and Policies: Carries out checks for each request provided by user against policies and permissions from UIRP through a middleware gateway to perform any action
Security features proposed in Magma NMS is explained below:
Authentication Authorization Administration
A new user security model for AAA is being implemented for the digital identity and access management in Magma NMS to manage access to assets and maintain system security.
Authentication is based on the idea that each individual user will have unique information When UIRP is implemented, When a user successfully logs in using their credentials, an JWT Token along with Encrypted Identity is returned, this proposal plans to fortify authentication using UIRP capability.
Authorization
Once a user is successfully logged in, a request to access routes, services, or resources (e.g., APIs) on behalf of that user. To do so, in every request, JWT token is validated and user identity is checked so the amount of information and the amount of services the user access depend on the user's authorization level (Roles, Policies, Attributes)
Administration
A part of Administration is controlling all CRUD operations access on resources, through policies, user roles, attributes. policies and access can be configured, or created new to any users, roles, user group for these resources
Role based access control
A service-based network management system like Magma NMS must have multiple roles for different job functions like Restricted View Role (Read-Only role), View All Role(user role), Config Role for Add/Provision anything except network entities in Magma Orc8r, Network Config Role for network entities in Magma Orc8r, Admin Role for delete resources/entities and administration. A Superuser role in Magma NMS will continue to be there to implement these advance RBAC to identity (users, groups of users, or roles). This can be achieved through UIRP UI. Since this is a extension of existing RBAC it is fully backward compablity.
Policy based access control
It supports environmental and contextual controls, so policies can be set to grant access to resources at certain times and from certain locations and even evaluate relationships between identities and resources. OPA (Open Policy Agent) module handles the decision making of granting a permission upon a user identity request to access a resource
Attribute based access control
This security mechanism defines permissions based on attributes of the different resources available for access and actions that can be performed on it by an identity. A controlled flow is maintained at Magma NMS and Orchestrator to have a lookback at the UIRP for the decision on accessing it each time before an action is going to be performed at a resource.
Database component
OPA DB: (open policy agent) can needs to hold multiple tables hold different data such as user-policy, policy schema, roles, user-roles adaptation, events, logs, stored procedures triggers for policy decision making
OPA will also need for audit and logs on the same database
Needs store procedure for advanced / complex queries
UIRP DB: Stores the UIRP Settings and configurations, private keys for JWT Issuer.
changes on Magma Orc8r
There are two new Magma Orc8r components that are a part of this proposal, namely
A service called accessd inside Orc8r will be extended to support these new components meanwhile keeping the current ACLs (Access Control List) intact. On top of ACLs for northbound REST APIs, this extension will bring policy based access control (PBAC) as well as attribute based access control (ABAC) for authorizing Orc8r Resources (REST endpoints, GRPC calls). UIRP proxy services will bring the policies defined in UIRP (which is a proposed NMS component. Refer section 3.1) inside Magma Orc8r to authorize Magma Orc8r resources.
Functional Components
A brief breakdown of new functional components of Magma Orc8r is provided below:
UIRP Proxy is a proposed Go service that acts as an interface between existing Accessd service and the policies defined for Orc8r resources using UIRP inside NMS. It will enforce ABAC and PBAC policies defined in NMS UIRP to authorize Orc8r resources. UIRP proxy can be configured using northbound REST API calls from NMS. New swagger handlers will be needed inside Obsidian to facilitate the configuration of UIRP proxy.
PBAC and ABAC Services will enforce ABAC and PBAC at resource level with help of middlewares inside Magma Orc8r.
AUTHENTICATION AUTHORIZATION ADMINISTRATION (AAA)
User identity details inside Magma Orc8r will be managed by new AAA Service. This service will also fetch Roles, Policy, groups, permission defined in Magma NMS OPA or UIRP DB through UIRP proxy in Magma Orc8r UIRP proxy will enforce the policies in place with help of extensions to accessd service in Magma orc8r.
AAA User Interface
Magma Orc8r Security Administration will be done through new AAA UI to manage User Roles, Policy rules for API endpoints, attributes. It will also be used to manage ACLs (Access Control List) inside Magma Orc8r.
ROLE BASED ACCESS CONTROL (RBAC)
RBAC policies will be defined through Magma Orc8rUI and enforced by accessd service with policies stored in replicated database local to orc8r. These policies can be configured using Orc8r AAA UI.
POLICY BASED ACCESS CONTROL (PBAC)
PBAC policies will be defined through Magma Orc8r UI and enforced by accessd service with policies stored in replicated database local to orc8r. These policies can be configured using Orc8r AAA UI.
ATTRIBUTE BASED ACCESS CONTROL (ABAC)
ABAC will be implemented for servicers to protect attributes from unauthorized access. Same can be administered from Orc8r AAA UI.
Delivery Approch
Features will be delivered in 8 milestones. Each milestone will have the following 5 process gates;
Design
Development & Unit Testing
code review
Integration testing
Resolve integration issues and regression issues
Roadmap
MS/Roadmap : Development effort (Design, Code, UT) against each milestone in person days is captured below:
References