Function | ONAP Today | Service Mesh | Risk |
Password Authn | - Performed by AAF
- Performed locally
| | 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
| - 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
| | 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 |
|
|
|
