Versions Compared

Key

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

...

Jira No
SummaryDescriptionStatusSolution

AAF statusJohn (new PTL) joins PTLs meetings and he is learning on how AAF works. AAF was not the best documented project. We havre to be realistic. It takes longer to get answers from the AAF team. John has a bit less time to work on AAF than Jonathan had. AAF some features could be replaced with service mesh. AAF is still targeted for user store. (where you maintain your privileges) as we have to have a policy information point. But in terms of being policy enforcement point, there are solutions like service mesh. For the moment we are not aware of somebody working on integratuion of AAF and service mesh. 


New zoom for SECCOMThere is a cjhance that we might get a new zoom bridge to avoid overlapping with Architecture Subcommittee.LFN acquired a news zoom bridge.

Common topics with Architecture Subcommittee

Implementation of service mesh as an alternative for AAF in the domain of policy enforcement point.

Logging opensource alternatives. Guidance from TSC and technical subcommittees is needed + core team to drive the implementation.


Fabian and Natacha plan to investigate service mesh alternative . Dedicated meeting for brainstorming under organization on Friday 20th of March on 4 PM CET:  Join Webex meeting   

Guilin SECCOM priorities - review -of new proposals

Increase the number of CIS Docker Benchmark checks in the Integration healthchecks.

New tests proposal with the Integration team. 3 sections interesting from CIS docker benchmark:

-ensure that only trusted base images are used (section 4.2).

-ensure that healthccheck instructions have been added to container images (section 4.6)

-ensure that docker images in ONAP have removed setuid and setgid

Requirements shall be testable and additionally it is very good to ensure that the Integration team includes those tests in ONAP CI. 

Logs Management

Format of logs is not unified - we need to have a centralized monitoring. Stdout should be used by applications in the container first. In general logging is very poor in ONAP. We need to get buyin from Architecture and PTLs. MVP to be identified. Cloudnative initiative might be in correlation. Standardized logs are crucial from security perspective. However first step is to make sure that all applications are able to deliver logging solution and that we can collect them. As a second step we should ensure that logs are unified.

Draft recommendation idea:

  1. common place for data - all applications should generate logs that can be collected by Kubernetes (rtarget for G release)
  2. common format for data - format of minimum data that we want that is usefull (target for H release)

User access management - RBAC

RBAC is crucial for IAM - user access management (AAF or service mesh?) We do not want to do Identity Management - we want to have some opne source component in the defualt deplyment and then we want an easy way for operator to integrate it with their internal system.

AAF was built to support RBAC and it supports now Identity Management. Alternatively we could rely on some other open source project - and so we do not need to maintain that code. PP Comment: To be discussed on the next SECCOM - proposal from Prague meetings from Robert on RBAC implemented by ODL. 

Introduction of service mesh is a good opportunity to consider that kind of solution. Implementation of data base is a good example - you just take solution taht is available and not develop it from the scratch. PoC for service mesh should include RBAC capabilities. Also multitenancy should be considered.

ONAP MVP 

Baseline of ONAP and to have a different levels of components like gold - no issue with functionality and security. Other levels : silver and bronze could be also added. For security hardenining it is easier to focus on specific component and not on overall solution. Similar concepts represents OpenStack big tent.

Flow management 

Flow matrix - full map of all the flows - before deploying in operator's infrastructure there has to be full confidence on each traffic and we need to describe in details what is the entry, protocol type, port to be open or closed etc. with primary focus on outside of ONAP in an ingress. It is manadatory before deployment inside operator like Orange.


Amy will post info on new tests proposal on the Wiki and share the link with SECCOM. Short slot with the Integration team for their feedback to be organized by Amy.

In comments for REQ-2xx link to Wiki to be provided.

Next time Fabian will share docker run commands to nesure that specific capabilities are not allowed.


Amy will check with AT&T projects.

To check with OOM how we could use CNCF project outputs.





















Comment for status on Communication matrix to be checked and confirmed by Natacha.



CII Badging - feedback from recent PTL meeting

Tony summarized rrequirements for assurance cases - security document. REQ-223

Tony requested to work on 2 items:

  • assurance test (implement secure design) - only few projects (5 only) responded to this question
  • hardening

Unfortunatelu Unfortunately Tony lost his recent update for this requirement and will update it once again. 

Ongoing direct vulnerabilities analysis for components upgrades guidelines

Amy completed the work for non AT&T led projects. Pawel is prrogressing with DCAE.

We focus on criticals and severes.


Outputs to be presented at the next SECCOM. 

SECCOM chair and vice chair electionsConfirm that the correct voting member for your company is on the Security Sub-committee Members listStill waiting for Kenny's feedback Kenny was asked again at the PTLS call to provide his feedback - he promissed to respond. 


 OUR NEXT SECCOM MEETING CALL WILL BE HELD ON 24TH OF MARCH'20


...