[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

Brandon Logan brandon.logan at RACKSPACE.COM
Sun Jun 8 22:53:34 UTC 2014


I think that would defeat a big purpose for barbican; a user only has to
store their secret in one central location for reuse with many services.

Thanks,
Brandon

On Sun, 2014-06-08 at 09:05 +0400, Eugene Nikanorov wrote:
> >  If a user makes a change to a secret
> Can we just disable that by making LBaaS a separate user so it would
> store secrets under LBaaS 'fake' tenant id?
> 
> 
> Eugene.
> 
> 
> On Sun, Jun 8, 2014 at 7:29 AM, Jain, Vivek <VIVEKJAIN at ebay.com>
> wrote:
>         +1 for #2.
>         
>         In addition, I think it would be nice if barbican maintains
>         versioned data
>         on updates. Which means consumer of barbican APIs can request
>         for data
>         from older version if needed. This can address concerns
>         expressed by
>         German. For example if certificates were updated on barbican
>         but somehow
>         update is not compatible with load balancer device, then lbaas
>         API user
>         gets an option to fall back to older working certificate. That
>         will avoid
>         downtime of lbaas managed applications.
>         
>         Thanks,
>         Vivek
>         
>         On 6/6/14, 3:52 PM, "Eichberger, German"
>         <german.eichberger at hp.com> wrote:
>         
>         >Jorge + John,
>         >
>         >I am most concerned with a user changing his secret in
>         barbican and then
>         >the LB trying to update and causing downtime. Some users like
>         to control
>         >when the downtime occurs.
>         >
>         >For #1 it was suggested that once the event is delivered it
>         would be up
>         >to a user to enable an "auto-update flag".
>         >
>         >In the case of #2 I am a bit worried about error cases: e.g.
>         uploading
>         >the certificates succeeds but registering the loadbalancer(s)
>         fails. So
>         >using the barbican system for those warnings might not as
>         fool proof as
>         >we are hoping.
>         >
>         >One thing I like about #2 over #1 is that it pushes a lot of
>         the
>         >information to Barbican. I think a user would expect when he
>         uploads a
>         >new certificate to Barbican that the system warns him right
>         away about
>         >load balancers using the old cert. With #1 he might get an
>         e-mails from
>         >LBaaS telling him things changed (and we helpfully updated
>         all affected
>         >load balancers) -- which isn't as immediate as #2.
>         >
>         >If we implement an "auto-update flag" for #1 we can have
>         both. User's who
>         >like #2 juts hit the flag. Then the discussion changes to
>         what we should
>         >implement first and I agree with Jorge + John that this
>         should likely be
>         >#2.
>         >
>         >German
>         >
>         >-----Original Message-----
>         >From: Jorge Miramontes
>         [mailto:jorge.miramontes at RACKSPACE.COM]
>         >Sent: Friday, June 06, 2014 3:05 PM
>         >To: OpenStack Development Mailing List (not for usage
>         questions)
>         >Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican
>         Neutron LBaaS
>         >Integration Ideas
>         >
>         >Hey John,
>         >
>         >Correct, I was envisioning that the Barbican request would
>         not be
>         >affected, but rather, the GUI operator or API user could use
>         the
>         >registration information to do so should they want to do so.
>         >
>         >Cheers,
>         >--Jorge
>         >
>         >
>         >
>         >
>         >On 6/6/14 4:53 PM, "John Wood" <john.wood at RACKSPACE.COM>
>         wrote:
>         >
>         >>Hello Jorge,
>         >>
>         >>Just noting that for option #2, it seems to me that the
>         registration
>         >>feature in Barbican would not be required for the first
>         version of this
>         >>integration effort, but we should create a blueprint for it
>         nonetheless.
>         >>
>         >>As for your question about services not
>         registering/unregistering, I
>         >>don't see an issue as long as the presence or absence of
>         registered
>         >>services on a Container/Secret does not **block** actions
>         from
>         >>happening, but rather is information that can be used to
>         warn clients
>         >>through their processes. For example, Barbican would still
>         delete a
>         >>Container/Secret even if it had registered services.
>         >>
>         >>Does that all make sense though?
>         >>
>         >>Thanks,
>         >>John
>         >>
>         >>________________________________________
>         >>From: Youcef Laribi [Youcef.Laribi at citrix.com]
>         >>Sent: Friday, June 06, 2014 2:47 PM
>         >>To: OpenStack Development Mailing List (not for usage
>         questions)
>         >>Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican
>         Neutron LBaaS
>         >>Integration Ideas
>         >>
>         >>+1 for option 2.
>         >>
>         >>In addition as an additional safeguard, the LBaaS service
>         could check
>         >>with Barbican when failing to use an existing secret to see
>         if the
>         >>secret has changed (lazy detection).
>         >>
>         >>Youcef
>         >>
>         >>-----Original Message-----
>         >>From: Jorge Miramontes
>         [mailto:jorge.miramontes at RACKSPACE.COM]
>         >>Sent: Friday, June 06, 2014 12:16 PM
>         >>To: OpenStack Development Mailing List (not for usage
>         questions)
>         >>Subject: [openstack-dev] [Neutron][LBaaS] Barbican Neutron
>         LBaaS
>         >>Integration Ideas
>         >>
>         >>Hey everyone,
>         >>
>         >>Per our IRC discussion yesterday I'd like to continue the
>         discussion on
>         >>how Barbican and Neutron LBaaS will interact. There are
>         currently two
>         >>ideas in play and both will work. If you have another idea
>         please free
>         >>to add it so that we may evaluate all the options relative
>         to each other.
>         >>Here are the two current ideas:
>         >>
>         >>1. Create an eventing system for Barbican that Neutron LBaaS
>         (and other
>         >>services) consumes to identify when to update/delete updated
>         secrets
>         >>from Barbican. For those that aren't up to date with the
>         Neutron LBaaS
>         >>API Revision, the project/tenant/user provides a secret
>         (container?) id
>         >>when enabling SSL/TLS functionality.
>         >>
>         >>* Example: If a user makes a change to a secret/container in
>         Barbican
>         >>then Neutron LBaaS will see an event and take the
>         appropriate action.
>         >>
>         >>PROS:
>         >> - Barbican is going to create an eventing system regardless
>         so it will
>         >>be supported.
>         >> - Decisions are made on behalf of the user which lessens
>         the amount of
>         >>calls the user has to make.
>         >>
>         >>CONS:
>         >> - An eventing framework can become complex especially since
>         we need to
>         >>ensure delivery of an event.
>         >> - Implementing an eventing system will take more time than
>         option #2ŠI
>         >>think.
>         >>
>         >>2. Push orchestration decisions to API users. This idea
>         comes with two
>         >>assumptions. The first assumption is that most providers'
>         customers use
>         >>the cloud via a GUI, which in turn can handle any
>         orchestration
>         >>decisions that need to be made. The second assumption is
>         that power API
>         >>users are savvy and can handle their decisions as well.
>         Using this
>         >>method requires services, such as LBaaS, to "register" in
>         the form of
>         >>metadata to a barbican container.
>         >>
>         >>* Example: If a user makes a change to a secret the GUI can
>         see which
>         >>services are registered and opt to warn the user of
>         consequences. Power
>         >>users can look at the registered services and make decisions
>         how they
>         >>see fit.
>         >>
>         >>PROS:
>         >> - Very simple to implement. The only code needed to make
>         this a
>         >>reality is at the control plane (API) level.
>         >> - This option is more loosely coupled that option #1.
>         >>
>         >>CONS:
>         >> - Potential for services to not register/unregister. What
>         happens in
>         >>this case?
>         >> - Pushes complexity of decision making on to GUI engineers
>         and power
>         >>API users.
>         >>
>         >>
>         >>I would like to get a consensus on which option to move
>         forward with
>         >>ASAP since the hackathon is coming up and delivering
>         Barbican to
>         >>Neutron LBaaS integration is essential to exposing SSL/TLS
>         >>functionality, which almost everyone has stated is a #1/#2
>         priority.
>         >>
>         >>I'll start the decision making process by advocating for
>         option #2. My
>         >>reason for choosing option #2 has to deal mostly with the
>         simplicity of
>         >>implementing such a mechanism. Simplicity also means we can
>         implement
>         >>the necessary code and get it approved much faster which
>         seems to be a
>         >>concern for everyone. What option does everyone else want to
>         move
>         >>forward with?
>         >>
>         >>
>         >>
>         >>Cheers,
>         >>--Jorge
>         >>
>         >>
>         >>_______________________________________________
>         >>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
>         >>
>         >>_______________________________________________
>         >>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
>         >
>         >_______________________________________________
>         >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
>         
> 
> 
> _______________________________________________
> 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