Versions Compared

Old Version 1

changes.mady.by.user Stephen terrill

Saved on

compared with

New Version Current

changes.mady.by.user Srinivasa Addepalli

Saved on

Key

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

...

  • Scenario descriptions (components using ISTIO, and components not using ISTIO etc).
  • Communication between components that are using ISTIO
  • Communication between components that are using ISTIO and those that are not using ISTIO.
  • Overall ONAP cert management and AAF.  This should consider how it is viewed from the ONAP users perspective
  • ONAP project requirements


Experiment 

Coexistence of ISTIO CA and AAF CA  AND secure communication along with Authentication & Authorization is covered in this presentation: https://lf-onap.atlassian.net/wiki/download/attachments/16231787/ISTIO-Envoy-MutualTLS_v2.pptx?api=v2

With respect to non-security related to ISTIO such as "Service registration/discovery" is overlapping technology with MSB.  We will need to ensure that existing ONAP projects & Projects that get enhanced to use ISTIO will work together.

There is a desire to move slowly to ISTIO.  Desire to start with two projects with ISTIO.  It means that some ONAP services are ISTIO based and some are MSB based.  Hence coexistence is needed.

We intend to do following experimentation to ensure the coexistence of projects that use ISTIO and projects that don't use ISTIO. (Kiran to experiment and provide feedback)

  • Make sure that Rancher configuration is modified to deploy ISTIO components.
  • Take two ONAP projects (Leaning towards OOF and Multi-Cloud - Yet to work with PTLs).
  • Delink these two projects from using MSB for service discovery and service registration (Seems like a configuration change - No code changes are required)
  • Delink these two projects from getting certificates from AAF CA (It appears that these two projects are not getting the certificates from AAF CA, hence no changes required)
  • Identify all containers within OOF and Multi-Cloud.
  • Ensure that each container (of OOF and Multi-Cloud) is associated with side car (Need to see whether to go with manual injection or go with automatic injection with some policies to ensure that side cars are injected only for these two projects. If it is manual injection, I guess each deployment of these containers is modified via Helm charts)
  • Use ISTIO CA for these containers to get the certificate enrolled using ISTIO CA
  • Use ISTIO Service mesh for them to communicate with each other and also to communicate with external containers.
  • Since we would like other neighbor projects to communicate with OOF and Multi-Cloud,  identify containers that other project use them as producers. (Should we expose OOF/MC via MSB or hide these services under istio-ingress?)
  • If any of the containers are consumers of other projects' services, how does our services discover the producer services that use MSB?  (Should our services discover the services using MSB or use some other mechanism?)

Recommendation Status

Draft

Recommendation

...