Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Please find below the Minutes of Meetings and recording for the SECCOM meeting that was held on 1st of February 2022.

Jira No
SummaryDescriptionStatusSolution

Securing connection between the Helm Client and Remote Helm Repository (Ramesh/Liam)a subject name

Helm charts to be held locally and these are the only repos you can pull HELM charts from.

Connection authentication services (option 1 and 4) and (option 2 and 3) configurability of destination supported, like a white list. Those 2 layers of security are a better option than single one of them.

Use of HTTPS = authenticated repo that HELM chart would be pulled (consumed). Once authenticated restrictions apply while K8s pulling from repo. Client needs to authenticate the repo that is pulling from. 

Service mesh can handle secure communication and authentication and authorization policies.

Begin with HTTPs connection. From the subject field from the repo would have a subject name that would be validated against white list. So first autheticate (HTTPs) and then authorize (white list). 

It is also crucial to ensure that to push HELM chart to the repo is under control (authentication and authorization. 2 way TLS: client doing a POST would be authenticated by the repo and authorization at the repo level would have to be done based on the subject field of the cert that was passed by the client. 

Mutual TLS enablement to standard client side.

ongoing

Need to address 2 points to avoid supply chain substitution attack:

  1. how do I autheticate I pulled from the right repo.
  2. How can I validate that the repo I pulled from is on my white list.

Byung will discuss service mesh option with Sylvain and OOM team on Wednesday.








https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-23423

Log4j upgrade

Log4j 2.17.1 was released. It provides a fix for a vulnerability: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832.

  • Following tickets opened:
  • With Istanbul maintenance release branches and CLM Jenkins jobs configured in jjb file, next round of log4j focussed scans and analysis.
  • Demo of CLM scans for Istanbul Maintenance was done.
ongoing

To check with Jess statuses of the tickets that were recently closed.

CLM scans per each project to be done by 4th of February.


Update of https://lists.onap.org/g/onap-security/members - updated listList of the participants to be updated with Maggie.doneStill waiting for Krzysztof's feedback.

CVE creation for ONAPKrzysztof proposed he will issue CVE for ONAP vulnerable to log4j release. ongoingTrying to reach out Krzysztof. If someone else knows the process, help is welcome (Muddasar might help as plan B).

Log4j CVEscould be checked here: https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-coreongoing

Sonarcloud API documentation

Following our last discussion ticket was opened to LFN IT (https://jira.linuxfoundation.org/plugins/servlet/theme/portal/2/IT-23519 ) to get the SonarCloud updated API documentation

ongoing

Ticket to LFN IT to be commented by Tony.



ONAP quality gates 

Quality asessment mainly for the submitted code (=delta)

  • Integrate tests with CPS
  • SO PoC
ongoing

Pawel to recheck with Seshu.

Pawel to point Toine.


SBOM generation

Jessica will perform SBOM creation - it is in her to do list.

Tony;s friend posted on Github tool that will look into Debain packages.

Presentation to Governing Board in SBOM topic.

Security logging in R-Alliance.


ongoing


Link to be shared by Tony.


SECCOM MEETING CALL WILL BE HELD ON 1st OF FEBRUARY'22. 

Security logging next steps - timeline

Quality gates for code quality improvements - continuation of the discussion.

SBOM next steps - status update with DCAE.




Recording: 



SECCOM presentation:







  • No labels