Date   

Cancelled Event: [onap-seccom] Service Mesh Risk Analysis #cal-cancelled

onap-seccom@lists.onap.org Calendar <noreply@...>
 

Cancelled: [onap-seccom] Service Mesh Risk Analysis

This event has been cancelled.

When:
Friday, 1 May 2020
9:00am to 10:00am
(UTC-05:00) America/Chicago
Repeats: Weekly on Friday, through Saturday, 17 October 2020

Where:
SECCOM zoom

Organizer: "ZWARICO, AMY"

Description:
https://zoom.us/j/793296315 ( https://zoom.us/j/793296315 )


Cancelled Event: #seccom Subcommittee (UTC) #seccom #cal-cancelled

onap-seccom@lists.onap.org Calendar <noreply@...>
 

Cancelled: #seccom Subcommittee (UTC)

This event has been cancelled.

When:
Tuesday, 30 April 2019
1:00pm to 2:00pm
(UTC+00:00) UTC
Repeats: Weekly on Tuesday

Where:
https://zoom.us/j/793296315

Organizer: Pawel Pawlak pawel.pawlak3@...

Description:

https://zoom.us/j/793296315

One tap mobile

+16465588656,,793296315# US (New York)

+16699006833,,793296315# US (San Jose)

Dial by your location

+1 646 558 8656 US (New York)

+1 669 900 6833 US (San Jose)

877 369 0926 US Toll-free

855 880 1246 US Toll-free

Meeting ID: 793 296 315

Find your local number: https://zoom.us/u/aedFyNdWz8


due to vF2F event next week we cancel our Tuesday SECCOM meeting on October 13th

Pawel Pawlak
 

Hi,

As incoming week will be a great opportunity to meet virtually, we cancel our Tuesday SECCOM meeting on October 13th.

Please join our SECCOM session on October 14th at 1 PM UTC.

Best regards

 

Pawel Pawlak | Product Owner

Service Provider

ONAP SECCOM Chair

Mobile +48 501 501 030  

signature_1253180772

NGINX is now part of F5. See why we’re better together

 

 


Re: IMPORTANT! Actions resulting from Zoom Bombing.

Kenny Paul
 

All,

In my haste to get out communications one of the recommendations I made was the following:

 

>>>Everyone should immediately begin following the model used by many other OSS communities and change your Zoom name to First-name FAMILY-NAME (company) – capitalization of family name here is intentional to help our global community.  Example:  Hosty MCHOSTFACE (Fetzervalve)

 

While it is true that many communities do use this naming convention as the accepted model, as was pointed out to me by a member of the ONAP community impacted by my recommendation, it does not reflect the global culture in which we live, collaborate and work.

 

  • There are cultures in which FAMILY-NAME is used in a different context or construct.
  • There are cultures in which FAMILY-NAME does not exist.
  • There are cultures in which FAMILY-NAME does exist but is gender specific.
  • There are cultures in which FAMILY-NAME does exist, but is unused as it is associated with historic caste, class or gender systems. 
  • There are cultures in which the name a person uses is derived by them or derived for them.

 

Please be assured that my recommendation was not an effort to promote any sort of US-centric perspective of what a name should be.  Unfortunately even though I am well aware of the examples above, I just instinctively fell back on what I am most accustomed to rather than taking a moment to stop and analyze what I was actually saying.

 

The simplest approach to naming can and should be Your-preferred-name-string (company) 

For those of you who are individual contributors Your-preferred-name-string (Individual)  works fine.

 

If you have never see it before, this is worth a read: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

 

Thanks!

-kenny

 

From: kpaul@... <kpaul@...>
Sent: Monday, October 5, 2020 3:42 PM
To: onap-tsc@...; onap-discuss@...; onap-arc@...; onap-modelingsub@...; onap-requirements-sub@...; onap-seccom@...
Cc: Heather Kirksey <hkirksey@...>; Steve Ira <sira@...>
Subject: IMPORTANT! Actions resulting from Zoom Bombing.

 

On Friday night I had a very long email composed on this topic, but upon a re-read and after today’s PTL call I scrapped it all and started over. 

 

Thanks to those of you whom have sent me links to a myriad of Zoom security blog posts and articles from the interwebs.   The problem is that all of these recommendations on are focused on private  Zoom meetings and open source meetings are not private.   However on the PTL call we did brainstorm around the directly conflicting needs of keeping out bad actors while staying open, welcoming and inclusive. Here’s the logical order of operations.

 

Knowing who is joining a meeting – ACTION REQUIRED BY ALL COMMUNITY MEMBERS

Everyone should immediately begin following the model used by many other OSS communities and change your Zoom name to First-name FAMILY-NAME (company) – capitalization of family name here is intentional to help our global community.
Example:  Hosty MCHOSTFACE (Fetzervalve)

 

Enable Waiting room for all meetings

I’m actively resetting all of the accounts to waiting room now. Depending on the meeting this has the potential for a lot of administrative overhead and it is impractical to rely on the person hosting/sharing to manage this.  Waiting room utilization therefore requires responsible delegation on the part of the meeting owner.

  • The Host needs to grant co-host privileges to a couple other attendees to monitor the waiting room to act as the door monitor.  Also co-hosts are necessary to help identify and boot bombers.
  • As a community we would need to establish an unambiguous criteria to determine if  someone should be admitted to the call or not. I believe that criteria should be as simple as seeing the First-name FAMILY-NAME (company) in the waiting room.  If there is ever any question, the door monitor can always ask.

 

Hide meeting links and/or passwords from bots or a google search.

I have reset the permissions on the newly created https://lists.onap.org/g/onap-meetings list to be viewable only if logged into Groups.io. Also, I have created a wiki space for hosting meeting information that is similarly not anonymously viewable but can be seen by anyone that is logged into the wiki.  I am starting the process of moving all of our meeting pages to the new wiki space this afternoon. The community is responsible for changing any zoom meeting passwords and corresponding meeting invites.  

 

Permit authenticated Zoom accounts only 

I really don’t want to resort to this unless absolutely necessary as it will block any community members in the PRC that do not have a paid Zoom account.  If the above steps have been followed, (new meeting password, user naming conventions and the waiting room) and a meeting still gets bombed, then and only then do I believe we should revert to authenticated users only.

 

Thanks for your support and patience.

-kenny

 


Waiting room enabled for our SECCOM weekly meetings

Pawel Pawlak
 

Hello,

It is just to let you know that following the recommendation from Kenny, I have enabled waiting room feature for our SECCOM weekly meetings. Let’s see if it works for us or passwords shall be used for meetings.

Best regards

 

Pawel Pawlak | Product Owner

Service Provider

ONAP SECCOM Chair

Mobile +48 501 501 030  

signature_1253180772

NGINX is now part of F5. See why we’re better together

 

 


IMPORTANT! Actions resulting from Zoom Bombing.

Kenny Paul
 

On Friday night I had a very long email composed on this topic, but upon a re-read and after today’s PTL call I scrapped it all and started over. 

 

Thanks to those of you whom have sent me links to a myriad of Zoom security blog posts and articles from the interwebs.   The problem is that all of these recommendations on are focused on private  Zoom meetings and open source meetings are not private.   However on the PTL call we did brainstorm around the directly conflicting needs of keeping out bad actors while staying open, welcoming and inclusive. Here’s the logical order of operations.

 

Knowing who is joining a meeting – ACTION REQUIRED BY ALL COMMUNITY MEMBERS

Everyone should immediately begin following the model used by many other OSS communities and change your Zoom name to First-name FAMILY-NAME (company) – capitalization of family name here is intentional to help our global community.
Example:  Hosty MCHOSTFACE (Fetzervalve)

 

Enable Waiting room for all meetings

I’m actively resetting all of the accounts to waiting room now. Depending on the meeting this has the potential for a lot of administrative overhead and it is impractical to rely on the person hosting/sharing to manage this.  Waiting room utilization therefore requires responsible delegation on the part of the meeting owner.

  • The Host needs to grant co-host privileges to a couple other attendees to monitor the waiting room to act as the door monitor.  Also co-hosts are necessary to help identify and boot bombers.
  • As a community we would need to establish an unambiguous criteria to determine if  someone should be admitted to the call or not. I believe that criteria should be as simple as seeing the First-name FAMILY-NAME (company) in the waiting room.  If there is ever any question, the door monitor can always ask.

Hide meeting links and/or passwords from bots or a google search.

I have reset the permissions on the newly created https://lists.onap.org/g/onap-meetings list to be viewable only if logged into Groups.io. Also, I have created a wiki space for hosting meeting information that is similarly not anonymously viewable but can be seen by anyone that is logged into the wiki.  I am starting the process of moving all of our meeting pages to the new wiki space this afternoon. The community is responsible for changing any zoom meeting passwords and corresponding meeting invites.  

 

Permit authenticated Zoom accounts only 

I really don’t want to resort to this unless absolutely necessary as it will block any community members in the PRC that do not have a paid Zoom account.  If the above steps have been followed, (new meeting password, user naming conventions and the waiting room) and a meeting still gets bombed, then and only then do I believe we should revert to authenticated users only.

 

Thanks for your support and patience.

-kenny

 


ONAP Calendar Migration

Kenny Paul
 

Apologies for the overly broad distribution for this, but it is important for everyone to be aware of the ONAP calendar migration status as action on your part IS required.

 

The new single calendar management group, https://lists.onap.org/g/onap-meetings has been created and is now open for community subscription

All members of the community should subscribe to this new group.

 

Calendar migration timeline:

  • Week of Sept 21: Initial data port into new calendar group from original source calendar groups
  • Week of Sept. 28:  Entries on new list reviewed / edited by meeting owners
  • Week of Oct. 02: The ONAP community should begin using the new group for calendar management
  • Oct. 09: All group specific group calendars and the wiki calendar will be deleted and disabled

 

NOTE: All team meetings during the LFN Technical Event on Oct 13-15 have already been removed from the new calendar.

 

Please see the sticky message here for more details on how to best transition yourself to the new calendar model. https://lists.onap.org/g/onap-meetings/message/9

 

 

Thanks!

-kenny

 


No SECCOM meeting this week

Pawel Pawlak
 

As you know this weeks there is ONES NA event and our SECCOM meeting was decided to be cancelled this week.

Hope to hear you on October 6th!

Best regards

 

Pawel Pawlak | Product Owner

Service Provider

ONAP SECCOM Chair

Mobile +48 501 501 030  

signature_1253180772

NGINX is now part of F5. See why we’re better together

 

 


Re: Waiver request for hard coded #ccsdk dgbuilder SSL certificate #ccsdk

Catherine LEFEVRE
 

Well done Dan !

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On Behalf Of TIMONEY, DAN
Sent: Thursday, September 17, 2020 9:05 PM
To: Krzysztof Opasiak <k.opasiak@...>; ZWARICO, AMY <az9121@...>; Xin.Miao@...; onap-seccom@...
Cc: DESBUREAUX Sylvain TGI/OLN <sylvain.desbureaux@...>
Subject: Re: [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder SSL certificate

*** Security Advisory: This Message Originated Outside of AT&T ***.
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.

All,

FYI - I was able to get certInitializer working for dgbuilder. Here's the code review with that change:

https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.onap.org_r_c_oom_-2B_112613&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=ZglJ8LOeAfevY7wWaSximhFMAzXaMdza5QYCg-DW6SU&m=tRJfDdIRR9pUlwL6kE9Sb2fdjPlpxkaLu63nfRcQJok&s=uMDahqy7Z_31VfrxZk2DGieKWL9g69LK2woH6hE5HEQ&e=

I tested this locally in my WindRiver environment and worked okay for me. We no longer need to request a waiver.

Thanks!
Dan


On 9/15/20, 10:10 AM, "TIMONEY, DAN" <dt5972@...> wrote:

Krzysztof,

Thank you very much in advance for your help!

Here's the answers to your questions below:

1) AAF specific data:

aafDeployFqi: deployer@...
aafDeployPass: demo123456!
fqdn: dgbuilder
fqi: dgbuilder@...
public_fqdn: dgbuilder.onap.org
app_ns: org.osaaf.aaf

2) Path where dgbuilder expects certs:
Private key path : /opt/onap/ccsdk/dgbuilder/certs/node-key.pem
Certificate path : /opt/onap/ccsdk/dgbuilder/certs/node-cert.pem

Note: for the first section, I just tried to model based on what you did in the sdnc helm charts.

Thanks again,
Dan

On 9/14/20, 6:31 PM, "Krzysztof Opasiak" <k.opasiak@...> wrote:



On 15.09.2020 00:09, TIMONEY, DAN wrote:
> Krzysztof,
>
> This is primarily a resource issue. There are really 2 areas we'd need to address:
>
> 1) The certInitializer set up , for the case where aafEnabled is true.
> 2) An alternate solution if aafEnabled is false. My preference for that alternate would be to use our self-signed cert in that case (so that we still have the benefits of https), but if we have to fall back to http, that's feasible (it's just a configuration change).

From OOM perspective:
- falling back to HTTP when aaf is disabled is perfectly fine
- If apart from that you would like to have a fallback with custom cert
in OOM repo it's also acceptable but it means extra work for you

>
> If you can help with the first, I can handle the second - in which case, I can withdraw this waiver request.

Sure I can help with that. I just need two things from you:

1) AAF specific data:

aafDeployFqi:
aafDeployPass:
fqdn:
fqi:
public_fqdn:
app_ns: org.osaaf.aaf

2) Path where dgbuilder expects certs

>
> Thanks,
> Dan
>
>
> On 9/14/20, 5:44 PM, "Krzysztof Opasiak" <k.opasiak@...> wrote:
>
>
>
> On 14.09.2020 23:36, TIMONEY, DAN wrote:
> > Amy, Krzysztof,
> >
> > I apologize - I think I was being unclear. I'm not pushing back on this as a valid requirement. What I'm really asking for is a waiver specifically for Guilin.
>
> I believe that in SECCOM we are all thinking about waivers as a kind of
> *exception* process that needs a valid (preferably) technical reason or
> (less preferably) resource reason.is
>
> So:
>
> 1) Do you have a technical reason to request this waiver?
>
> 2) Are you under high resource pressure that prevents you from
> fulfilling this requirement? Can this issue be solved if I help you with
> the certInitializer part?
>
> 3) Do you have any other reason to request a waiver for this requirement?
>
> >
> > Dan
> >
> > On 9/14/20, 4:32 PM, "ZWARICO, AMY" <az9121@...> wrote:
> >
> > I agree with Krzysztof. If it cannot be accomplished in this release, that's one thing, but long term, it should use the same certificate management processes as the rest of ONAP.
> >
> > -----Original Message-----
> > From: onap-seccom@... <onap-seccom@...> On Behalf Of Krzysztof Opasiak via lists.onap.org
> > Sent: Monday, September 14, 2020 2:31 PM
> > To: TIMONEY, DAN <dt5972@...>; Xin.Miao@...; onap-seccom@...
> > Cc: DESBUREAUX Sylvain TGI/OLN <sylvain.desbureaux@...>
> > Subject: Re: [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder SSL certificate
> >
> > Hi Dan,
> >
> > 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:
> > > Xin,
> > >
> > > 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.
> >
> > >
> > > Dan
> > >
> > > *From: *"Xin.Miao@..." <Xin.Miao@...>
> > > *Date: *Monday, September 14, 2020 at 1:28 PM
> > > *To: *"TIMONEY, DAN" <dt5972@...>, "onap-seccom@..."
> > > <onap-seccom@...>
> > > *Subject: *RE: Waiver request for hard coded #ccsdk dgbuilder SSL
> > > certificate
> > >
> > > I believe the most advantage of DG is that user can modify and execute
> > > them in ONAP at Run Time.
> > >
> > > Thanks,
> > >
> > > /Xin Miao/
> > >
> > > /Solution Engineering/
> > >
> > > /Fujitsu Network Communication/
> > >
> > > /(W)972-479-2263 (M)469-268-5226/
> > >
> > > /2811 Telecom Drive/
> > >
> > > /Richardson, TX 75081, USA/
> > >
> > > *From:*onap-seccom@... [mailto:onap-seccom@...]
> > > *On Behalf Of *TIMONEY, DAN
> > > *Sent:* Monday, September 14, 2020 8:56 AM
> > > *To:* onap-seccom@...
> > > *Subject:* [Onap-seccom] Waiver request for hard coded #ccsdk
> > > dgbuilder SSL certificate
> > >
> > > SECCOM:
> > >
> > > 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,
> > >
> > > Dan
> > >
> > > --
> > >
> > > Dan Timoney
> > >
> > > @djtimoney <mailto:@djtimoney>
> > >
> > > Principal Technical Staff Member
> > >
> > > ONAP Project Technical Lead : CCSDK and SDNC projects
> > >
> > >
> >
> > --
> > Krzysztof Opasiak
> > Samsung R&D Institute Poland
> > Samsung Electronics
> >
> >
> >
> >
>
> --
> Krzysztof Opasiak
> Samsung R&D Institute Poland
> Samsung Electronics
>

--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics


Re: Waiver request for hard coded #ccsdk dgbuilder SSL certificate #ccsdk

Dan Timoney
 

All,

FYI - I was able to get certInitializer working for dgbuilder. Here's the code review with that change:

https://gerrit.onap.org/r/c/oom/+/112613

I tested this locally in my WindRiver environment and worked okay for me. We no longer need to request a waiver.

Thanks!
Dan


On 9/15/20, 10:10 AM, "TIMONEY, DAN" <dt5972@...> wrote:

Krzysztof,

Thank you very much in advance for your help!

Here's the answers to your questions below:

1) AAF specific data:

aafDeployFqi: deployer@...
aafDeployPass: demo123456!
fqdn: dgbuilder
fqi: dgbuilder@...
public_fqdn: dgbuilder.onap.org
app_ns: org.osaaf.aaf

2) Path where dgbuilder expects certs:
Private key path : /opt/onap/ccsdk/dgbuilder/certs/node-key.pem
Certificate path : /opt/onap/ccsdk/dgbuilder/certs/node-cert.pem

Note: for the first section, I just tried to model based on what you did in the sdnc helm charts.

Thanks again,
Dan

On 9/14/20, 6:31 PM, "Krzysztof Opasiak" <k.opasiak@...> wrote:



On 15.09.2020 00:09, TIMONEY, DAN wrote:
> Krzysztof,
>
> This is primarily a resource issue. There are really 2 areas we'd need to address:
>
> 1) The certInitializer set up , for the case where aafEnabled is true.
> 2) An alternate solution if aafEnabled is false. My preference for that alternate would be to use our self-signed cert in that case (so that we still have the benefits of https), but if we have to fall back to http, that's feasible (it's just a configuration change).

From OOM perspective:
- falling back to HTTP when aaf is disabled is perfectly fine
- If apart from that you would like to have a fallback with custom cert
in OOM repo it's also acceptable but it means extra work for you

>
> If you can help with the first, I can handle the second - in which case, I can withdraw this waiver request.

Sure I can help with that. I just need two things from you:

1) AAF specific data:

aafDeployFqi:
aafDeployPass:
fqdn:
fqi:
public_fqdn:
app_ns: org.osaaf.aaf

2) Path where dgbuilder expects certs

>
> Thanks,
> Dan
>
>
> On 9/14/20, 5:44 PM, "Krzysztof Opasiak" <k.opasiak@...> wrote:
>
>
>
> On 14.09.2020 23:36, TIMONEY, DAN wrote:
> > Amy, Krzysztof,
> >
> > I apologize - I think I was being unclear. I'm not pushing back on this as a valid requirement. What I'm really asking for is a waiver specifically for Guilin.
>
> I believe that in SECCOM we are all thinking about waivers as a kind of
> *exception* process that needs a valid (preferably) technical reason or
> (less preferably) resource reason.is
>
> So:
>
> 1) Do you have a technical reason to request this waiver?
>
> 2) Are you under high resource pressure that prevents you from
> fulfilling this requirement? Can this issue be solved if I help you with
> the certInitializer part?
>
> 3) Do you have any other reason to request a waiver for this requirement?
>
> >
> > Dan
> >
> > On 9/14/20, 4:32 PM, "ZWARICO, AMY" <az9121@...> wrote:
> >
> > I agree with Krzysztof. If it cannot be accomplished in this release, that's one thing, but long term, it should use the same certificate management processes as the rest of ONAP.
> >
> > -----Original Message-----
> > From: onap-seccom@... <onap-seccom@...> On Behalf Of Krzysztof Opasiak via lists.onap.org
> > Sent: Monday, September 14, 2020 2:31 PM
> > To: TIMONEY, DAN <dt5972@...>; Xin.Miao@...; onap-seccom@...
> > Cc: DESBUREAUX Sylvain TGI/OLN <sylvain.desbureaux@...>
> > Subject: Re: [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder SSL certificate
> >
> > Hi Dan,
> >
> > 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:
> > > Xin,
> > >
> > > 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.
> >
> > >
> > > Dan
> > >
> > > *From: *"Xin.Miao@..." <Xin.Miao@...>
> > > *Date: *Monday, September 14, 2020 at 1:28 PM
> > > *To: *"TIMONEY, DAN" <dt5972@...>, "onap-seccom@..."
> > > <onap-seccom@...>
> > > *Subject: *RE: Waiver request for hard coded #ccsdk dgbuilder SSL
> > > certificate
> > >
> > > I believe the most advantage of DG is that user can modify and execute
> > > them in ONAP at Run Time.
> > >
> > > Thanks,
> > >
> > > /Xin Miao/
> > >
> > > /Solution Engineering/
> > >
> > > /Fujitsu Network Communication/
> > >
> > > /(W)972-479-2263 (M)469-268-5226/
> > >
> > > /2811 Telecom Drive/
> > >
> > > /Richardson, TX 75081, USA/
> > >
> > > *From:*onap-seccom@... [mailto:onap-seccom@...]
> > > *On Behalf Of *TIMONEY, DAN
> > > *Sent:* Monday, September 14, 2020 8:56 AM
> > > *To:* onap-seccom@...
> > > *Subject:* [Onap-seccom] Waiver request for hard coded #ccsdk
> > > dgbuilder SSL certificate
> > >
> > > SECCOM:
> > >
> > > 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,
> > >
> > > Dan
> > >
> > > --
> > >
> > > Dan Timoney
> > >
> > > @djtimoney <mailto:@djtimoney>
> > >
> > > Principal Technical Staff Member
> > >
> > > ONAP Project Technical Lead : CCSDK and SDNC projects
> > >
> > >
> >
> > --
> > Krzysztof Opasiak
> > Samsung R&D Institute Poland
> > Samsung Electronics
> >
> >
> >
> >
>
> --
> Krzysztof Opasiak
> Samsung R&D Institute Poland
> Samsung Electronics
>

--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics


Re: Waiver request for hard coded #ccsdk dgbuilder SSL certificate #ccsdk

Dan Timoney
 

Krzysztof,

Thank you very much in advance for your help!

Here's the answers to your questions below:

1) AAF specific data:

aafDeployFqi: deployer@...
aafDeployPass: demo123456!
fqdn: dgbuilder
fqi: dgbuilder@...
public_fqdn: dgbuilder.onap.org
app_ns: org.osaaf.aaf

2) Path where dgbuilder expects certs:
Private key path : /opt/onap/ccsdk/dgbuilder/certs/node-key.pem
Certificate path : /opt/onap/ccsdk/dgbuilder/certs/node-cert.pem

Note: for the first section, I just tried to model based on what you did in the sdnc helm charts.

Thanks again,
Dan

On 9/14/20, 6:31 PM, "Krzysztof Opasiak" <k.opasiak@...> wrote:



On 15.09.2020 00:09, TIMONEY, DAN wrote:
> Krzysztof,
>
> This is primarily a resource issue. There are really 2 areas we'd need to address:
>
> 1) The certInitializer set up , for the case where aafEnabled is true.
> 2) An alternate solution if aafEnabled is false. My preference for that alternate would be to use our self-signed cert in that case (so that we still have the benefits of https), but if we have to fall back to http, that's feasible (it's just a configuration change).

From OOM perspective:
- falling back to HTTP when aaf is disabled is perfectly fine
- If apart from that you would like to have a fallback with custom cert
in OOM repo it's also acceptable but it means extra work for you

>
> If you can help with the first, I can handle the second - in which case, I can withdraw this waiver request.

Sure I can help with that. I just need two things from you:

1) AAF specific data:

aafDeployFqi:
aafDeployPass:
fqdn:
fqi:
public_fqdn:
app_ns: org.osaaf.aaf

2) Path where dgbuilder expects certs

>
> Thanks,
> Dan
>
>
> On 9/14/20, 5:44 PM, "Krzysztof Opasiak" <k.opasiak@...> wrote:
>
>
>
> On 14.09.2020 23:36, TIMONEY, DAN wrote:
> > Amy, Krzysztof,
> >
> > I apologize - I think I was being unclear. I'm not pushing back on this as a valid requirement. What I'm really asking for is a waiver specifically for Guilin.
>
> I believe that in SECCOM we are all thinking about waivers as a kind of
> *exception* process that needs a valid (preferably) technical reason or
> (less preferably) resource reason.is
>
> So:
>
> 1) Do you have a technical reason to request this waiver?
>
> 2) Are you under high resource pressure that prevents you from
> fulfilling this requirement? Can this issue be solved if I help you with
> the certInitializer part?
>
> 3) Do you have any other reason to request a waiver for this requirement?
>
> >
> > Dan
> >
> > On 9/14/20, 4:32 PM, "ZWARICO, AMY" <az9121@...> wrote:
> >
> > I agree with Krzysztof. If it cannot be accomplished in this release, that's one thing, but long term, it should use the same certificate management processes as the rest of ONAP.
> >
> > -----Original Message-----
> > From: onap-seccom@... <onap-seccom@...> On Behalf Of Krzysztof Opasiak via lists.onap.org
> > Sent: Monday, September 14, 2020 2:31 PM
> > To: TIMONEY, DAN <dt5972@...>; Xin.Miao@...; onap-seccom@...
> > Cc: DESBUREAUX Sylvain TGI/OLN <sylvain.desbureaux@...>
> > Subject: Re: [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder SSL certificate
> >
> > Hi Dan,
> >
> > 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:
> > > Xin,
> > >
> > > 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.
> >
> > >
> > > Dan
> > >
> > > *From: *"Xin.Miao@..." <Xin.Miao@...>
> > > *Date: *Monday, September 14, 2020 at 1:28 PM
> > > *To: *"TIMONEY, DAN" <dt5972@...>, "onap-seccom@..."
> > > <onap-seccom@...>
> > > *Subject: *RE: Waiver request for hard coded #ccsdk dgbuilder SSL
> > > certificate
> > >
> > > I believe the most advantage of DG is that user can modify and execute
> > > them in ONAP at Run Time.
> > >
> > > Thanks,
> > >
> > > /Xin Miao/
> > >
> > > /Solution Engineering/
> > >
> > > /Fujitsu Network Communication/
> > >
> > > /(W)972-479-2263 (M)469-268-5226/
> > >
> > > /2811 Telecom Drive/
> > >
> > > /Richardson, TX 75081, USA/
> > >
> > > *From:*onap-seccom@... [mailto:onap-seccom@...]
> > > *On Behalf Of *TIMONEY, DAN
> > > *Sent:* Monday, September 14, 2020 8:56 AM
> > > *To:* onap-seccom@...
> > > *Subject:* [Onap-seccom] Waiver request for hard coded #ccsdk
> > > dgbuilder SSL certificate
> > >
> > > SECCOM:
> > >
> > > 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,
> > >
> > > Dan
> > >
> > > --
> > >
> > > Dan Timoney
> > >
> > > @djtimoney <mailto:@djtimoney>
> > >
> > > Principal Technical Staff Member
> > >
> > > ONAP Project Technical Lead : CCSDK and SDNC projects
> > >
> > >
> >
> > --
> > Krzysztof Opasiak
> > Samsung R&D Institute Poland
> > Samsung Electronics
> >
> >
> >
> >
>
> --
> Krzysztof Opasiak
> Samsung R&D Institute Poland
> Samsung Electronics
>

--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics


Re: Waiver request for hard coded #ccsdk dgbuilder SSL certificate #ccsdk

Krzysztof Opasiak
 

On 15.09.2020 00:09, TIMONEY, DAN wrote:
Krzysztof,

This is primarily a resource issue. There are really 2 areas we'd need to address:

1) The certInitializer set up , for the case where aafEnabled is true.
2) An alternate solution if aafEnabled is false. My preference for that alternate would be to use our self-signed cert in that case (so that we still have the benefits of https), but if we have to fall back to http, that's feasible (it's just a configuration change).
From OOM perspective:
- falling back to HTTP when aaf is disabled is perfectly fine
- If apart from that you would like to have a fallback with custom cert
in OOM repo it's also acceptable but it means extra work for you


If you can help with the first, I can handle the second - in which case, I can withdraw this waiver request.
Sure I can help with that. I just need two things from you:

1) AAF specific data:

aafDeployFqi:
aafDeployPass:
fqdn:
fqi:
public_fqdn:
app_ns: org.osaaf.aaf

2) Path where dgbuilder expects certs


Thanks,
Dan


On 9/14/20, 5:44 PM, "Krzysztof Opasiak" <k.opasiak@...> wrote:



On 14.09.2020 23:36, TIMONEY, DAN wrote:
> Amy, Krzysztof,
>
> I apologize - I think I was being unclear. I'm not pushing back on this as a valid requirement. What I'm really asking for is a waiver specifically for Guilin.

I believe that in SECCOM we are all thinking about waivers as a kind of
*exception* process that needs a valid (preferably) technical reason or
(less preferably) resource reason.is

So:

1) Do you have a technical reason to request this waiver?

2) Are you under high resource pressure that prevents you from
fulfilling this requirement? Can this issue be solved if I help you with
the certInitializer part?

3) Do you have any other reason to request a waiver for this requirement?

>
> Dan
>
> On 9/14/20, 4:32 PM, "ZWARICO, AMY" <az9121@...> wrote:
>
> I agree with Krzysztof. If it cannot be accomplished in this release, that's one thing, but long term, it should use the same certificate management processes as the rest of ONAP.
>
> -----Original Message-----
> From: onap-seccom@... <onap-seccom@...> On Behalf Of Krzysztof Opasiak via lists.onap.org
> Sent: Monday, September 14, 2020 2:31 PM
> To: TIMONEY, DAN <dt5972@...>; Xin.Miao@...; onap-seccom@...
> Cc: DESBUREAUX Sylvain TGI/OLN <sylvain.desbureaux@...>
> Subject: Re: [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder SSL certificate
>
> Hi Dan,
>
> 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:
> > Xin,
> >
> > 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.
>
> >
> > Dan
> >
> > *From: *"Xin.Miao@..." <Xin.Miao@...>
> > *Date: *Monday, September 14, 2020 at 1:28 PM
> > *To: *"TIMONEY, DAN" <dt5972@...>, "onap-seccom@..."
> > <onap-seccom@...>
> > *Subject: *RE: Waiver request for hard coded #ccsdk dgbuilder SSL
> > certificate
> >
> > I believe the most advantage of DG is that user can modify and execute
> > them in ONAP at Run Time.
> >
> > Thanks,
> >
> > /Xin Miao/
> >
> > /Solution Engineering/
> >
> > /Fujitsu Network Communication/
> >
> > /(W)972-479-2263 (M)469-268-5226/
> >
> > /2811 Telecom Drive/
> >
> > /Richardson, TX 75081, USA/
> >
> > *From:*onap-seccom@... [mailto:onap-seccom@...]
> > *On Behalf Of *TIMONEY, DAN
> > *Sent:* Monday, September 14, 2020 8:56 AM
> > *To:* onap-seccom@...
> > *Subject:* [Onap-seccom] Waiver request for hard coded #ccsdk
> > dgbuilder SSL certificate
> >
> > SECCOM:
> >
> > 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,
> >
> > Dan
> >
> > --
> >
> > Dan Timoney
> >
> > @djtimoney <mailto:@djtimoney>
> >
> > Principal Technical Staff Member
> >
> > ONAP Project Technical Lead : CCSDK and SDNC projects
> >
> >
>
> --
> Krzysztof Opasiak
> Samsung R&D Institute Poland
> Samsung Electronics
>
>
>
>

--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics
--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics


Re: Waiver request for hard coded #ccsdk dgbuilder SSL certificate #ccsdk

Dan Timoney
 

Krzysztof,

This is primarily a resource issue. There are really 2 areas we'd need to address:

1) The certInitializer set up , for the case where aafEnabled is true.
2) An alternate solution if aafEnabled is false. My preference for that alternate would be to use our self-signed cert in that case (so that we still have the benefits of https), but if we have to fall back to http, that's feasible (it's just a configuration change).

If you can help with the first, I can handle the second - in which case, I can withdraw this waiver request.

Thanks,
Dan


On 9/14/20, 5:44 PM, "Krzysztof Opasiak" <k.opasiak@...> wrote:



On 14.09.2020 23:36, TIMONEY, DAN wrote:
> Amy, Krzysztof,
>
> I apologize - I think I was being unclear. I'm not pushing back on this as a valid requirement. What I'm really asking for is a waiver specifically for Guilin.

I believe that in SECCOM we are all thinking about waivers as a kind of
*exception* process that needs a valid (preferably) technical reason or
(less preferably) resource reason.is

So:

1) Do you have a technical reason to request this waiver?

2) Are you under high resource pressure that prevents you from
fulfilling this requirement? Can this issue be solved if I help you with
the certInitializer part?

3) Do you have any other reason to request a waiver for this requirement?

>
> Dan
>
> On 9/14/20, 4:32 PM, "ZWARICO, AMY" <az9121@...> wrote:
>
> I agree with Krzysztof. If it cannot be accomplished in this release, that's one thing, but long term, it should use the same certificate management processes as the rest of ONAP.
>
> -----Original Message-----
> From: onap-seccom@... <onap-seccom@...> On Behalf Of Krzysztof Opasiak via lists.onap.org
> Sent: Monday, September 14, 2020 2:31 PM
> To: TIMONEY, DAN <dt5972@...>; Xin.Miao@...; onap-seccom@...
> Cc: DESBUREAUX Sylvain TGI/OLN <sylvain.desbureaux@...>
> Subject: Re: [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder SSL certificate
>
> Hi Dan,
>
> 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:
> > Xin,
> >
> > 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.
>
> >
> > Dan
> >
> > *From: *"Xin.Miao@..." <Xin.Miao@...>
> > *Date: *Monday, September 14, 2020 at 1:28 PM
> > *To: *"TIMONEY, DAN" <dt5972@...>, "onap-seccom@..."
> > <onap-seccom@...>
> > *Subject: *RE: Waiver request for hard coded #ccsdk dgbuilder SSL
> > certificate
> >
> > I believe the most advantage of DG is that user can modify and execute
> > them in ONAP at Run Time.
> >
> > Thanks,
> >
> > /Xin Miao/
> >
> > /Solution Engineering/
> >
> > /Fujitsu Network Communication/
> >
> > /(W)972-479-2263 (M)469-268-5226/
> >
> > /2811 Telecom Drive/
> >
> > /Richardson, TX 75081, USA/
> >
> > *From:*onap-seccom@... [mailto:onap-seccom@...]
> > *On Behalf Of *TIMONEY, DAN
> > *Sent:* Monday, September 14, 2020 8:56 AM
> > *To:* onap-seccom@...
> > *Subject:* [Onap-seccom] Waiver request for hard coded #ccsdk
> > dgbuilder SSL certificate
> >
> > SECCOM:
> >
> > 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,
> >
> > Dan
> >
> > --
> >
> > Dan Timoney
> >
> > @djtimoney <mailto:@djtimoney>
> >
> > Principal Technical Staff Member
> >
> > ONAP Project Technical Lead : CCSDK and SDNC projects
> >
> >
>
> --
> Krzysztof Opasiak
> Samsung R&D Institute Poland
> Samsung Electronics
>
>
>
>

--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics


Re: Waiver request for hard coded #ccsdk dgbuilder SSL certificate #ccsdk

Krzysztof Opasiak
 

On 14.09.2020 23:36, TIMONEY, DAN wrote:
Amy, Krzysztof,

I apologize - I think I was being unclear. I'm not pushing back on this as a valid requirement. What I'm really asking for is a waiver specifically for Guilin.
I believe that in SECCOM we are all thinking about waivers as a kind of
*exception* process that needs a valid (preferably) technical reason or
(less preferably) resource reason.

So:

1) Do you have a technical reason to request this waiver?

2) Are you under high resource pressure that prevents you from
fulfilling this requirement? Can this issue be solved if I help you with
the certInitializer part?

3) Do you have any other reason to request a waiver for this requirement?


Dan

On 9/14/20, 4:32 PM, "ZWARICO, AMY" <az9121@...> wrote:

I agree with Krzysztof. If it cannot be accomplished in this release, that's one thing, but long term, it should use the same certificate management processes as the rest of ONAP.

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On Behalf Of Krzysztof Opasiak via lists.onap.org
Sent: Monday, September 14, 2020 2:31 PM
To: TIMONEY, DAN <dt5972@...>; Xin.Miao@...; onap-seccom@...
Cc: DESBUREAUX Sylvain TGI/OLN <sylvain.desbureaux@...>
Subject: Re: [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder SSL certificate

Hi Dan,

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:
> Xin,
>
> 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.

>
> Dan
>
> *From: *"Xin.Miao@..." <Xin.Miao@...>
> *Date: *Monday, September 14, 2020 at 1:28 PM
> *To: *"TIMONEY, DAN" <dt5972@...>, "onap-seccom@..."
> <onap-seccom@...>
> *Subject: *RE: Waiver request for hard coded #ccsdk dgbuilder SSL
> certificate
>
> I believe the most advantage of DG is that user can modify and execute
> them in ONAP at Run Time.
>
> Thanks,
>
> /Xin Miao/
>
> /Solution Engineering/
>
> /Fujitsu Network Communication/
>
> /(W)972-479-2263 (M)469-268-5226/
>
> /2811 Telecom Drive/
>
> /Richardson, TX 75081, USA/
>
> *From:*onap-seccom@... [mailto:onap-seccom@...]
> *On Behalf Of *TIMONEY, DAN
> *Sent:* Monday, September 14, 2020 8:56 AM
> *To:* onap-seccom@...
> *Subject:* [Onap-seccom] Waiver request for hard coded #ccsdk
> dgbuilder SSL certificate
>
> SECCOM:
>
> 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,
>
> Dan
>
> --
>
> Dan Timoney
>
> @djtimoney <mailto:@djtimoney>
>
> Principal Technical Staff Member
>
> ONAP Project Technical Lead : CCSDK and SDNC projects
>
>

--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics



--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics


Re: Waiver request for hard coded #ccsdk dgbuilder SSL certificate #ccsdk

Dan Timoney
 

Amy, Krzysztof,

I apologize - I think I was being unclear. I'm not pushing back on this as a valid requirement. What I'm really asking for is a waiver specifically for Guilin.

Dan

On 9/14/20, 4:32 PM, "ZWARICO, AMY" <az9121@...> wrote:

I agree with Krzysztof. If it cannot be accomplished in this release, that's one thing, but long term, it should use the same certificate management processes as the rest of ONAP.

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On Behalf Of Krzysztof Opasiak via lists.onap.org
Sent: Monday, September 14, 2020 2:31 PM
To: TIMONEY, DAN <dt5972@...>; Xin.Miao@...; onap-seccom@...
Cc: DESBUREAUX Sylvain TGI/OLN <sylvain.desbureaux@...>
Subject: Re: [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder SSL certificate

Hi Dan,

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:
> Xin,
>
> 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.

>
> Dan
>
> *From: *"Xin.Miao@..." <Xin.Miao@...>
> *Date: *Monday, September 14, 2020 at 1:28 PM
> *To: *"TIMONEY, DAN" <dt5972@...>, "onap-seccom@..."
> <onap-seccom@...>
> *Subject: *RE: Waiver request for hard coded #ccsdk dgbuilder SSL
> certificate
>
> I believe the most advantage of DG is that user can modify and execute
> them in ONAP at Run Time.
>
> Thanks,
>
> /Xin Miao/
>
> /Solution Engineering/
>
> /Fujitsu Network Communication/
>
> /(W)972-479-2263 (M)469-268-5226/
>
> /2811 Telecom Drive/
>
> /Richardson, TX 75081, USA/
>
> *From:*onap-seccom@... [mailto:onap-seccom@...]
> *On Behalf Of *TIMONEY, DAN
> *Sent:* Monday, September 14, 2020 8:56 AM
> *To:* onap-seccom@...
> *Subject:* [Onap-seccom] Waiver request for hard coded #ccsdk
> dgbuilder SSL certificate
>
> SECCOM:
>
> 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,
>
> Dan
>
> --
>
> Dan Timoney
>
> @djtimoney <mailto:@djtimoney>
>
> Principal Technical Staff Member
>
> ONAP Project Technical Lead : CCSDK and SDNC projects
>
>

--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics


Re: Waiver request for hard coded #ccsdk dgbuilder SSL certificate #ccsdk

Amy Zwarico
 

I agree with Krzysztof. If it cannot be accomplished in this release, that's one thing, but long term, it should use the same certificate management processes as the rest of ONAP.

-----Original Message-----
From: onap-seccom@... <onap-seccom@...> On Behalf Of Krzysztof Opasiak via lists.onap.org
Sent: Monday, September 14, 2020 2:31 PM
To: TIMONEY, DAN <dt5972@...>; Xin.Miao@...; onap-seccom@...
Cc: DESBUREAUX Sylvain TGI/OLN <sylvain.desbureaux@...>
Subject: Re: [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder SSL certificate

Hi Dan,

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:
Xin,

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.


Dan

*From: *"Xin.Miao@..." <Xin.Miao@...>
*Date: *Monday, September 14, 2020 at 1:28 PM
*To: *"TIMONEY, DAN" <dt5972@...>, "onap-seccom@..."
<onap-seccom@...>
*Subject: *RE: Waiver request for hard coded #ccsdk dgbuilder SSL
certificate

I believe the most advantage of DG is that user can modify and execute
them in ONAP at Run Time.

Thanks,

/Xin Miao/

/Solution Engineering/

/Fujitsu Network Communication/

/(W)972-479-2263 (M)469-268-5226/

/2811 Telecom Drive/

/Richardson, TX 75081, USA/

*From:*onap-seccom@... [mailto:onap-seccom@...]
*On Behalf Of *TIMONEY, DAN
*Sent:* Monday, September 14, 2020 8:56 AM
*To:* onap-seccom@...
*Subject:* [Onap-seccom] Waiver request for hard coded #ccsdk
dgbuilder SSL certificate

SECCOM:

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,

Dan

--

Dan Timoney

@djtimoney <mailto:@djtimoney>

Principal Technical Staff Member

ONAP Project Technical Lead : CCSDK and SDNC projects

--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics


Re: Waiver request for hard coded #ccsdk dgbuilder SSL certificate #ccsdk

Krzysztof Opasiak
 

Hi Dan,

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:
Xin,

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.


Dan

*From: *"Xin.Miao@..." <Xin.Miao@...>
*Date: *Monday, September 14, 2020 at 1:28 PM
*To: *"TIMONEY, DAN" <dt5972@...>, "onap-seccom@..."
<onap-seccom@...>
*Subject: *RE: Waiver request for hard coded #ccsdk dgbuilder SSL
certificate

I believe the most advantage of DG is that user can modify and execute
them in ONAP at Run Time.

Thanks,

/Xin Miao/

/Solution Engineering/

/Fujitsu Network Communication/

/(W)972-479-2263 (M)469-268-5226/

/2811 Telecom Drive/

/Richardson, TX 75081, USA/

*From:*onap-seccom@... [mailto:onap-seccom@...]
*On Behalf Of *TIMONEY, DAN
*Sent:* Monday, September 14, 2020 8:56 AM
*To:* onap-seccom@...
*Subject:* [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder
SSL certificate

SECCOM:

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,

Dan

--

Dan Timoney

@djtimoney <mailto:@djtimoney>

Principal Technical Staff Member

ONAP Project Technical Lead : CCSDK and SDNC projects

--
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics


Re: Waiver request for hard coded #ccsdk dgbuilder SSL certificate #ccsdk

Xin.Miao@fujitsu.com
 

Sure. Completely understand your concerns and agree with you. Thank you very much for your explanation!

Xin


From: TIMONEY, DAN <dt5972@...>
Sent: Monday, September 14, 2020 12:48:42 PM
To: Miao, Xin <Xin.Miao@...>; onap-seccom@... <onap-seccom@...>
Subject: Re: Waiver request for hard coded #ccsdk dgbuilder SSL certificate
 

Xin,

 

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.

 

Dan

 

From: "Xin.Miao@..." <Xin.Miao@...>
Date: Monday, September 14, 2020 at 1:28 PM
To: "TIMONEY, DAN" <dt5972@...>, "onap-seccom@..." <onap-seccom@...>
Subject: RE: Waiver request for hard coded #ccsdk dgbuilder SSL certificate

 

I believe the most advantage of DG is that user can modify and execute them in ONAP at Run Time.

 

Thanks,

 

Xin Miao

Solution Engineering

Fujitsu Network Communication

(W)972-479-2263 (M)469-268-5226

2811 Telecom Drive

Richardson, TX 75081, USA

 

From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of TIMONEY, DAN
Sent: Monday, September 14, 2020 8:56 AM
To: onap-seccom@...
Subject: [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder SSL certificate

 

SECCOM:

 

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,

Dan

 

 

-- 

Dan Timoney

dtimoney@...

Principal Technical Staff Member

ONAP Project Technical Lead : CCSDK and SDNC projects

 

 


Re: Waiver request for hard coded #ccsdk dgbuilder SSL certificate #ccsdk

Dan Timoney
 

Xin,

 

Sorry – hit send a bit too soon ….

 

When I say below “Our vision has always been that directed graphs should be distributed via SDC”, I meant to say that’s how those of us in the CCSDK/SDNC community early on saw how directed graph distribution should be done.  As I’m sure you know, we do not currently support distributing directed graphs via SDC.  I happen to think that would be an excellent enhancement, but it would of course have to be prioritized and slotted for a future release.

 

My email below was not clear on that point, so I thought it best to clarify.

 

Sorry for any confusion,

 

Dan

 

From: <onap-seccom@...> on behalf of "TIMONEY, DAN" <dt5972@...>
Date: Monday, September 14, 2020 at 1:48 PM
To: "Xin.Miao@..." <Xin.Miao@...>, "onap-seccom@..." <onap-seccom@...>
Subject: Re: [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder SSL certificate

 

***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.


Xin,

 

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.

 

Dan

 

From: "Xin.Miao@..." <Xin.Miao@...>
Date: Monday, September 14, 2020 at 1:28 PM
To: "TIMONEY, DAN" <dt5972@...>, "onap-seccom@..." <onap-seccom@...>
Subject: RE: Waiver request for hard coded #ccsdk dgbuilder SSL certificate

 

I believe the most advantage of DG is that user can modify and execute them in ONAP at Run Time.

 

Thanks,

 

Xin Miao

Solution Engineering

Fujitsu Network Communication

(W)972-479-2263 (M)469-268-5226

2811 Telecom Drive

Richardson, TX 75081, USA

 

From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of TIMONEY, DAN
Sent: Monday, September 14, 2020 8:56 AM
To: onap-seccom@...
Subject: [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder SSL certificate

 

SECCOM:

 

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,

Dan

 

 

-- 

Dan Timoney

dtimoney@...

Principal Technical Staff Member

ONAP Project Technical Lead : CCSDK and SDNC projects

 

 


Re: Waiver request for hard coded #ccsdk dgbuilder SSL certificate #ccsdk

Dan Timoney
 

Xin,

 

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.

 

Dan

 

From: "Xin.Miao@..." <Xin.Miao@...>
Date: Monday, September 14, 2020 at 1:28 PM
To: "TIMONEY, DAN" <dt5972@...>, "onap-seccom@..." <onap-seccom@...>
Subject: RE: Waiver request for hard coded #ccsdk dgbuilder SSL certificate

 

I believe the most advantage of DG is that user can modify and execute them in ONAP at Run Time.

 

Thanks,

 

Xin Miao

Solution Engineering

Fujitsu Network Communication

(W)972-479-2263 (M)469-268-5226

2811 Telecom Drive

Richardson, TX 75081, USA

 

From: onap-seccom@... [mailto:onap-seccom@...] On Behalf Of TIMONEY, DAN
Sent: Monday, September 14, 2020 8:56 AM
To: onap-seccom@...
Subject: [Onap-seccom] Waiver request for hard coded #ccsdk dgbuilder SSL certificate

 

SECCOM:

 

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,

Dan

 

 

-- 

Dan Timoney

dtimoney@...

Principal Technical Staff Member

ONAP Project Technical Lead : CCSDK and SDNC projects