Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Function

ONAP Today

Service Mesh

Risk

Authentication (Enforcement)

Password Authn

  • Performed by AAF
  • Performed locally
  • Uniform implementation

ONAP Todayrisk:

  • Difficult to manage
  • Showstopper for commercial use
  • Limited support from AAF and project teams
PKI-based Authn

Certificate Management

  • Performed by AAF
  • Performed locally
  • Each component must manage its certificates
  • init container obtains from AAF certman and puts the certificate in the volume
  • Uniform implementation
  • Managed by Sidecar
  • Strongly recommends the use of ingress controller instead of node port
  • cert manager project is the typical way of managing certificates in K8S
  • cert manager is separate from Service Mesh (https://github.com/jetstack/cert-manager)
  • Service Mesh designed to deliver the certificate to the pod (sidecar)
    • Internal communication: citadel certificates
    • External communication: cert manager delivers cert to the ingress controller

ONAP risk:

  • projects must manage certificates
  • AAF certman must be supported by AAF

Istio risk:

  • cert manager not support CMPv2
  • must enable Istio to obtain certificates from an external CA
  • must manage two levels of certificates
  • must disable all application level authentication

Authorization (Enforcement)

  • Performed by AAF
  • Performed locally
  • Uniform implementation
  • OAuth can provide the token (claims) to the application

Istio risk:

RBAC (Enforcement)

  • Supported by AAF
  • AAF RBAC is not widely used by ONAP projects
  • RBAC decisions based on URL and request header content
  • Provides extensible architecture to support decisions based on content in the body


Confidentiality on External Interfaces (Encrypted transport)

  • Performed by AAF
  • Performed locally
  • Performed by Service Mesh

AAF risk:

  • per project work and understanding of init containers and AAF certman
Confidentiality on Internal Interfaces (Encrypted transport)
  • Performed by AAF
  • Performed locally
  • Performed by Service Mesh

ONAP today:

  • per project work and understanding of init containers and AAF certman
  • no distinction between internal and external communication in current deployment

User Management (Information Store)

  • Part of AAF
  • Part of each project


ONAP Today:

  • AAF user/passwords not stored in user store
  • AAF has complicated user store management
  • Non-uniform solution is difficult to manage
  • Showstopper for commercial use
  • Most Operators have an existing user store (commonly LDAP)
  • Limited support from AAF and project teams

Certificate Management




TCP and UDP support

  • TCP supported
  • UDP not supported

DCAE (SNMP trap collector) uses UDP for data collection (SNMP)

Service Mesh would not change the security posture of ONAP use of UDP

Authentication could be implemented as a sidecar plugin, but would require custom work

Logging

  • The application has responsibility for transactional logging
  • Multiple solutions have been adopted by the projects (ONAP Logging, AAF-CADI, natively in application)
  • Some components running a sidecar that runs an application called filebeat that sends log files to ELK Stack (Logging) or ESSK
  • Logging project has not participated in the past two releases
  • Some components log to stdout
  • ONAP logging is customized
  • AAF provides logging capabilities
  • ONAP and Acumos logging projects have a common definition
  • Transactional events are logged by AAF-CADI, if integrated
  • Service Mesh could be integrated with ONAP Logging
  • Transactional events can be logged by Service Mesh instead of by the application
  • Collects the events to a centralized location
  • Consistent source of log data across all projects and requires no work from projects to collect the data

ONAP Today:

  • ONAP Logging is not actively maintained

Service Mesh:

API Tracing

  • provided by each application
  • Need an inventory of how each ONAP application is using AAF


Monitoring and Alarming

  • POMBA was the analytics logging analytics service and is in the process of being deprecated and removed from ONAP
  • ONAP logs can be ingested into an SIEM tool
  • ONAP does not provide native monitoring and alarming for the ONAP components
  • Service Mesh integrates natively with FluentD (CNCF open source data aggregation solution)
  • Logs can be ingested into SIEM tool (Falco, CNCF SIEM open source project https://www.infoq.com/news/2020/01/falco-security-cncf/)
  • Service Mesh collects information about ingress and egress traffic, including authentication
  • Neither ONAP nor Service Mesh provide native monitoring and alarming functionality

Performance

  • CADI is part of the application container
  • sidecars are separate containers
  • Proxy must be running in order to route transactions to the destination service outside the pod
  • Sidecar may have impact on throughput (adds 3ms of delay)
  • Sidecar may increase the ONAP resource requirements (potentially 3G for a full ONAP deployment)

Integration

  • Enforcement of AN/AZ requires code development
  • AAF CADI only supports Java
  • Language independent

ONAP Today:

  • Third party microservices require modification (modification may not be possible)
  • Cannot use the ONAP microservice independently

Layer 7 load balancing




Integration with Ingress




...