Re: ONAP secure communications via VPN in addition to HTTPS? #security #seccom

Krzysztof Opasiak
 

Dear Keong Lim,

On 08.05.2019 03:57, Keong Lim wrote:
Hi Seccom,

Have just been looking at https://jira.onap.org/browse/OJSI-97 due to its relationship to https://jira.onap.org/browse/AAI-2411 and the struggle to have the corresponding gerrit review merged https://gerrit.onap.org/r/#/c/87178/

which lead to browsing these related 87 issues:
https://jira.onap.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=text+%7E+%22plain+text+http%22+ORDER+BY+updated++DESC

Would the progression of https://jira.onap.org/browse/SECCOM-92 for "ONAP Communication Security Requirements" be assisted by implementing a node-to-node VPN at the level of the VMs/physical servers that host the Kubernetes pods/docker containers?

See also https://wiki.onap.org/display/DW/ONAP+Support+for+Secure+Communication

It seems to me that securing the infrastructure could provide immediate protection while the individual plain text ports are still being phased out over the coming years (!)
So actually we are expecting that in 1-2 releases there will be no plain
text and no API ports exposed outside of the k8s cluster.


Would this level of protection still be considered to be "in ONAP"?
Please let me clarify. The tickets that you mentioned here are related
to NodePorts which means ports exposed outside of the Kubernetes Cluster
and this is what we are trying to get fixed.

To provide the minimal level of security and privacy all the
communication between end user and ONAP should happen via HTTPS.

My understanding of your email is that you are concern about component
to component communication which doesn't require exposing port outside
of the cluster but may be achieved using ClusterIP.

Obviously in the endo of the day we would like to secure also component
to component communication but it's a next step. First let's try to
achieve the very basic security of the external communication.

Should this be considered for El Alto release?
We are discussing deferring those issues that you mentioned to the El
Alto release but we need to remember that this has a certain consequences:

1. We require projects to clearly document this as a vulnerability in
their security release notes.

2. Projects should change their answer to all CII badging questions
related to secure communication from Met to Unmet which will influence
their CII badging score.

Best regards,
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Join onap-seccom@lists.onap.org to automatically receive all group messages.