Page Comparison

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:

• role management (ILM)
• investigate leveraging AAF as a policy decision point and/or policy information point
• https://istio.io/docs/tasks/security/authorization/authz-http/

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

• Performed by Ingress Gateway
• Use Cert Manager (https://github.com/jetstack/cert-manager) integrated with K8S to manage certificates

AAF risk:

• per project work and understanding of init containers and AAF certman
• Not integrated with K8S

• 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

• TCP supported
• UDP supported

• (https://istio.io/docs/ops/configuration/traffic-management/protocol-selection/)

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

• Sidecar intercepts the networking stack and can gather basic statistics and logs to a central location

• https://www.envoyproxy.io/docs/envoy/v1.12.0/intro/arch_overview/observability/tracing

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/