[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