Versions Compared

Key

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

...

Jira No
SummaryDescriptionStatusSolution

SECCOM Non functional requirements for Guilin release 

Wiki to be updated by each requirement leader by 27th of May. Additionally Jira requirement Epics will have to be created.

OngoingAmy already fulfilled packages upgrade requirement.AAF removal proposal 

Java and Python upgrades were putted in the separate requirements..

Following the discussions SECCOM team agreed with the following statment proposal:

AAF is a default security mechanizm for ONAP, it should be possible to replace AAF with an alternative solution.

OOF is the only project that is using AAF SMS.

Done

Done - waiting for a feedback from Taka. 

To be shared with Sylvain.

Taka do be contacted to check in what context AAF is used by APPC.

Guilin Integration non-functional requirements

Amy presented slides with Sylvain's proposal.

2 blockers identified:

  1. Exactly 1 main process per container - waiver can be granted for projects with technical reasons for having more than 1 main process.
  2. All logs written to STDOUT.

Components may use http = to have ability to run without https

Applications come with hadcoded passwordsand then when we try to replace it with something else, if it fails appliction is using default insecure passwords.

Many applications fail without any message - if you put special character inside the sed, it would not fail but produce result that you would not expect and then application configuration is broken. 

We ask PTLs to update their code to comply with those requirements. When TSC decides to put lower priority to some of those, we might have not being able to force for the existing code (we may try to achieve it gradually). Any new code should comply with those regulations that we have here. 

Nginx ingress is already part of the deployment.

20_05_19_GuilinIntegrationNonfunctionalRequirementsV2.pptx

IAM requirement

Waiting for Fabian's feedback.

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySECCOM-136

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySECCOM-172

to be reviewed by Fabian.

Logging proposal at the last PTL call

Christophe provided a proposal on logging.

Action plan is more short term and definitely a path forward. 

AAF statusNot clear if we have a new PTL - John Franey. New commiters (Pawel, John and Gerard) were only temporary or Frankfurt release.To be checked with John or Pawel. B.Content for Jira's for CII BadgingConversation on Security documentation meeting next week

SECCOM meeting on 17th of March we agreed on the following draft requirement:

  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)

All logs from applications should be stored in STDOUT.

3 kind of logs: debug, regular and auth. They have different types of information.

For centralized logs collection STDOUT might not be sufficient, so there should be continuation from there to some external system.

Natural channel would be syslog and then to send it somewhere else. 

Ongoing

Natacha to add Fabian;s requirements.

Krzysztof and Tony to update theirs as well.


Synch with Architecture Subcommittee.No presentation scheduled this week at the Architecture Subcommitteee meeting for Service Mesh PoC.


Security Guideline Documentation Hrarald is very occupied. and proposed to run meeting once content update is possible.


CII Badging requirement

Tony shared REQ-223 from Frankfurt release.

Assurance case. Built on top of other security requirements. Documentation security is one of the basis - what consumer of the project may or may not expect from the project.

Assurance case takes basic requirements and presents in a way: this is how we implement it , in other words: what shouldhappen, it does happen.

AAF is a good  example. Thanos is applicable to many ONAP projects.   

We shoud have a general document on ONAP security within next few months.

Distinction between run and design time. In the run time a lot of discussion within ONAP. In the design time which is very project specific they need to share what they did.

3 types of ONAP applications:

  • facing ONAP user
  • fully internal (just communicating with other ONAP components)
  • communicating with VNF

So we have 3 groups of documentations, where most of the stuff will be common.




 OUR NEXT SECCOM MEETING CALL WILL BE HELD ON 2nd OF JUNE'20.



View file
name2020-05-19_SECCOM_week.mp4
height150

View file
name2020-05-26 ONAP Security Meeting - AgendaAndMinutes.pptx
height150