You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Please find below the Minutes of Meetings and recording for the  SECCOM meeting that was held on 28th of April 2020.

Jira No
SummaryDescriptionStatusSolution

New Notary v2 project - address container image signing

Tero shared a week ago info about this new project. Notary v2 use  cases: https://github.com/notaryproject/requirements/blob/master/scenarios.md

Dedicated SECCOM meetings around this topic (requirements and features) could be organized if only we have a core team to work on it and ONAP contributions to Notary v2.  We should look on how ONAP would use Notary v2, especially in CNF context, like onboarding.


WE take some extra time to analyse and consider if we could contribute.


TSC logging presentation – discussion point

20_04_30_ONAPLoggingGuilin_V1.pptx

We need to bring it to the Architecture Subcommittee. ONAP component retirement and replacement still requires discusssion at the TSC level.

Logging is not just a collection of logs but also analysis and the retention.

FluentD - we need to check if full logging needs could be fulfilled.  


ONAP project use of Logging

2 next steps:

-Understand logging and upgrade path to Java 11. In order to move forward, we have to identify logging project representative.

-Consider open source projects as equivalent for logging and impact on other ONAP projects - we would need a proxy/representative for logging open source.


OOM requirements for Guilin

VErsions required are inline with SECCOM recommendations.

As the AAF usage (or rather not using it at all) statement seems to collect different points of view, Sylvain proposal was shared with SECCOM distribution list, so we could conclude the discussion at the next SECCOM (on 12th of May). 




Service mesh and ingress feature

We we speak about an external https - in the future this feature will be used and deployed and feature will be used with ingress that is why we don't want to use https for an external communication for each component we need it. For Kubernetes we just need to deploy ingress feature. And we already have ingress in the source code (it came with F release). For now we are doing SSL redirect , if service support https. It is also a valid deployment option if you do SSL termination at the ingress gateway, not at the component. 

Internal request - if you use in the future service mesh, we do not want to have double https and mTLS in the same way but only one point to manage certification. In this case sidecar will be managing TLS  




Hardcoding certificates in docker images

PKI - public certificate that is signed by the Certificate Authority.

AAF contains hardcoded trust store. According to Krzysztof this is a security issue as root CA in ONAP is already compromised. By default none of the ONAP images should trust that CA. Only If user is deploying ONAP for testing, in lab environemnt, it is fine to use that. 

A lot of components use AAF hardcoded certificate.

Trust store that is in the AAF agent image should be removed from that image and placed in the OOM as a resource and delivered in the image at the deployment time. 







We need to have an agreement from projects. This proposal to be presented at the PTLs call.


Synch meeting with Requirements Subcommittee 

Synch meeting with Requirements Subcommittee – we missed the one on 27th of April to present SECCOM requirements for Guilin release – next meeting is sccheduled on May 11th. CMPv2 requirements will be presented by Pawel on to the Requirements Subcommittee. 


CII Badging requirement 

Jira tickets to be created info to be shared with Krzysztof.





 OUR NEXT SECCOM MEETING CALL WILL BE HELD ON 12th OF MAY'20.








  • No labels