Page Comparison

Krzysztof has a draft wiki page documenting the approach for ONAP secrets management and would like feedback.

In general ONAP should not hardcode any secrets inside the HELM charts.

For the solution first of all we should remove all default values for HELM chart external secrets. For example OpenStack password should be provided by user at the deployment time. We do not want to generate random values because this creates some issues during the upgrades. We would like to utilize well known master password algorythm (supported by spring library which is part of HELM).

We also expect that the underlying Kubernetes cluster is configured properly which means taht it uses encryption and REST plugin - secrets are never written in plein text into etcd.

It could be good if details (namespace, secret and key) would documented. Documentation is available here:

https://gerrit.onap.org/r/gitweb?p=oom.git;a=blob;f=docs/oom_user_guide.rst;h=48701f7c3126d1ccf70178d5303868cf5368d4c9;hb=refs/heads/master

Feedback that Ramesh has putted few certificates to OOM repo resources. why not used aitomated certificates generation by AAF - feedback that those are not SSL certificates and automated certificates generation is only on server side and client side certificates have to be hardcoded in the repo!.   

We should not have any single certificate within OOM repo or any container image

• Update on requirement for projects to update out of date direct dependencies. (REQ-263)

Description and examples of the CLAMP script

Feedback from the PTLs\ meeting was to not run the script because the Jira tickets would create addtional work. They would prefer to track progress using gerrit reviews.

SECCOM:

• jenkins runs unit tests for major and minor versions.
• junit tests may not catch all impacts of upgraded packages. Results may be repo dependent
• it may be possibly to leverage the oparent

Actions: put ideas on onap-discuss and set up a separate meeting if there is enough interest

Remediating Known Vulnerabilities in Third Party Packages

Automated K8S tests enabled for Frankfurt

Feedback from PTLs - no specific feedback.

Propose enabling

Oracle JDK which is commercial - benefits updates

Open JDK - like open source so free of charge but support for java 11 but not earlier versions.

2/11 update

Docker images for both the Debian and Alpine releases of the Java 11 JDK will be available for all projects

TSC wants to know which distribution of the OpenJDK is used – Integration team/OOM to be contacted - discussion planned for next status meeting on Wednesday. SECCOM cares Java 11 and not particular distribution - we appreciate common image from governance perspective and harmonization - coordination on release manager side.

Next steps:

E-mail to be sent to Morgan with Pawel B. in copy to confirm if image is already created.

-SECCOM Coverity integration by end of Frankfurt (REQ-247)– moved to Guilin release

-SECCOM Perform Software Composition Analysis - Vulnerability tables (REQ-263) – descoped

-SECCOM Java 11 migration from v8 (REQ-219) - feedback from PTLs call?

-SECCOM CII badging – meet targeted Silver and Gold requirements (REQ-223) - feedback from PTLs call?

Decide which meeting(s) SECCOM wants to focus on

Start collecting topics for the meeting(s)