From: email@example.com <firstname.lastname@example.org> On Behalf Of Krzysztof Opasiak via lists.onap.org
Sent: Monday, September 14, 2020 2:31 PM
To: TIMONEY, DAN <email@example.com>; Xin.Miao@fujitsu.com; firstname.lastname@example.org
Cc: DESBUREAUX Sylvain TGI/OLN <email@example.com>
Subject: Re: [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder SSL certificate
don't want to be a police officer but my personal opinion is that as long as sth is deployed as a part of onap it should follow the same rules, no matter if it is intended to be a design time or runtime.
If sth is not deployed as a part of ONAP (aka it's a testing tool, simulator, sample implementation etc) it means that:
1) It's disabled in onap-all override
2) It's disabled in gating (so there is no testing for it)
3) It has lowest priority in terms of OOM reviews
4) It cannot be used by other components (at least not enabled by default)
5) If there is no one interested in actively maintaining it it would be probably removed or put in "Maintenance mode"
Just to make sure that we are on the same page. It's not the policy approved by TSC at this point. That's what I and probably Sylvain (@Sylvain correct me if I'm wrong) would recommend.
On 14.09.2020 19:48, TIMONEY, DAN wrote:
This is true, but there is an important caveat ….
In a production environment, operations are often not supportive of
making changes to live service without having first performed those
same changes in a test environment. Our vision has always been that
directed graphs should be distributed via SDC so that there is some
infrastructure/governance in place to make sure that any changes
pushed to production have first been tested and certified.
Dgbuilder itself was intended more like a developer’s IDE. It
certainly can be used to update DGs in a production environment, and
one could easily see how one could institute methods and procedures to
discourage/prevent users from deploying DG changes in production that
they have not tested. But since that process relies on M&Ps, as
opposed to hard restrictions within dgbuilder itself, I try to be
careful to characterize dgbuilder as a development tool as opposed to a runtime tool.
If SECCOM sees value in our moving to a certInitializer approach, we
can certainly look at that – but we need to find someone from the
community to step up to do the associated work.
Well you already proposed to go with hardcoded certificate but actually using certInitializer is even simpler.
I may even offer some help for you. If you are able to provide me all the values that I need to pass to AAF init container (deployer id and all that stuff) and the location where DG builder expects to find the certificate I'm happy to do the certInitializer work for you. Please just bare in mind that you have to do this fast (preferable within one
day) as I need to finish this before my paternity leave which can start anytime at this stage;)
In case my child is faster than you I'm sure that Sylvain will be also happy to help you.
*From: *"Xin.Miao@fujitsu.com" <Xin.Miao@fujitsu.com>
*Date: *Monday, September 14, 2020 at 1:28 PM
*To: *"TIMONEY, DAN" <firstname.lastname@example.org>, "email@example.com"
*Subject: *RE: Waiver request for hard coded #ccsdk dgbuilder SSL
I believe the most advantage of DG is that user can modify and execute
them in ONAP at Run Time.
/Fujitsu Network Communication/
/2811 Telecom Drive/
/Richardson, TX 75081, USA/
*On Behalf Of *TIMONEY, DAN
*Sent:* Monday, September 14, 2020 8:56 AM
*Subject:* [Onap-seccom] Waiver request for hard coded #ccsdk
dgbuilder SSL certificate
I would like to request a security waiver for the CCSDK dgbuilder to
exempt use from migrating to certInitializer in Guilin. Instead, we
would continue to use self-signed SSL certificates, installed as
secrets via OOM and documented as hard coded certificates.
As background : the CCSDK directed graph builder (dgbuilder) is a
design-time tool that is used by developers to edit directed graphs.
Directed graphs are generally created at design time, submitted into
source control, and deployed as part of release installation. In OOM,
we do include dgbuilder helm charts so that testers will have the
ability to test “hot fixes” to directed graphs without having to wait
for a new release build. However, dgbuilder itself is not needed to
process any use case.
Thank you for your consideration,
Principal Technical Staff Member
ONAP Project Technical Lead : CCSDK and SDNC projects
Samsung R&D Institute Poland