[openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?
Brandon Logan
brandon.logan at RACKSPACE.COM
Mon Jun 23 22:38:47 UTC 2014
Whoops, [Neutron][LBaaS] got taken out of the subject line here.
Putting it back in.
On Mon, 2014-06-23 at 21:10 +0000, Brandon Logan wrote:
> Okay so we've talked a bit about this in IRC and now I'm sending this
> out as an update. Here are the options with pros and cons that have
> come from that discussion.
>
> 1) default_certificate_id is an attribute of the Listener object.
>
> Pros:
> -No extra entity needed
>
> Cons:
> -May bloat Listener object when more attributes are needed for only TLS
> termination. Sounds like TLS version and cipher selection will be
> needed attributes in the future.
>
>
> 2) A separate TLS Entity is created that is referenced by the Listener
> object. This entity at first may only contain a certificate_id that
> references barbican. Name and description can be allowed as well.
>
> Pros:
> -TLS domain specific attributes contained in its own entity
> -Future attributes would just be added to this entity and not bloat the
> Listener object.
>
> Cons:
> -It's another entity
>
> In IRC we (sbalukoff, myself) seemed to agree option 2 is right way to
> go. Anyone agree or disagree?
>
> Thanks,
> Brandon
>
> On Mon, 2014-06-23 at 12:15 -0700, Stephen Balukoff wrote:
> > The separate entity makes sense for certificates participating in an
> > SNI configuration, but probably not so much for the 'default'
> > certificate used when TLS is being terminated.
> >
> >
> > Vijay: You're also right that other TLS-related attributes will
> > probably get added to the Listener object. This probably makes sense
> > if they apply to the Listener object as a whole. (This includes things
> > like TLS version and cipher selection.)
> >
> >
> > I don't see much of a point in creating a separate object to contain
> > these fields, since it would have a 1:1 relationship with the
> > Listener. It's true that for non-TLS-terminated Listeners, these
> > fields wouldn't be used, but isn't that already the case in many other
> > objects (not just in the Neutron LBaaS sub project)?
> >
> >
> > Thanks,
> > Stephen
> >
> >
> >
> >
> >
> >
> > On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan
> > <brandon.logan at rackspace.com> wrote:
> > Vijay,
> > I think the separate entity is still going to happen. I don't
> > think it
> > has remvoed. Or that is may just be my assumption.
> >
> > Thanks,
> > Brandon
> >
> > On Mon, 2014-06-23 at 15:59 +0000, Vijay Venkatachalam wrote:
> > > Hi:
> > >
> > >
> > > In the “LBaaS TLS termination capability specification”
> > proposal
> > >
> > > https://review.openstack.org/#/c/98640/
> > >
> > > TLS settings like default certificate container id and SNI
> > cert list are part of the listener properties.
> > >
> > > I think it is better to have this as a separate entity so
> > that the listener properties are clean and is not “corrupted”
> > with TLS settings.
> > >
> > > I liked the original SSL proposal better where TLS settings
> > was a separate entity.
> > >
> > > It is just 2 properties now but in future the TLS settings
> > would grow and if we are going to introduce a TLS
> > profile/params/settings entity later, it is better to do it
> > now (albeit with min properties).
> > >
> > > Thanks,
> > > Vijay V.
> >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > >
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Stephen Balukoff
> > Blue Box Group, LLC
> > (800)613-4305 x807
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list