Page Comparison

1

• Create performance improvement plan.

Performance test results for Casablanca here: Platform maturity: performance/stability test plan.

Identify bottlenecks as a start for improvement plan.

Estimation:

• Improvement plan: 1-2 days of work.

2

Project level requirements

• Level 2: CII Silver badge, plus:
  • All internal/external system communications shall be able to be encrypted.
  • All internal/external service calls shall have common role-based access control and authorization using CADI framework.
    
    

ONAP Platform-level requirements per release 

Level 2: 70 % of the projects passing silver 

• with non-silver projects:
  •  completed passing level and 80% towards silver level
  • internal/external system communications shall be able to be encrypted

Encryption not implemented for:

• InternalServlet (isAuthorizedForInternal)
• RouteServlet (isAuthorizedForInternal)
• PublishServlet
• StatisticsServlet
• LogServlet
  
  

Access control/authorization not implemented.

CII Silver badge

The project MUST document what the user can and cannot expect in terms of security from the software produced
by the project. The project MUST identify the security requirements that the software is intended to meet and an
assurance case that justifies why these requirements are met.

CII Badging Program

Currently DR on Passing level.

Data Router (DR) API Guide

Estimation:

• Encryption: 2-3 days of work. (Fairly repetitive work. update classes
  • InternalServlet (isAuthorizedForInternal)
  • RouteServlet (isAuthorizedForInternal)
  • PublishServlet
  • StatisticsServlet
  • LogServlet
  )
• Role-based access: 1 sprint

• A component can be independently upgraded without impacting operation interacting components
• Component configuration to be externalized in a common fashion across ONAP projects
• All application logging to adhere to ONAP Application Logging Specification v1.2
• Implement guidelines for a minimal container footprint

Currently implemented:

• Log4J (to log events and internal logging) and
• EELF (for logging API calls) .

Considering eelf is one of the suggested logging frameworks for the spec, and we have nothing implemented for slf4j, we should ideally use only eelf for our logging purposes and replace any log4j logging with eelf

Guidance for Implementation

• Please refer to the Logging Enhancements Project documentation for guidance on implementing logging, including the Logging Developer Guide.
  • For transaction tracing, the Logging Spec v1.2 supports MDCs and Markers.  In the future, a service mesh could support this.
  • Portal will do the example for other projects.
• Independent upgrades can be accomplished with OOM and helm charts.
• Configuration can be externalized into Helm charts via the OOM project.  See OOM Configuration Management.
• See this presentation and follow the Container Image Minimization Guidelines

Estimation:

• Use one Logging system: 5 days of work (35 files to update x several line each)
• Logging to adhere to ONAP Application Logging Specification v1.2: two MDCs implemented (RequestId and InvocationId.
  Nine more to be implemented:

InstanceID
ServiceName
PartnerName
StatusCode
ResponseCode
ResponseDesc
Severity
ServerFQDN
ClientIPAddress)

Update the format of the logging to conform to v1.2 spec.

Some additional work required to provide log data to Audit Log and Metric Log. 1 sprint of work.

• Implement guidelines for a minimal container footprint: 1-2 days
• Component configuration to be externalized: