Open Stack

> -----Original Message-----
> From: Carlos Garza [mailto:carlos.garza at rackspace.com]
> 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 <EvgenyF at Radware.com>
> 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:Vijay.Venkatachalam at citrix.com]
> > 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:SamuelB at Radware.com]
> > 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:dougw at a10networks.com]
> > 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 <douglas.mendizabal at RACKSPACE.COM>
> > Reply-To: "OpenStack Development Mailing List (not for usage
> > questions)" <openstack-dev at lists.openstack.org>
> > Date: Tuesday, June 10, 2014 at 3:26 PM
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > 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 <adam.harwell at RACKSPACE.COM>
> > Reply-To: "OpenStack Development Mailing List (not for usage
> > questions)" <openstack-dev at lists.openstack.org>
> > Date: Tuesday, June 10, 2014 at 4:17 PM
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > 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 <dougw at a10networks.com>
> > Reply-To: "OpenStack Development Mailing List (not for usage
> > questions)" <openstack-dev at lists.openstack.org>
> > Date: Tuesday, June 10, 2014 4:10 PM
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > 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 <adam.harwell at RACKSPACE.COM>
> > Reply-To: "OpenStack Development Mailing List (not for usage
> > questions)" <openstack-dev at lists.openstack.org>
> > Date: Tuesday, June 10, 2014 at 3:04 PM
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > 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 <dougw at a10networks.com>
> > Reply-To: "OpenStack Development Mailing List (not for usage
> > questions)" <openstack-dev at lists.openstack.org>
> > Date: Tuesday, June 10, 2014 3:42 PM
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > 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 <adam.harwell at RACKSPACE.COM>
> > Reply-To: "OpenStack Development Mailing List (not for usage
> > questions)" <openstack-dev at lists.openstack.org>
> > Date: Tuesday, June 10, 2014 at 2:19 PM
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > 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 <dougw at a10networks.com>
> > Reply-To: "OpenStack Development Mailing List (not for usage
> > questions)" <openstack-dev at lists.openstack.org>
> > Date: Tuesday, June 10, 2014 2:53 PM
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at 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 <sbalukoff at bluebox.net>
> > Reply-To: "OpenStack Development Mailing List (not for usage
> > questions)" <openstack-dev at lists.openstack.org>
> > Date: Tuesday, June 10, 2014 at 1:47 PM
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at 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.harwell at 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.clark at 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.Venkatachalam at citrix.com<mailto:Vijay.Venkatachalam at citrix.com
> > >>>
> > >Reply-To: OpenStack List
> > ><openstack-dev at lists.openstack.org<mailto:openstack-
> dev at lists.opensta
> > >ck.or
> > >g>>
> > >Date: Tuesday, 10 June 2014 05:48
> > >To: OpenStack List
> > ><openstack-dev at lists.openstack.org<mailto:openstack-
> dev at lists.opensta
> > >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:sbalukoff at 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
> > ><clint at fewbar.com<mailto:clint at 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 at lists.openstack.org<mailto:OpenStack-
> dev at lists.openstac
> > >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
> > >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