Page Comparison

New Notary v2 project - address container image signing

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.  

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.

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). 

Rephrase proposal: for the purpose of using an alternative solution to AAF, whatever this solution would be.

OOM requirements are acceptance criteria for submitted patches and shall be know to the ONAP projects in advance - before Guilin release: for example if patch  would require root access to DB - it would be rejected as it would be not compliant with OOM requirement for Guilin release.

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  

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. 

Synch meeting with Requirements Subcommittee 

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