Service Mesh Risk Analysis

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:

• 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

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

• 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/