Please find below the Minutes of Meetings and recording for the SECCOM meeting that was held on 24th of March 2020.
| Jira No | Summary | Description | Status | Solution |
|---|---|---|---|---|
| List of security items that must be addressed for Frankfurt release | 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. 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. |
Security MVP proposal for a Frankfurt release and draft for Guilin release are available on the Wiki
Action Point: to join OOM meeting on Wednesdays to address simulators compliance with https requirements.
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.
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 Awel 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 . |
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:
- common place for data - all applications should generate logs that can be collected by Kubernetes (rtarget for G release)
- 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.
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
| Ongoing direct vulnerabilities analysis for components upgrades guidelines | 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. | There was no time to present the results in the detail | 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 | Harald shared his positive feedback on last meeting. Amy is already working on an item. We will use Wiki as a collaboration space and then transfer it to readthedocs. | Link for the readthedocs scripts to be shared by Harald. | ||
Service Mesh risk analysis – meeting summary available here | Service mesh requirements from security perspective followed by risk analysis. | |||
| Hackathon for https | Self-signed tls certificates to be used around begining of the release. Same methodology to be used by all projects. by M1 support for https, then Hackathon organized and by M2 everyone is integrated with AAF. |
| OUR NEXT SECCOM MEETING CALL WILL BE HELD ON 31st OF MARCH'20 |
| View file | ||||
|---|---|---|---|---|
|
| View file | ||||
|---|---|---|---|---|
|