Attendees & Representation (default sort: member first name)

TAC Members and Project representatives should mark their attendance below 

Member Representatives

RepresentingMember
AT&T
China Mobile

vacant

China Telecomvacant
Cisco
Deutsche Telekom
Ericsson
Google

vacant

Huawei
Infosys
Nokia

Red Hat

Tech Mahindra

vacant

TELUS
Verizon

vacant

Wallmart
ZTE

Community Representatives

CommunityRepresentativeLifecycle
ONAPGraduated
OpenDaylightGraduated
AnuketGraduated
FD.ioGraduated
Nephio
Graduated
ODIMSandbox
EMCOSandbox
L3AFSandbox
XGVelaSandbox

Elected Representatives

Chairperson
Vice-Chair
Security
5G-SBP

Agenda

  • We will start by mentioning the project's Antitrust Policy, which you can find linked from the LF and project websites. The policy is important where multiple companies, including potential industry competitors, are participating in meetings. Please review and if you have any questions, please contact your company legal counsel. Members of the LF may contact Andrew Updegrove at the firm Gesmer Updegrove LLP, which provides legal counsel to the LF.
  • Roll Call
  • Check Action Items & Topic Requests
  • General Topics
    • 2024 Priorities
    • Security discussion
      • Create an LFN security scrum of scrums
        • Purpose: educate LFN projects on the LFN security guidelines
        • Frequency of meeting: monthly for first 6 months; quarterly after that
        • Governance: update Tony Hansen's ONAP OpenSSF dashboard to include all LFN projects; require all LFN projects to fill out OpenSSF report
        • Future: back up attestation with testing
      • LFN support of security
        • LFN provides static application security testing (SAST) and software composition analysis (SCA) tools and onboarding support for project
        • LFN pipelines create vulnerability reports to accompany each release: list vulnerabilities in project created code and known CVEs in 3rd party packages
        • Future: LFN tooling creates Jira ticket per code vulnerability and package vulnerability
      • LFN release certification
        • Add suffix to the release indicating lifecycle phase of the project and release
          • Example: name-version-incubation, name-version-sandbox
          • LFN TAC approves of version suffix
        • Provide bug report as part of release notes (fixed and open)
    • CNF Conformance 
  • Any Other Topics

Action items

Minutes

CNF Conformance → Cloud Native Telecom Initiative (CNTI)

  • Olaf Renner the LFN has a new initiative to build parity with the Anuket and the CNF WG and other testing initiatives. 
    • We want this to be governed at the TAC level
    • Cedric Ollivier said that he believes that the Anuket is already conforming to CNF test policies
    • Frank Brockners noted that there is a few aspects to conformance.
      • He spoke about self testing with the test suites
        • Right now tests are done by a 3rd party and how we can bring that back to being community driven
      • Olaf Renner asked how we could get the Anuket -CNCF assets aligned in a fully community driven way
      • Cedric Ollivier the CNF test suite is already in Anuket.  The only difference is that we can not do live on live testing.
      • Muddasar Ahmed are you saying the software complaiance testing is there, but we don't have runtime compliance testing?
        • Cedric Ollivier We can verify the cluster, but not the test suite itself in live
        • Muddasar Ahmed who approved the process?
        • Cedric Ollivier The test does make sense, but there are some tests that are different from CNF WG.  We don't do the live testing.
        • Muddasar Ahmed if the test tool is available, they can have a gradual increase of testing on the production instance
      • Olivier Smith : There are a number of projects that could be adding to those requirements that are not just Anuket.  The end users will need choices.  Nephio is an example that would likely need test suite that could be enhanced by not tying everything to Anuket.  We can't be just tied to Anuket.
        • Olaf: Anuket context may have a different view what cloud native is compared to the CNF WG.  
        • Olivier Smith : Agree that we need to align some of our requirements more with the CNF test suite.  There are indeed different views of what CNF is.  We should be constantly be trying to ensure a baseline conformance.
    • Muddasar Ahmed What is our desired outcome and governance?
      • Olivier Smith : There are 3 areas that we are focusing on
        • Building out the test suite catalogue
          • We want to be able to include other projects
        • Offer different conformance testing badges
        • Move all certification suites into one location
  • We asked the CNF WG members in attendance to introduce themselves
  • Frank Brockners spoke about the how the Board expects that the teams between the Anuket and CNF WG collaborate and find a way to reach our goals by April. 
    • Taylor, right now we are meeting to ensure alignment at the CNF WG
    • There is a desire to have something new that takes the best pieces and merges them under a new WG
      • tentatively named CNF Telco Initiative
    • Olivier Smith : It makes sense for us to at least come back and report to the TAC on our progress towards these initiatives. 
      • start preparation before next TAC meeting

LFN Security

  • Amy Zwarico spoke about the current efforts taking place with the Security WG
    • Create an LFN security scrum of scrums
      • Purpose: educate LFN projects on the LFN security guidelines
      • Frequency of meeting: monthly for first 6 months; quarterly after that
      • Governance: update Tony Hansen's ONAP OpenSSF dashboard to include all LFN projects; require all LFN projects to fill out OpenSSF report
        • She suggested that all of the LFN projects should adopt a similar security posture
        • Tony may be willing to help with the dashboard, but the projects will need to complete the OpenSFF badging template.
      • Future: back up attestation with testing
    • LFN support of security
      • Amy suggested that LFN provides static application security testing (SAST) and software composition analysis (SCA) tools and onboarding support for project
      • LFN pipelines create vulnerability reports to accompany each release: list vulnerabilities in project created code and known CVEs in 3rd party packages
      • Future: LFN tooling creates Jira ticket per code vulnerability and package vulnerability
    • LFN release certification
      • Add suffix to the release indicating lifecycle phase of the project and release
        • Example: name-version-incubation, name-version-sandbox
        • LFN TAC approves of version suffix
      • Provide bug report as part of release notes (fixed and open)
  • There was some follow up discussion about how Orgs trust open source projects
    • This initiative is important to build trust for mission critical environments
    • There is an obligation to ensure that we are removing bugs to the best of our ability 
  • Beth spoke about the LFN security team building some guidelines for the projects to follow as a baseline.
  • Olaf Renner +1 on having dedicated monthly meetings with security experts from the projects. We currently don't have LFN security requirements documented.
  • Continue discussion on release certification and TAC role in next TAC meeting

CNF Zero Trust whitepaper https://docs.google.com/document/d/10g2390JdCBXmSmzQ_EGHFWrg2JosPsXLaqXaGQ-B9NA/edit

2 Comments

  1. Some resources for security in open source:

  2. Re: Clarifications on the CNF initiatives formerly at CNCF as well as the Cloud Native Telecom program focus on cloud native 

    • CNF Test Suite is a community effort
      • There have been and continue to be contributions from companies such as MATRIXX, ChaosNative, Armo, Intel, Tieto, Kyverno
        • New tests, bug fixes, use cases, and examples are welcome and encouraged from the community
      • Some tests directly utilize upstream tests, just like the Anuket RC2 func test does for K8s e2e tests, including Kubescape, Kyverno, LitmusChaos
    •  The CNF Certification program only supports self-testing and was designed for self-validation
      • All certified products were self-tested by the companies in their environments
      • Instructions for self-testing are listed on the certification web page and repository

    Certification and tests in the test suite were added based on direct input from the community to relate cloud native best practices and principles to Telecom challenges.

    See the following for guidelines on what cloud native is, which have been the guidance for these efforts:

    Here are the high-level cloud native principles NGMN would like to see  applied to all layers (network infrastructure, applications and services):

    1. Decoupled infrastructure and application lifecycles over vertical monoliths  
    2. ‘API first’ over manual provisioning of network resources  
    3. Declarative and intent-based automation over imperative workflows  
    4. GitOps** principles over traditional network operations practices 
    5. Unified Kubernetes (or the like) resource consumption patterns over domain-specific resource controllers 
    6. Unified Kubernetes (or the like) closed-loop reconciliation patterns over vendor-specific element management practices  
    7. Interoperability by well-defined certification processes over vendor-specific optimisation. 

    These are based on the aforementioned principles, coming sourced from community papers and standards on this topic.  You can also see this repeated with vendors such as:

    It is also listed in various parts of the Anuket project such as https://cntt.readthedocs.io/projects/ra2/en/stable-nile/chapters/chapter01.html#cloud-native-principles

    A new program focused on cloud native testing and certifications (which is what we have heard the community wants in meetings so far) would build from the existing cloud native focused efforts adding more functional tests, and best practices → based on community input.