POC Definition

Architectural Evaluation of AAF

Function

ONAP Today

Service Mesh

Risk

Password Authn

  • Performed by AAF
  • Performed locally
  • Uniform implementation

ONAP risk:

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

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
  • Access decisions based on URL and request header content (includes a JWT)
  • Keycloak or other OpenID Connect compatible service to manage roles and issue JWT token
  • JWT token can be used both within the the Service Mesh and on the Ingress Controller
  • Provides extensible architecture to support decisions based on content in the body
  • https://istio.io/docs/tasks/security/authorization/authz-jwt/

AAF risk:

  • custom solution with limited open source community support

Confidentiality on External Interfaces (Encrypted transport)

  • Performed by AAF
  • Performed locally

AAF risk:

  • per project work and understanding of init containers and AAF certman
  • Not integrated with K8S
Confidentiality on Internal Interfaces (Encrypted transport)
  • Performed by AAF
  • Performed locally
  • Can issue the certificates for both internal and external communication
  • Performed by Service Mesh
  • Service Mesh assigns an identity (spiffe https://spiffe.io/)
    to every pod
  • Service Mesh uses Citadel for certificate management, using the spiffe identity

ONAP risk:

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

Service Mesh risk:

  • need to be using at least Istio 1.5 for Citadel support

User Management (Information Store)

  • Part of AAF
  • Part of each project
  • Can use KeyCloak (or other openID Connect service) to manage manage users centrally
  • KeyCloak can be integrated with an identity provider

ONAP risk:

  • 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 or Keberos)
  • Limited support from AAF and project teams

Certificate Management

see confidentiality

see confidentiality


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
  • 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
  • Certificate management via certman mostly language independent (uses AAFinit container to put cert into volume) supports P12 and JKS, no PEM format. ONAP containers retrieve the cert from the volume.
  • AAF was not designed to be run on containers
  • Language independent
  • CA and certificate management external to ONAP
  • No code maintenance by ONAP
  • Cloud Native solution

ONAP Today:

  • Third party microservices require modification (modification may not be possible)
  • Cannot use the ONAP microservice independently
  • CA is part of ONAP, not external
  • If AAF fails during deployment, the ONAP containers cannot retrieve a certificate

Service Mesh:

  • external dependency that must be supported by integration and testing teams
  • external dependency that must be provided by an ONAP user

Layer 7 load balancing

  • AAF does not perform load balancing

https://istio.io/docs/concepts/traffic-management/


  • No labels