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

• 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

Propose enabling

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

Questions for Krzysztof:

• Are secrets stored as clear text or base 64.
• Which projects have had the clear text secrets removed.
• How is the master password protected

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.

2/11: Confirm documentation and location of Debian and Alpine images

Decide which meeting(s) SECCOM wants to focus on

Start collecting topics for the meeting(s)