This page is mostly a wishful thinking. It does not reflect the current state of ONAP security. It's rather where we would like to be.

ONAP introduction

Abstract ONAP Architecture

Abstractly, ONAP is an independent software system that exposes Northbound interfaces for User, Admin and OSS/BSS systems and Southbound interfaces for xNFs (VNF, CNF, PNF). ONAP uses interfaces provided by NFVi and xNFs.

ONAP deployed on kubernetes

In the early releases, ONAP was deployed on VMs. ONAP is now virtualized using containers orchestrated by Kubernetes (K8S). ONAP uses interfaces exposed by K8S.

ONAP deployed on kubernetes with external databases

Most ONAP components require a data persistence layer, implemented using a databases. In early releases, most ONAP components had their own databases. As the platform has matured, components have moved to shared databases. A logical progression to make the platform simpler to deploy in an operator environment, is to create interfaces that allow an operator to configure ONAP to use external DB engines in the operators environment.

ONAP deployed on K8S with external databases and external identity and access management (IAM)

ONAP includes AAF, an identity management system that supports authentication, authorization, identity lifecycle management (ILM), and certificate management, including a certificate authority (CA) designed to support a lab deployment. It is likely that an operator will want to integrate ONAP with their IAM system, thus ONAP needs to support standard IAM protocols.

• TO DO: specify the protocols

  • LDAP

  • ...

ONAP deployed on kubernetes with external databases and external IAM and external CA

Most of the operators probably already have Certificate Authority server running in their network and a requirement that all services should present a valid certificate signed by this CA. This means that ONAP should provide the ability to integrate with external CA instead of shipping own one.

Defining system boundaries

Provided interfaces

1. Admin/User/OSS/BSS interfaces are REST.

2. xNF southbound interfaces are VES events (protocol depends on the collector used)

Used interfaces

1. Kubernetes interface is REST. Exact supported version of kubernetes has to be specified by every ONAP release

2. Database interface depends on DB type but only encrypted communication should be used

3. xNF interface depends on particular xNF but all xNFs should support secure protocols for communication

4. NFVI interface is REST (usually OpenStack or Kubernetes)

5. IAM interface is Open ID Connect

   1. if operator already has OIDC compatible solution ONAP should just use it

   2. if operator has Identity Provider (LDAP/Kerberos/etc) external OIDC solution should be deployed (ie keycloak) with operator IdP configured as backend

   3. In testing environment external OIDC solution should be deployed and bootstraped with test users

6. CA interface can be one of:

   1. Manual interaction by deployer that will retrieve certificates and the bootstrap ONAP instance with them

   2. One of automated certificate retrieval protocols (ACME, CMPv2 etc)

   3. In testing environment external CA (and ONAP should use automated certificate retrieval as described in b) solution should be deployed

Requirements on interfaces

Kubernetes

1. Cluster should be configured according to CIS Kubernetes Benchmark

2. Encryption at rest should be properly configured to ensure that secrets are never stored in the plain text

Databases

1. Each DB should be configured according to corresponding CIS guideline

2. All DB should be already created or ONAP should be provided with user that is capable of creating DB

3. If ONAP creates a DB a dedicated user account with privileges limited to that DB should be created. Password used for this user cannot be hardcoded in ONAP source.

xNF

1. Define by the  ONAP VNF security requirements

NFVI

1. Defined by the CNTT Reference Architecture 1 & 2

IAM

1. IAM must support OpenID Connect standard

CA

1. If automated certificate retrieval is used one of .... has to be supported by the CA (CMPv2, ACME, SCEP)

Requirements on exposed interfaces

1. North and south interfaces should be separated (ie different instance of ingress controller) to provide operator deployment flexibility

2. All Northbound interfaces musts be protected using TLS

3. All Northbound interfaces must support SSO

4. All Northbound interfaces must support RBAC

5. All roles used in ONAP have to be documented

6. All forms should validate and sanitize their input provided by the user

7. Southbound interfaces must satisfy VNF security requirements

8. ...