> -----Original Message----- > From: Carlos Garza [mailto:[email protected]] > Sent: Thursday, June 12, 2014 1:34 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > Integration Ideas > > > On Jun 11, 2014, at 9:31 AM, Evgeny Fedoruk <[email protected]> > wrote: > > > Regarding the case when back-end system tries to retrieve secret from > > deleted Barbican TLS container, Is this a real use case? I mean, is there a > back-end system which will get container ID from somewhere, try to retrieve > secrets from Barbican by itself and hope for good? > > I'm of the opinion that the backend systems should not be talking to > barbican and that any key passing should happen from the API to the back > end. > I see it being very complex trying to code the backend so that its > configurable > with barbican since I would have assumed the backend won't even have > knowledge of open stack. > > > > In my understanding, there is a plugin and a driver who can always check > TLS container existence before even start configuring the back-end system. > In case of a problem tenant will receive a clear error message and back-end > system will remain up and running. > > This is the case when the API is spinning up the back end system. The > concern is when a backend tries to be HA by duplicating a loadbalancer for > redundancy. But I would argue that the front end as its being treated now > would not be managing details for HA so that the back end providing HA > would duplicate the keys between backend loadbalancers. Example F5 must > store the private key on its side and if its providing HA it would have > access to > the key already.
This assumption is right. For ex. in NetScaler case, when a certificate is sent to a HA setup of LoadBalancers, the certificate is maintained by the backend. The cert is replicated in both the LoadBalancers by its private mechanisms (no need to contact Barbican). > > > In case when back-end system itself triggers secret retrieval (outside of > OpenStack scope) - first it should check container existence and only after > that destroy previous TLS setup and perform a new setup. > > LBaaS back-end system may not get a container ID at all, but get its > > content > and not interact with Barbican by itself. > > In case when new LBaaS back-end system is created (HA event, for > example), whoever created an instance and gave it container ID, should > check its existence. > > > > Is there a specific use case when: > > back-end system, having container ID, up and running, offloading > > encrypted traffic with a certificate from that container (by this time > > deleted > from Barbican), at some time, goes and tries to retrieve the secret, fails, > loses its previous TLS settings and causing downtime? > > > > Regards, > > Evgeny > > > > > > > > From: Vijay Venkatachalam [mailto:[email protected]] > > Sent: Wednesday, June 11, 2014 4:14 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: [Caution: Message contains Suspicious URL content] Re: > > [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration > > Ideas > > > > +1 - Warning on a deletion of certificate in use can be considered as a > "nice-to-have" feature and not "must-have"! > > > > From: Samuel Bercovici [mailto:[email protected]] > > Sent: Wednesday, June 11, 2014 4:16 PM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > > Integration Ideas > > > > Hi, > > > > For Juno - > > I think that the existing capabilities in Barbican should be enough to start > with. > > A good detection and error message in LBaaS should also be sufficient to > start with. > > > > After Juno - > > We can consider a fix enhancement to Barbican later, IF deleting a > certificate in use and expressing an explicit error, will be common and > become an issue. > > > > Regards, > > -Sam. > > > > > > > > From: Doug Wiegley [mailto:[email protected]] > > Sent: Wednesday, June 11, 2014 12:41 AM > > To: OpenStack Development Mailing List (not for usage questions) > > Subject: [Caution: Message contains Suspicious URL content] Re: > > [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration > > Ideas > > > > Of what use is a database that randomly delete rows? That is, in effect, > what you're allowing. > > > > The secrets are only useful when paired with a service. And unless I'm > mistaken, there's no undo. So you're letting users shoot themselves in the > foot, for what reason, exactly? How do you expect openstack to rely on a > data store that is fundamentally random at the whim of users? Every single > service that uses Barbican will now have to hack in a defense mechanism of > some kind, because they can't trust that the secret they rely on will still be > there later. Which defeats the purpose of this mission statement: "Barbican > is a ReST API designed for the secure storage, provisioning and management > of secrets." > > > > (And I don't think anyone is suggesting that blind refcounts are the > > answer. At least, I hope not.) > > > > Anyway, I hear this has already been decided, so, so be it. Sounds like > > we'll > hack around it. > > > > Thanks, > > doug > > > > > > From: Douglas Mendizabal <[email protected]> > > Reply-To: "OpenStack Development Mailing List (not for usage > > questions)" <[email protected]> > > Date: Tuesday, June 10, 2014 at 3:26 PM > > To: "OpenStack Development Mailing List (not for usage questions)" > > <[email protected]> > > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > > Integration Ideas > > > > I think that having Barbican decide whether the user is or isn't allowed to > delete a secret that they own based on a reference count that is not directly > controlled by them is unacceptable. This is indeed policy enforcement, and > we'd rather not go down that path. > > > > I'm opposed to the idea of reference counting altogether, but a couple of > other Barbican-core members are open to it, as long as it does not affect the > delete behaviors. > > > > -Doug M. > > > > From: Adam Harwell <[email protected]> > > Reply-To: "OpenStack Development Mailing List (not for usage > > questions)" <[email protected]> > > Date: Tuesday, June 10, 2014 at 4:17 PM > > To: "OpenStack Development Mailing List (not for usage questions)" > > <[email protected]> > > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > > Integration Ideas > > > > Doug: Right, we actually have a blueprint draft for EXACTLY this, but > > the Barbican team gave us a flat "not happening, we reject this > > change" on causing a delete to fail. The shadow-copy solution I > > proposed only came about because the option you are proposing is not > > possible. :( > > > > I also realized that really, this whole thing is an issue for the backend, > > not > really for the API itself - the LBaaS API will be retrieving the key/cert from > Barbican and passing it to the backend, and the backend it what's responsible > for handling it from that point (F5, Stingray etc would never actually call > back > to Barbican). So, really, the Service-VM solution we're architecting is where > the shadow-copy solution needs to live, at which point it no longer is really > an > issue we'd need to discuss on this mailing list, I think. Stephen, does that > make sense to you? > > --Adam > > > > https://keybase.io/rm_you > > > > > > From: Doug Wiegley <[email protected]> > > Reply-To: "OpenStack Development Mailing List (not for usage > > questions)" <[email protected]> > > Date: Tuesday, June 10, 2014 4:10 PM > > To: "OpenStack Development Mailing List (not for usage questions)" > > <[email protected]> > > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > > Integration Ideas > > > > A third option, that is neither shadow copying nor policy enforcement: > > > > Ask the Barbican team to put in a small api that is effectively, "hey, I'm > using this container" and "hey, I'm done with this container", and the have > their delete fail if someone is still using it. This isn't calling into > other services, > it's simply getting informed of who's using what, and not stomping it. That > seems pretty core to me, and the workarounds if we can't trust the store to > store things are pretty hacky. > > > > Doug > > > > > > From: Adam Harwell <[email protected]> > > Reply-To: "OpenStack Development Mailing List (not for usage > > questions)" <[email protected]> > > Date: Tuesday, June 10, 2014 at 3:04 PM > > To: "OpenStack Development Mailing List (not for usage questions)" > > <[email protected]> > > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > > Integration Ideas > > > > Right, service VMs are the biggest case for this, because then we WILL > > need to be tracking the barbicanID even in the backend. I also agree > > that it would be more useful for OpenStack as a whole if it were > > managed by a central service (i.e., Barbican handles this issue) > > rather than having to duplicate all of this logic in every service > > that utilizes the containers (VPN/FW would have to use essentially the > > same strategy, or else fragment and do something entirely different - > > the first of which is a lot of duplicated effort, and the second is > > just generally bad, already way too much fragmentation going on). On > > the other hand, the Barbican team is very opposed to doing policy > > enforcement within Barbican, and I can't say I fault them for that > > opinion (Barbican was never designed to include a policy enforcement > > engine). The shadow-copy strategy is the best alternative I can think > > of given the current project/political landscape. :( > > > > --Adam > > > > https://keybase.io/rm_you > > > > > > From: Doug Wiegley <[email protected]> > > Reply-To: "OpenStack Development Mailing List (not for usage > > questions)" <[email protected]> > > Date: Tuesday, June 10, 2014 3:42 PM > > To: "OpenStack Development Mailing List (not for usage questions)" > > <[email protected]> > > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > > Integration Ideas > > > > > 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. > > > > Certainly the ticking time bomb is a bad idea, but HA seems cleaner to do in > the backend, rather than at the openstack API level (the dangling reference > doesn't kick in until the lbaas api is used to accomplish that failover.) > And the > lbaas api also doesn't have any provisions for helping to shuffle for > capacity, > so that also becomes a backend issue. And the backend won't be natively > dealing with a barbican reference. > > > > However, couple this with service VM's, and I guess the issue pops back > into the forefront. This is going to be an issue that everyone using ssl > certs in > barbican is going to have, so it seems we're applying a band-aid in the wrong > place. > > > > Doug > > > > > > From: Adam Harwell <[email protected]> > > Reply-To: "OpenStack Development Mailing List (not for usage > > questions)" <[email protected]> > > Date: Tuesday, June 10, 2014 at 2:19 PM > > To: "OpenStack Development Mailing List (not for usage questions)" > > <[email protected]> > > Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS > > Integration Ideas > > > > 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 <[email protected]> > > Reply-To: "OpenStack Development Mailing List (not for usage > > questions)" <[email protected]> > > Date: Tuesday, June 10, 2014 2:53 PM > > To: "OpenStack Development Mailing List (not for usage questions)" > > <[email protected]> > > 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 <[email protected]> > > Reply-To: "OpenStack Development Mailing List (not for usage > > questions)" <[email protected]> > > Date: Tuesday, June 10, 2014 at 1:47 PM > > To: "OpenStack Development Mailing List (not for usage questions)" > > <[email protected]> > > 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 > <[email protected]> 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" <[email protected]> > 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 > > > ><[email protected]<mailto:[email protected] > > >>> > > >Reply-To: OpenStack List > > ><[email protected]<mailto:openstack- > [email protected] > > >ck.or > > >g>> > > >Date: Tuesday, 10 June 2014 05:48 > > >To: OpenStack List > > ><[email protected]<mailto:openstack- > [email protected] > > >ck.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:[email protected]] > > >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 > > ><[email protected]<mailto:[email protected]>> 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 > > >[email protected]<mailto:OpenStack- > [email protected] > > >k.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 > > >[email protected] > > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > -- > > Stephen Balukoff > > Blue Box Group, LLC > > (800)613-4305 x807 > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
