Versions Compared

Old Version 35

changes.mady.by.user Byung-Woo Jun

Saved on

compared with

New Version Current

changes.mady.by.user Byung-Woo Jun

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents


Key Contacts - Byung-Woo Jun  (Ericsson)


Note: The ONAP Streamlining - The Process has been approved by ONAP TSC


ONAP Benefits to the Industry

Contribution - Great Accomplishments!

...

ONAP Deployment Dependencies (by Andreas Geissler)

See ONAP deployment dependenciesevolution 


ONAP Helm Charts Dependencies (by Andreas Geissler)

...

CDS Service Provider Interface

  • tbd

ONAP Component Runtime Security Analysis

  • ONAP components are protected by Ingress Controller, Keycloak (IdAM) and Istio (Service Mesh), with AuthN/Authz, intra-secure communications, external-secure communications.
  • ONAP components themselves do not have their own/ proprietary protection any longer (e.g., removal of HTTP Basic Authentication and HTTPs).
  • Current OOM-provided security support as described above will be provided as ONAP reference security mechanism.
  • It is assumed that vendors/operators support industry de facto security mechanism like ONAP security and imported ONAP components are protected by the security mechanism.
  • ONAP will provide documentation of security architecture, global requirements and best practices, informing how to protect/secure selected ONAP components.
    • For secure external communications, Ingress Controller, aouth2-proxy and IdAM are used
    • For intra-secure communications, Istio is be used with Cert-Manager and policies
    • For user authentication and authorization, KeyCloak is used, with SSO support and OAuth2-based token generation and validation

Image Removed

ONAP Component Code Security Analysis

Each ONAP component needs to meet code security practices and certifications that are defined by SECCOM. There would be no direct impact for ONAP Streamlining.

Additional analysis will be provided as needed. 

ONAP Component Logging Analysis

  • ONAP supports open-source and standard-based logging.
  • ONAP already separates log generation from log collection / aggregation/persistence/visualization/analysis.
    • Each ONAP component handle log generation only thru STDOUT and STDERR, by following ONAP security logging fields – global requirements, https://wiki.onap.org/display/DW/Security+Logging+Fields+-+Global+Requirement
    • The log destination will be configured
    • Log collection agent(s) will be configured; ONAP reference configuration is using FluentBit as the collection agent;
      • ONAP uses a separate privileged namespace to deploy FluentBit for security reasons
      • Vendors/operators can configure it differently, based on their needs
    • Vendors/operators can realize and configure the log collection/ aggregation/persistence/visualization with their own logging ecosystem
  • There will be no/minor impact on logging due to ONAP component disaggregation

Image Removed

ONAP Component Focused Integrated Testing

  • ONAP supports clustering components by use cases:
    • Selection of the best components for a particular task in systems
    • Responsive integration and delivery
    • ONAP still can provide reference automation for coordination
  • ONAP E2E integration testing can be performed for code quality.
  • Focused Integration testing can be performed, based on use cases.
  • Additional analysis will be provided as needed.

Release Management Tasks - TBD...

  • Marketing version, Montreal, will be scheduled as the previous releases.
  • Setting release schedule plans for Montreal
  • The Marketing version will be used as the Major version by ONAP projects
  • PTLs decide the minor and patch versions, based on their project release cycles and share the project versioning with TSC
    • Provide each component release flexibility and evolution
  • Integration & Pair-wise testing
  • Integration testing will continue to increase ONAP project overall qualities
  • Pair-wise testing will continue but it will be based on use cases
  • Project testing will be performed by each project team
  • For Montreal, security scanning will continue as before

  • Based on feedback during the Montreal, the release plan can be revisited

Special Interest Group (SIG) - TBD...

  • Technical coordination and governance (former TSC)
  • Architecture & Interoperability (could be on LFN level)
  • LFN security
  • LFN common practices
  • Modeling
  • LFN documentation consistency
  • Technical outreach (SDO & Open-source)

Presentation

  • CDSE-1: CDS interface for Blueprint


CCSDK Service Provider Interface (it is a set of libraries for DCAE, OOM, SDNC)

  • ASDC-API: RESTConf interface for non-TOSCA
  • dataChange: RESTConf pub/sub interface
  • LCM: RESTConf for LCM events
  • SLI-API: RESTConf for service logic interpreter
  • selfservice-api: gRPC interface with CDS
  • oofpcipoc-api: RESTConf for OOF/PCI integration

ONAP Component Runtime Security Analysis

  • ONAP components are protected by Ingress Controller, Keycloak (IdAM) and Istio (Service Mesh), with AuthN/Authz, intra-secure communications, external-secure communications.
  • ONAP components themselves do not have their own/ proprietary protection any longer (e.g., removal of HTTP Basic Authentication and HTTPs).
  • Current OOM-provided security support as described above will be provided as ONAP reference security mechanism.
  • It is assumed that vendors/operators support industry de facto security mechanism like ONAP security and imported ONAP components are protected by the security mechanism.
  • ONAP will provide documentation of security architecture, global requirements and best practices, informing how to protect/secure selected ONAP components.
    • For secure external communications, Ingress Controller, aouth2-proxy and IdAM are used
    • For intra-secure communications, Istio is be used with Cert-Manager and policies
    • For user authentication and authorization, KeyCloak is used, with SSO support and OAuth2-based token generation and validation

Image Added


ONAP Component Code Security Analysis

Each ONAP component needs to meet code security practices and certifications that are defined by SECCOM. There would be no direct impact for ONAP Streamlining; i.e., business is as usual.

Additional analysis will be provided as needed. 


ONAP SECCOM Roles

The following lists ONAP SECCOM roles and duties:

  • Provide global requirements and best practices and audit tests - example: require secure code
  • Provide secure reference implementation and documentation - example: logging, service mesh, external security with authentication and authorization
  • Prioritize vulnerability fixes
  • prioritize secure enhancements
  • Proposal: ONAP projects work with latest version of common components such as Istio, KeyCloak, Kafka, Ingress...

ONAP Component Logging Analysis

  • ONAP supports open-source and standard-based logging.
  • ONAP already separates log generation from log collection / aggregation/persistence/visualization/analysis.
    • Each ONAP component handle log generation only thru STDOUT and STDERR, by following ONAP security logging fields – global requirements, https://wiki.onap.org/display/DW/Security+Logging+Fields+-+Global+Requirement
    • The log destination will be configured
    • Log collection agent(s) will be configured; ONAP reference configuration is using FluentBit as the collection agent;
      • ONAP uses a separate privileged namespace to deploy FluentBit for security reasons
      • Vendors/operators can configure it differently, based on their needs
    • Vendors/operators can realize and configure the log collection/ aggregation/persistence/visualization with their own logging ecosystem
  • There will be no/minor impact on logging due to ONAP component disaggregation

Image Added


ONAP Component Focused Integrated Testing

  • ONAP supports clustering components by use cases:
    • Selection of the best components for a particular task in systems
    • Responsive integration and delivery
    • ONAP still can provide reference automation for coordination
  • ONAP E2E integration testing can be performed for code quality.
  • Focused Integration testing can be performed, based on use cases.
  • Additional analysis will be provided as needed.


Release Management Tasks 

  • Marketing version, Montreal, will be scheduled as the previous releases.
  • Setting release schedule plans for Montreal
  • The Marketing version will be used as the Major version by ONAP projects
  • PTLs decide the minor and patch versions, based on their project release cycles and share the project versioning with TSC
    • Provide each component release flexibility and evolution
  • Integration & Pair-wise testing
  • Integration testing will continue to increase ONAP project overall qualities
  • Pair-wise testing will continue but it will be based on use cases
  • Project testing will be performed by each project team
  • For Montreal, security scanning will continue as before

  • Based on feedback during the Montreal, the release plan can be revisited

Montreal Release Plan Proposal

  • Each PTL determines their project agile cycle(s) based their features
  • PTLs/Feature owners coordinate with ARCCOM/REQCOM/SECCOM/TSC for the feature review and approval per agile iteration
  • PTLs/Feature owners may work with OOM, INT and DOC for build, testing and documentation, as needed
    • project release specific documentation should be handled in a automated fashion (e.g., scripts; PTLs create the release-specific rst and scripts put the rst contents into RTD)
  • Each agile iteration/sprint is reviewed and critiqued by the project team (and ARCCOM/REQCOM/SECCOM/INT/TSC as needed…) and is used to determine what the next step (PTL decides it) until RC
    • e.g., priorities, guidance, standards, security…
  • After Montreal, we may want to revisit the Marketing release RC and Sign off


Image Added


Documentation Versioning Proposal


Image Added


Special Interest Group (SIG) - TBD...

  • Technical coordination and governance (former TSC)
  • Architecture & Interoperability (could be on LFN level)
  • LFN security
  • LFN common practices
  • Modeling
  • LFN documentation consistency
  • Technical outreach (SDO & Open-source)


Presentation

References

...