Hi Adam, If nothing else, we could always write a "garbage collector" process which periodically scans for shadow containers that are not in use by any listeners anymore and cleans them up. I suppose that's actually not a difficult problem to solve.
Anyway, yes, I'm liking your suggestion quite a bit: It leaves barbican and LBaaS neatly de-coupled, and prevents a ticking time bomb from exploding in the face of a user who deletes a container they didn't know was still in use. Stephen On Tue, Jun 10, 2014 at 1:19 PM, Adam Harwell <adam.harw...@rackspace.com> wrote: > Doug: The reasons a LB might be reprovisioned are fairly important — > mostly around HA, for fail overs or capacity — exactly the times we're > trying avoid a failure. > > Stephen: yes, I am talking about storing the copy in a non-tenant way > (on the tenant-id for the LBaaS Service Account, not visible to the user). > We would have to delete our shadow-copy when the loadbalancer was updated > with a new barbicanID by the user, and make a copy of the new container to > take its place. > Also, yes, I think it would be quite surprising (and far from ideal) when > the LB you set up breaks weeks or months later when an HA event occurs and > you haven't actually made any "changes" in quite a long time. > Unfortunately, "making the key unusable in all other contexts" on a > Barbican delete isn't really an option, so this is the best fallback I can > think of. > > --Adam > > https://keybase.io/rm_you > > > From: Doug Wiegley <do...@a10networks.com> > > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, June 10, 2014 2:53 PM > > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > > > In any case, it strikes me as misleading to have an explicit delete > command sent to Barbican not have the effect of making the key unusable in > all other contexts. It would be less surprising behavior, IMO, to have a > deleted barbican container result in connected load balancing services > breaking. (Though without notification to LBaaS, the connected service > might break weeks or months after the key disappeared from barbican, which > would be more surprising behavior.) > > Since a delete in barbican will not affect neutron/lbaas, and since most > backends will have had to make their own copy of the key at lb provision > time, the barbican delete will not result in lbaas breaking, I think. The > shadow copy would only get used if the lb had to be re-provisioned for some > reason before it was given a new key id, which seems a fair bit of > complexity for what is gained. > > doug > > > From: Stephen Balukoff <sbaluk...@bluebox.net> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Date: Tuesday, June 10, 2014 at 1:47 PM > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > > Adam-- > > Wouldn't the user see the duplicate key/cert copy in their barbican > interface, or are you proposing storing these secrets in a > not-assigned-to-the-tenant kind of way? > > In any case, it strikes me as misleading to have an explicit delete > command sent to Barbican not have the effect of making the key unusable in > all other contexts. It would be less surprising behavior, IMO, to have a > deleted barbican container result in connected load balancing services > breaking. (Though without notification to LBaaS, the connected service > might break weeks or months after the key disappeared from barbican, which > would be more surprising behavior.) > > Personally, I like your idea, as I think most of our users would rather > have LBaaS issue warnings when the user has done something stupid like this > rather than break entirely. I know our support staff would rather it > behaved this way. > > What's your proposal for cleaning up copied secrets when they're > actually no longer in use by any LB? > > Stephen > > > On Tue, Jun 10, 2014 at 12:04 PM, Adam Harwell <adam.harw...@rackspace.com > > wrote: > >> So, it looks like any sort of validation on Deletes in Barbican is going >> to be a no-go. I'd like to propose a third option, which might be the >> safest route to take for LBaaS while still providing some of the >> convenience of using Barbican as a central certificate store. Here is a >> diagram of the interaction sequence to create a loadbalancer: >> http://bit.ly/1pgAC7G >> >> Summary: Pass the Barbican "TLS Container ID" to the LBaaS create call, >> get the container from Barbican, and store a "shadow-copy" of the >> container again in Barbican, this time on the LBaaS service account. >> The secret will now be duplicated (it still exists on the original tenant, >> but also exists on the LBaaS tenant), but we're not talking about a huge >> amount of data here -- just a few kilobytes. With this approach, we retain >> most of the advantages we wanted to get from using Barbican -- we don't >> need to worry about taking secret data through the LBaaS API (we still >> just take a barbicanID from the user), and the user can still use a single >> barbicanID (the original one they created -- the copies are invisible to >> them) when passing their TLS info to other services. We gain the >> additional advantage that it no longer matters what happens to the >> original TLS container -- it could be deleted and it would not impact our >> service. >> >> What do you guys think of that option? >> >> >> >> As an addendum (not saying we necessarily want to do this, but it's an >> option), we COULD retain both the original and the copied barbicanID in >> our database and attempt to fetch them in that order when we need the TLS >> info again, which would allow us to do some alerting if the user does >> delete their key. For example: the user has deleted their key because it >> was compromised, but they forgot they used it on their loadbalancer -> a >> failover event occurs and we attempt to fetch the info from Barbican -> >> the first fetch fails, but the second fetch to our copy succeeds -> the >> failover of the LB is successful, and we send an alert to notify the user >> that their LB is using TLS info that has been deleted from Barbican. >> >> >> --Adam >> >> >> https://keybase.io/rm_you >> >> >> >> >> >> On 6/10/14 6:21 AM, "Clark, Robert Graham" <robert.cl...@hp.com> wrote: >> >> >It looks like this has come full circle and we are back at the simplest >> >case. >> > >> ># Containers are immutable >> ># Changing a cert means creating a new container and, when ready, >> >pointing LBaaS at the new container >> > >> >This makes a lot of sense to me, it removes a lot of handholding and >> >keeps Barbican and LBaaS nicely decoupled. It also keeps certificate >> >lifecycle management firmly in the hands of the user, which imho is a >> >good thing. With this model it¹s fairly trivial to provide guidance / >> >additional tooling for lifecycle management if required but at the same >> >time the simplest case (I want a cert and I want LBaaS) is met without >> >massive code overhead for edge-cases. >> > >> > >> >From: Vijay Venkatachalam >> ><vijay.venkatacha...@citrix.com<mailto:vijay.venkatacha...@citrix.com>> >> >Reply-To: OpenStack List >> ><openstack-dev@lists.openstack.org<mailto: >> openstack-...@lists.openstack.or >> >g>> >> >Date: Tuesday, 10 June 2014 05:48 >> >To: OpenStack List >> ><openstack-dev@lists.openstack.org<mailto: >> openstack-...@lists.openstack.or >> >g>> >> >Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS >> >Integration Ideas >> > >> > >> >My vote is for option #2 (without the registration). It is simpler to >> >start with this approach. How is delete handled though? >> > >> >Ex. What is the expectation when user attempts to delete a >> >certificate/container which is referred by an entity like LBaaS listener? >> > >> > >> >1. Will there be validation in Barbican to prevent this? *OR* >> > >> >2. LBaaS listener will have a dangling reference/pointer to >> >certificate? >> > >> >Thanks, >> >Vijay V. >> > >> >From: Stephen Balukoff [mailto:sbaluk...@bluebox.net] >> >Sent: Tuesday, June 10, 2014 7:43 AM >> >To: OpenStack Development Mailing List (not for usage questions) >> >Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS >> >Integration Ideas >> > >> >Weighing in here: >> > >> >I'm all for option #2 as well. >> > >> >Stephen >> > >> >On Mon, Jun 9, 2014 at 4:42 PM, Clint Byrum >> ><cl...@fewbar.com<mailto:cl...@fewbar.com>> wrote: >> >Excerpts from Douglas Mendizabal's message of 2014-06-09 16:08:02 -0700: >> >> Hi all, >> >> >> >> I¹m strongly in favor of having immutable TLS-typed containers, and >> very >> >> much opposed to storing every revision of changes done to a container. >> >>I >> >> think that storing versioned containers would add too much complexity >> to >> >> Barbican, where immutable containers would work well. >> >> >> >Agree completely. Create a new one for new values. Keep the old ones >> >while they're still active. >> > >> >> >> >> I¹m still not sold on the idea of registering services with Barbican, >> >>even >> >> though (or maybe especially because) Barbican would not be using this >> >>data >> >> for anything. I understand the problem that we¹re trying to solve by >> >> associating different resources across projects, but I don¹t feel like >> >> Barbican is the right place to do this. >> >> >> >Agreed also, this is simply not Barbican or Neutron's role. Be a REST >> >API for secrets and networking, not all dancing all singing nannies that >> >prevent any possibly dangerous behavior with said API's. >> > >> >> It seems we¹re leaning towards option #2, but I would argue that >> >> orchestration of services is outside the scope of Barbican¹s role as a >> >> secret-store. I think this is a problem that may need to be solved at >> a >> >> higher level. Maybe an openstack-wide registry of dependend entities >> >> across services? >> >An optional openstack-wide registry of depended entities is called >> >"Heat". >> > >> >_______________________________________________ >> >OpenStack-dev mailing list >> >OpenStack-dev@lists.openstack.org<mailto: >> OpenStack-dev@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@lists.openstack.org >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@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@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
