Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Jira No
SummaryDescriptionStatusSolution

SeshuAs Seshu did not join us,  next week slot will be provided (if needed).


Guilin SECCOM priorities

P1:

-Updates of the languages (java from v8 -> 11 and Python 2.7 -> to 3.x) – Interns from LFN could be gained

-Updates of directly dependent software components (Here we are thinking about benefiting from LFN Interns that could support projects in their packages upgrades, in addition the new version of Nexus-IQ is able to display components with direct and indirect dependencies, we should define priorities, release manager should help in coordination between projects)

-Automated security testing – containers not running as root – SDNC example

P2:

-Secrets management

-No root access to the DB from main application container Currently we have some pods (i.e. OOF) that require root access to their mariadb-galera instance for main application to work. This is obviously a security issue. Each application should have its own DB account that allows to access only its own DB.

-All config files inside the main container should be ReadOnly There are some weird design like in APPC where main container modifies properties provided by the user at runtime. I believe that application configuration should be read only.

P3:

-Increase of code coverage (to be honest in Frankfurt release it seems that not that much happened – I am not sure if each project proposed % feasible for them and followed the actions to achieve this

-CII badging

P4:

-High Priority SECCOM initiative: service mesh recommendation

-SECCOM initiative: OJSIs to be solved

-SECCOM initiative: https communication

We shall continue efforts for projects ongoin e.g. connectivity matrix, VNF Security requirments, CMPv2 etc. 

Based on brainstorming session we agreed on the following list with topics grouped together. 

List to be presented to PTLs and TSC .

Efforts on service mesh to be continued to have a real alternative to AAF which is failing as of today. We hope AAF would be better with new PTL John but service mesh alernative should be explored with: certificates, mTLS, sidecar.


SECCOM chair and vice chair electionsConfirm that the correct voting member for your company is on the Security Sub-committee Members listWaiting for Kenny's feedback Amy contacted Kenny to get information about process scheduling - February time frame?. 

Secrets encryption

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

In ProgressONAP secret management

Exchanges Tony-Krzysztof were done around the documentation. There should be a documentation on OOM charts (from OOM team to the projects) - as of today there is no such documentation at all. This is the area for improvement in the next release.

In ProgressKrzysztof to document in OOM including master password that has to be set at the deployment time.

AAF client certificate

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.

Jonathan\s responses for hardcoding passwords are not clear...

Jonathan to be addressed and John Freney - new AAF PTL with Amy's support to clarify - to be followed-up offline..It looks veru very weird - to be further investigated with AAF team. Mutual TLS = both sides can use the same certificate. OOM password removal - MariaDB-GaleraWhole encryption is blocking and compromised in SO.

Mariadb-galeraVNF Security RequirementsAmy asked for +2 for the reviewed items.
Jiras to be updated with comments (+2s)

Scripts for automatic Jira tickets creation for direct dependency components upgrades

PTL presentation on 10th of February. PTLs are concerned with many Jira tickets generated.

No news.

Meeting with Ittay, Pierre and Pam to be organized. by Amy.

Automated K8S tests enabled for Frankfurt

Feedback from PTLs - no specific feedback.

Propose enabling

Present to TSCDocker and Kubernetes Security

Bi-weekly meetings for security guidelinesThursday's meeting slot is not finally valid for Harald anymoreand invitation was sent to SECCOM distribution list..Data proposal to be was sent by Harald to seccom distribution list.M2/M3 SECCOM requirements update

-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?

Guilin release requirements to be prepared for the next SECCOM meeting.

Upcoming F2F meetings

Decide which meeting(s) SECCOM wants to focus on

Start collecting topics for the meeting(s)

In Progress

 OUR NEXT SECCOM MEETING CALL WILL BE HELD ON 3RD OF MARCH'20


...