Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

POC Definition

Architectural Evaluation of AAF

Function

ONAP Today

Service Mesh

Risk

Authentication (Enforcement)




Password Authn

  • Performed by AAF
  • Performed locally
  • Uniform implementation

ONAP Today:

  • Difficult to manage
  • Showstopper for commercial use
  • Limited support from AAF and project teams

PKI-based Authn

  • Performed by AAF
  • Performed locally
  • Uniform implementation


Authorization (Enforcement)

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


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


Confidentiality on Internal Interfaces (Encrypted transport)
  • Performed by AAF
  • Performed locally


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 integrates natively with FluentD (CNCF open source data aggregation solution)
  • 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




Performance




Integration

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


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




  • No labels