Topics

ONAP SECCOM : file for generating communoication matrix for review.


natacha.mach@...
 

Hello,

 

We would like to submit for review the attached YAML file.

The initial purpose was to be able to centralize relevant information regarding the communications established between components (and their sub components) of ONAP.

 

ð  The approach is proposed as collaborative, meaning that each project would be responsible for completing the file for its scope.

ð  There will be a presentation of the file (either during PTL meeting, or during F2F ONAP).

 

Best regards,

 

Natacha Mach

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


Pawel Baniewski (Nokia)
 

Natacha, few comments from my side, which we can discuss on next ONAP SECCOM.

 

  1. I propose to split flows into three types:

external_communication – between Operator and K8s cluster which hosts ONAP (UI -> backend component)

inter_project_communication – between different ONAP projects (DCAE -> AAF)

internal_communication – as right now, within one ONAP project (DCAE X -> DCAE Y)

 

With this approach we can easily find services which are NodePorts but shouldn’t be, what should be exposed on Ingress Controller in the future, manage Service Mesh Traffic Management in the future, etc.

 

  1. I might be wrong, but usually clients knows to what they are establishing connections, while servers don’t care. Your approach took different direction – from service (server) perspective you want to list all clients (also from different ONAP projects) which might be unrealistic in such huge project. IMO every project should list internal communication, communication between Operator and K8s cluster and outgoing communication (from own component to other ONAP project’s service)

 

  1. Also, I think there will be a challenge with different naming, as different ONAP projects may call differently the same
    1. client used in external_used_by and internal_used_by
    2. service name

– to harmonize I propose to extend metadata by list of components and services and use only such names (when PTL from project X will fill in own metadata file (s)he will have to check how component/service from project Y is called and use such name – easy to validate when processing multiple metadata files and open solution if new components/services will be added in the future)

 

  1. Section port can’t be a list as usually different communication is used there (protocol, data flow, etc)

 

 

Regards

 

Pawel Baniewski

____________________________________________

Nokia Mobile Networks  BTSOAM Serviceability ARCH Tribe Architect

 

mobile: +48 728 361 386

 

From: onap-seccom@... <onap-seccom@...> On Behalf Of natacha.mach via Lists.Onap.Org
Sent: Tuesday, July 30, 2019 4:57 PM
To: onap-discuss@...
Cc: onap-seccom@...
Subject: [Onap-seccom] ONAP SECCOM : file for generating communoication matrix for review.

 

Hello,

 

We would like to submit for review the attached YAML file.

The initial purpose was to be able to centralize relevant information regarding the communications established between components (and their sub components) of ONAP.

 

  • The approach is proposed as collaborative, meaning that each project would be responsible for completing the file for its scope.
  • There will be a presentation of the file (either during PTL meeting, or during F2F ONAP).

 

Best regards,

 

Natacha Mach

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.