2020-03-31 Security Subcommittee Meeting Notes (under construction)

SO made an effort to close several OJSIs and only one is remaining - for this specific one waiver for SO for OJSI with AAF interaction – approved by SECCOM.

Whitelisted projects - Krzysztof will submit a patch to Morgan.

Replacement of AAF by service mesh - we want to replace only part of AAF which is policy enforcement.

CII Badging - Tony provided some additional inputs to REQ-223 comments. AAF made good examples. 7-9 good assurance cases.  Template preparation by SECCOM couldbe felpfull for ONAP project. Assurance case = how your project is internally secure and protects security of the things that deals with. Security document says how the appliction is secure baed on its architecture. Assurance case this is what we did in the implementation to meet security requirement. Example of assurance casse:  thanos.io/security.

Availble here. Under restricted access Wiki information about direct dependency vulnerabilities and recommended upgrade version is provided per repository. Additionally status column should reflect actual status of the upgrade process. Priority 1 is the highest and reflects critical vulnerabilities for upgrade. Priority 2 reflects severe level vulnerabilities. Each project will have all the info in one place under its dedicated Wiki. Per each project there will be ajira ticket open with link to the Wiki. In some cases we will not eliminate all vulnerbilities but we will significantly reduce them.

CLAMP is the first project without any direct vulnerability - congratulations to Martial and project team!

Report is available here.

OJSI-145 on the whitelist - to be checked why. 3 issues from SDC, one issue from VES colector blocked by some integration testing. For VNFSDK - whu they still exposing JDWP? OOM made a really good progress with passwords removal around MariaDB-galera.

Morgan reprts scan results of the current ONAP instance. We expect hash commit for removing the vulnerability for transparency.

TSC requested general report on ONAP security that should include list of items that must be completed by end of Frankfurt release and plan to move forward after Frankfurt.

For removing hardcoded passwords from HELM charts many challemges appeard so not finished as expected. - key takeaway is to do most of the work inside of the OOM repo. Solution was to create an init container and just replacing those passwords by putting it in momory volume which is as secure as the application taking it for environment variable. The difference with AAF solution is that it using persistent volume while Krzysztof used in memory volume.

Jonathan's AAF Video

Discussion on http ports open for test purpose (DCAE with VES collector use case). Nokia will fix PNF simulator.

Brief review of SECCOM requirements for FRankfurt release ranked by TSC with a priority1:  REQ-235 (Password removal from OOM HELM charts) and  REQ-231 (HTTPS communication vs. HTTP).

ONAP use cases shall be ran by user in default ONAP deployment which is secure.

Problem statement: ONAP simulators that are not compliant with https policy and support only http. Morgan and Marco are the right points ofcontact for this issue.

Discussion on ONAP code and ONAP testing difference - baseline security requirements should be exactly te same for both. VNF Requirement for https communication puts an obligation on ONAP simulators as well. Reference: VNF HTTPS requirement R-49109: The VNF or PNF MUST support HTTPS using TLS v1.2 or higher with strong cryptographic ciphers. 

This requirement was formalized when Frankfurt was already in progress?

In service mesh internal communication is done with mTLS. For an external communication it would be an ingress controller for example: SSO certificate at the entry and then from ingress controller to component using a separate certificate that comes from the mesh.

Regarding encoded passwords - for now we are doing only MariaDB-galera. Projects like DCAE and A&AI are authenticating to each other using user names and passwords - if we decide to go with service mesh, user names and passwords would be dropped in favour of mTLS and certificate based authentication. That way we would eliminate a lot of hardcoded passwords without using Kubernetes secrets, just by providing certificate and moving from basic auth to certificate based authentication. Every service has certificate that is binded for its identity (for identification) and private key for authorization.

For service mesh implemenattion - document framework for Guilin release and for the H release make application - really use it.

Security MVP proposal for a Frankfurt release and draft for Guilin release are available on the Wiki

Action Point - -email to be sent by Pawel to TSC and ONAP community with link reference to Security requirements for a Frankfurt release. 

Action Point: to join OOM meeting on Wednesdays to address simulators compliance with https requirements.

The idea is to organize a security framework based on service mesh as a deliverable for Guilin release to avoid push-back from some PTLs .

Amy completed the work for non AT&T led projects. Pawel is progressing with most of AT&T ones.We focus on criticals and severes.

Amy created a table on a Wiki with reference for upgrade versions.

For ODL upgrade will have to be done with multi-jump fashion.

Outputs to be presented at the next SECCOM. 

Docker image version to be added. - for the exact version Fabian will check with Sylvain.

Security guidelines for ONAP – meeting summary

Service Mesh risk analysis – meeting summary available here