Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
I would like to see something more sophisticated than a simple counter (it's so easy for a counter to get off when dealing with non-atomic asynchronous commands). But a counter is a good place to start. On Jun 13, 2014 6:54 AM, Jain, Vivek vivekj...@ebay.com wrote: +2. I totally agree with your comments Doug. It defeats the purpose if Barbican does not want to deal with consumers of its service. Barbican can simply have a counter field on each container to signify how many consumers are using it. Every time a consumer uses a container, it increases the counter using barbican API. If counter is 0, container is safe to delete. —vivek 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 at 2:41 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 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.mendiza...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 3:26 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 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.harw...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 4:17 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 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 do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 4:10 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 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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
Excerpts from Doug Wiegley's message of 2014-06-10 14:41:29 -0700: 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. Doug, nobody is calling Barbican a database. It is a place to store secrets. The idea is to loosely couple things, and if you need more assurances, use something like Heat to manage the relationships. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
nobody is calling Barbican a database. It is a place to store Š did you at least feel a heavy sense of irony as you typed those two statements? ³It¹s not a database, it just stores things!² :-) The real irony here is that in this rather firm stand of keeping the user in control of their secrets, you are actually making the user LESS in control of their secrets. Copies of secrets will have to be made, whether stored under another tenant, or shadow copied somewhere. And the user will have no way to delete them, or even know that they exist. The force flag would eliminate the common mistake cases enough that I¹d wager lbaas and most others would cease to worry, not duplicate, and just reference barbican id¹s and nothing else. (Not including backends that will already make a copy of the secret, but things like servicevm will not need to dup it.) The earlier assertion that we have to deal with the missing secrets case even with a force flag is, I think, false, because once the common errors have been eliminated, the potential window of accidental pain is reduced to those that really ask for it. Thanks, Doug On 6/16/14, 1:56 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Doug Wiegley's message of 2014-06-10 14:41:29 -0700: 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. Doug, nobody is calling Barbican a database. It is a place to store secrets. The idea is to loosely couple things, and if you need more assurances, use something like Heat to manage the relationships. ___ 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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
Excerpts from Doug Wiegley's message of 2014-06-16 13:22:26 -0700: nobody is calling Barbican a database. It is a place to store Š did you at least feel a heavy sense of irony as you typed those two statements? ³It¹s not a database, it just stores things!² :-) Not at all, though I understand that, clipped as so, it may look a bit ironic. I was using shorthand of database to mean a general purpose database. I should have qualified it to avoid any confusion. It is a narrow purpose storage service with strong access controls. We can call that a database if you like, but I think it has one very tiny role, and that is to audit and control access to secrets. The real irony here is that in this rather firm stand of keeping the user in control of their secrets, you are actually making the user LESS in control of their secrets. Copies of secrets will have to be made, whether stored under another tenant, or shadow copied somewhere. And the user will have no way to delete them, or even know that they exist. Why would you need to make copies outside of the in-RAM copy that is kept while the service runs? You're trying to do too much instead of operating in a nice loosely coupled fashion. The force flag would eliminate the common mistake cases enough that I¹d wager lbaas and most others would cease to worry, not duplicate, and just reference barbican id¹s and nothing else. (Not including backends that will already make a copy of the secret, but things like servicevm will not need to dup it.) The earlier assertion that we have to deal with the missing secrets case even with a force flag is, I think, false, because once the common errors have been eliminated, the potential window of accidental pain is reduced to those that really ask for it. The accidental pain thing makes no sense to me. I'm a user and I take responsibility for my data. If I don't want to have that responsibility, I will use less privileged users and delegate the higher amount of privilege to a system that does manage those relationships for me. Do we have mandatory file locking in Unix? No we don't. Why? Because some users want the power to remove files _no matter what_. We build in the expectation that things may disappear no matter what you do to prevent it. I think your LBaaS should be written with the same assumption. It will be more resilient and useful to more people if they do not have to play complicated games to remove a secret. Anyway, nobody has answered this. What user would indiscriminately delete their own data and expect that things depending on that data will continue to work indefinitely? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
Sorry for responding so late but I don't think we should be doing ref counting at all. In a closed system its hard enough to guarantee they are correct but in an open distributed system I really doubt every service will bother decrementing and incrementing the counters properly. On Jun 16, 2014, at 1:35 PM, Stephen Balukoff sbaluk...@bluebox.net wrote: I would like to see something more sophisticated than a simple counter (it's so easy for a counter to get off when dealing with non-atomic asynchronous commands). But a counter is a good place to start. On Jun 13, 2014 6:54 AM, Jain, Vivek vivekj...@ebay.com wrote: +2. I totally agree with your comments Doug. It defeats the purpose if Barbican does not want to deal with consumers of its service. Barbican can simply have a counter field on each container to signify how many consumers are using it. Every time a consumer uses a container, it increases the counter using barbican API. If counter is 0, container is safe to delete. —vivek 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 at 2:41 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 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.mendiza...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 3:26 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 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.harw...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 4:17 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 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 do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 4:10 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 A third option, that is neither shadow copying nor policy
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
Hi Clint, Comments below. On 6/16/14, 3:06 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Doug Wiegley's message of 2014-06-16 13:22:26 -0700: nobody is calling Barbican a database. It is a place to store Š did you at least feel a heavy sense of irony as you typed those two statements? ³It¹s not a database, it just stores things!² :-) Not at all, though I understand that, clipped as so, it may look a bit ironic. I was using shorthand of database to mean a general purpose database. I should have qualified it to avoid any confusion. It is a narrow purpose storage service with strong access controls. We can call that a database if you like, but I think it has one very tiny role, and that is to audit and control access to secrets. The real irony here is that in this rather firm stand of keeping the user in control of their secrets, you are actually making the user LESS in control of their secrets. Copies of secrets will have to be made, whether stored under another tenant, or shadow copied somewhere. And the user will have no way to delete them, or even know that they exist. Why would you need to make copies outside of the in-RAM copy that is kept while the service runs? You're trying to do too much instead of operating in a nice loosely coupled fashion. I’ll come back to this. The force flag would eliminate the common mistake cases enough that I¹d wager lbaas and most others would cease to worry, not duplicate, and just reference barbican id¹s and nothing else. (Not including backends that will already make a copy of the secret, but things like servicevm will not need to dup it.) The earlier assertion that we have to deal with the missing secrets case even with a force flag is, I think, false, because once the common errors have been eliminated, the potential window of accidental pain is reduced to those that really ask for it. The accidental pain thing makes no sense to me. I'm a user and I take responsibility for my data. If I don't want to have that responsibility, I will use less privileged users and delegate the higher amount of privilege to a system that does manage those relationships for me. Do we have mandatory file locking in Unix? No we don't. Why? Because some users want the power to remove files _no matter what_. We build in the expectation that things may disappear no matter what you do to prevent it. I think your LBaaS should be written with the same assumption. It will be more resilient and useful to more people if they do not have to play complicated games to remove a secret. There is literally no amount of resilience that can recover an HTTPS service that has no SSL private key. It’s just down. Worse, it’s not down when the user takes the action; it’s down at some indeterminate point in the future (e.g. when it reboots next, or when the LB has to move two a different servicevm.) We could sub in a self-signed cert in that case, though that’s as bad as down in many contexts. I could be pedantic and point out that NFS files in use can’t be deleted, but that’s not relevant to your point. :-) Anyway, nobody has answered this. What user would indiscriminately delete their own data and expect that things depending on that data will continue to work indefinitely? Maybe there are multiple admins and a miscommunication? Memory lapse? What kind of customer base do you have that doesn’t make those kinds of mistakes *all the time*? You’re assuming a perfect user with a perfect memory; accidents happen. Now pair that with a wildcard cert used by 1000 sites, and you’ve just one-clicked your way into *an extremely bad day*. And you won’t even know it, until your pager starts to go off at some later date. Neutron doesn’t let you delete objects in use, e.g. Lots of other examples in the API. I’m not saying don’t let them cut their own foot off, if that’s their choice (the unix delete example.) But don’t make it easy, just because “they’d all just use force all the time anyway.” Why would you need to make copies outside of the in-RAM copy that is kept while the service runs? You're trying to do too much instead of operating in a nice loosely coupled fashion. Back to this — what you describe is what we *want* to do, but you have a pile of operators and admins that aren’t comfortable with having a single click, somewhere not related to the service, quietly setting a time bomb for a later service failure/downtime. Giving the user a way to easily discover how much of their foot they’re about to blow off, before doing it, is what we’re asking for. And without it, I expect that workarounds of all varieties will proliferate up and down the stack. Force flag, soft deletes, resource tracking, even just displaying who’s using what for a visual cue; there are any number of ways to make this less dangerous without pushing it onto every consumer of your service. Thanks, doug ___ OpenStack-dev mailing list
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
On Jun 16, 2014, at 3:22 PM, Doug Wiegley do...@a10networks.com wrote: nobody is calling Barbican a database. It is a place to store Š did you at least feel a heavy sense of irony as you typed those two statements? ³It¹s not a database, it just stores things!² :-) The real irony here is that in this rather firm stand of keeping the user in control of their secrets, you are actually making the user LESS in control of their secrets. Copies of secrets will have to be made, whether stored under another tenant, or shadow copied somewhere. And the user will have no way to delete them, or even know that they exist. The force flag would eliminate the common mistake cases enough that I¹d wager lbaas and most others would cease to worry, not duplicate, and just reference barbican id¹s and nothing else. (Not including backends that will already make a copy of the secret, but things like servicevm will not need to dup it.) The earlier assertion that we have to deal with the missing secrets case even with a force flag is, I think, false, because once the common errors have been eliminated, the potential window of accidental pain is reduced to those that really ask for it. The force flag is not an option and should no longer be considered. I'm thinking we should leave it to the user to properly delete their secrets and not try to open a can of behavioral worms by enforcing policy on the barbican side. :( Thanks, Doug On 6/16/14, 1:56 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Doug Wiegley's message of 2014-06-10 14:41:29 -0700: 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. Doug, nobody is calling Barbican a database. It is a place to store secrets. The idea is to loosely couple things, and if you need more assurances, use something like Heat to manage the relationships. ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
On Jun 16, 2014, at 4:06 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Doug Wiegley's message of 2014-06-16 13:22:26 -0700: nobody is calling Barbican a database. It is a place to store Š did you at least feel a heavy sense of irony as you typed those two statements? ³It¹s not a database, it just stores things!² :-) Not at all, though I understand that, clipped as so, it may look a bit ironic. I was using shorthand of database to mean a general purpose database. I should have qualified it to avoid any confusion. It is a narrow purpose storage service with strong access controls. We can call that a database if you like, but I think it has one very tiny role, and that is to audit and control access to secrets. The real irony here is that in this rather firm stand of keeping the user in control of their secrets, you are actually making the user LESS in control of their secrets. Copies of secrets will have to be made, whether stored under another tenant, or shadow copied somewhere. And the user will have no way to delete them, or even know that they exist. Why would you need to make copies outside of the in-RAM copy that is kept while the service runs? You're trying to do too much instead of operating in a nice loosely coupled fashion. Because the service may be restarted? The force flag would eliminate the common mistake cases enough that I¹d wager lbaas and most others would cease to worry, not duplicate, and just reference barbican id¹s and nothing else. (Not including backends that will already make a copy of the secret, but things like servicevm will not need to dup it.) The earlier assertion that we have to deal with the missing secrets case even with a force flag is, I think, false, because once the common errors have been eliminated, the potential window of accidental pain is reduced to those that really ask for it. The accidental pain thing makes no sense to me. I'm a user and I take responsibility for my data. If I don't want to have that responsibility, I will use less privileged users and delegate the higher amount of privilege to a system that does manage those relationships for me. Do we have mandatory file locking in Unix? No we don't. Why? Because some users want the power to remove files _no matter what_. We build in the expectation that things may disappear no matter what you do to prevent it. I think your LBaaS should be written with the same assumption. It will be more resilient and useful to more people if they do not have to play complicated games to remove a secret. Anyway, nobody has answered this. What user would indiscriminately delete their own data and expect that things depending on that data will continue to work indefinitely? Users that are expecting barbican operations to only occur during the initial loadbalancer provisioning. IE users that don't realize their LBconfigs don't natively store the private keys and would be be retrieving keys on the fly during every migration,HA spin up, service restart(from power failure) etc. But I agree we shouldn't do force flag locking as the barbican team has already dismissed the possibility of adding policy enforcement on behalf of other services. Shadow copying(into a lbaas owned account on barbican) was just so that our lbaas backend can access the keys outside of the users control if need be. :| ___ 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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
Look, I'm talking a lot and not showing up with code, so I'm squelching myself. Noted, and ditto. Thanks for the dialog. Doug On 6/16/14, 5:54 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Doug Wiegley's message of 2014-06-16 16:10:51 -0700: Hi Clint, Comments below. On 6/16/14, 3:06 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Doug Wiegley's message of 2014-06-16 13:22:26 -0700: nobody is calling Barbican a database. It is a place to store Š did you at least feel a heavy sense of irony as you typed those two statements? ³It¹s not a database, it just stores things!² :-) Not at all, though I understand that, clipped as so, it may look a bit ironic. I was using shorthand of database to mean a general purpose database. I should have qualified it to avoid any confusion. It is a narrow purpose storage service with strong access controls. We can call that a database if you like, but I think it has one very tiny role, and that is to audit and control access to secrets. The real irony here is that in this rather firm stand of keeping the user in control of their secrets, you are actually making the user LESS in control of their secrets. Copies of secrets will have to be made, whether stored under another tenant, or shadow copied somewhere. And the user will have no way to delete them, or even know that they exist. Why would you need to make copies outside of the in-RAM copy that is kept while the service runs? You're trying to do too much instead of operating in a nice loosely coupled fashion. I’ll come back to this. The force flag would eliminate the common mistake cases enough that I¹d wager lbaas and most others would cease to worry, not duplicate, and just reference barbican id¹s and nothing else. (Not including backends that will already make a copy of the secret, but things like servicevm will not need to dup it.) The earlier assertion that we have to deal with the missing secrets case even with a force flag is, I think, false, because once the common errors have been eliminated, the potential window of accidental pain is reduced to those that really ask for it. The accidental pain thing makes no sense to me. I'm a user and I take responsibility for my data. If I don't want to have that responsibility, I will use less privileged users and delegate the higher amount of privilege to a system that does manage those relationships for me. Do we have mandatory file locking in Unix? No we don't. Why? Because some users want the power to remove files _no matter what_. We build in the expectation that things may disappear no matter what you do to prevent it. I think your LBaaS should be written with the same assumption. It will be more resilient and useful to more people if they do not have to play complicated games to remove a secret. There is literally no amount of resilience that can recover an HTTPS service that has no SSL private key. It’s just down. Worse, it’s not down when the user takes the action; it’s down at some indeterminate point in the future (e.g. when it reboots next, or when the LB has to move two a different servicevm.) We could sub in a self-signed cert in that case, though that’s as bad as down in many contexts. This is way too much focus on problems that are not LBaaS's. Help users make keys for all other services, both inside the cloud and in the user's machines, more reliable.. don't just magically make them reliable for LBaaS. I could be pedantic and point out that NFS files in use can’t be deleted, but that’s not relevant to your point. :-) On the remote system, correct. On the home system, they can be rm'd right out from under the nfsd and there's nothing it can do about it. And that's just my point. NFS is a distributed system, and thus will try to take care of the distributed system, but the lower level thing, the host, is unencumbered by the service. I'm suggesting that LBaaS and Barbican are both low level services, and thus should not be doing anything at a higher level. Anyway, nobody has answered this. What user would indiscriminately delete their own data and expect that things depending on that data will continue to work indefinitely? Maybe there are multiple admins and a miscommunication? Memory lapse? What kind of customer base do you have that doesn’t make those kinds of mistakes *all the time*? You’re assuming a perfect user with a perfect memory; accidents happen. Now pair that with a wildcard cert used by 1000 sites, and you’ve just one-clicked your way into *an extremely bad day*. And you won’t even know it, until your pager starts to go off at some later date. This is the same reason we don't login to systems as root and just do whatever, right? We make admins funnel changes through a structured system that can be reviewed, tracked, and collaborated on. But we still have root.. and we still need it for
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
Excerpts from Carlos Garza's message of 2014-06-16 16:25:10 -0700: On Jun 16, 2014, at 4:06 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Doug Wiegley's message of 2014-06-16 13:22:26 -0700: nobody is calling Barbican a database. It is a place to store Š did you at least feel a heavy sense of irony as you typed those two statements? ³It¹s not a database, it just stores things!² :-) Not at all, though I understand that, clipped as so, it may look a bit ironic. I was using shorthand of database to mean a general purpose database. I should have qualified it to avoid any confusion. It is a narrow purpose storage service with strong access controls. We can call that a database if you like, but I think it has one very tiny role, and that is to audit and control access to secrets. The real irony here is that in this rather firm stand of keeping the user in control of their secrets, you are actually making the user LESS in control of their secrets. Copies of secrets will have to be made, whether stored under another tenant, or shadow copied somewhere. And the user will have no way to delete them, or even know that they exist. Why would you need to make copies outside of the in-RAM copy that is kept while the service runs? You're trying to do too much instead of operating in a nice loosely coupled fashion. Because the service may be restarted? The force flag would eliminate the common mistake cases enough that I¹d wager lbaas and most others would cease to worry, not duplicate, and just reference barbican id¹s and nothing else. (Not including backends that will already make a copy of the secret, but things like servicevm will not need to dup it.) The earlier assertion that we have to deal with the missing secrets case even with a force flag is, I think, false, because once the common errors have been eliminated, the potential window of accidental pain is reduced to those that really ask for it. The accidental pain thing makes no sense to me. I'm a user and I take responsibility for my data. If I don't want to have that responsibility, I will use less privileged users and delegate the higher amount of privilege to a system that does manage those relationships for me. Do we have mandatory file locking in Unix? No we don't. Why? Because some users want the power to remove files _no matter what_. We build in the expectation that things may disappear no matter what you do to prevent it. I think your LBaaS should be written with the same assumption. It will be more resilient and useful to more people if they do not have to play complicated games to remove a secret. Anyway, nobody has answered this. What user would indiscriminately delete their own data and expect that things depending on that data will continue to work indefinitely? Users that are expecting barbican operations to only occur during the initial loadbalancer provisioning. IE users that don't realize their LBconfigs don't natively store the private keys and would be be retrieving keys on the fly during every migration,HA spin up, service restart(from power failure) etc. But I agree we shouldn't do force flag locking as the barbican team has already dismissed the possibility of adding policy enforcement on behalf of other services. Shadow copying(into a lbaas owned account on barbican) was just so that our lbaas backend can access the keys outside of the users control if need be. :| I'm not sure what that means, but perhaps this is a nice use case for trusts, which would let the user hand LBaaS a revokable secret that gives LBaaS rights to impersonate the user for a specific keystone role. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
+2. I totally agree with your comments Doug. It defeats the purpose if Barbican does not want to deal with consumers of its service. Barbican can simply have a counter field on each container to signify how many consumers are using it. Every time a consumer uses a container, it increases the counter using barbican API. If counter is 0, container is safe to delete. —vivek From: Doug Wiegley do...@a10networks.commailto:do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 2:41 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: 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.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 3:26 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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.harw...@rackspace.commailto:adam.harw...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 4:17 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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 do...@a10networks.commailto:do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 4:10 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
Excerpts from Adam Harwell's message of 2014-06-10 12:04:41 -0700: 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? A user hands LBaaS an ID, and then deletes it, and expects that LBaaS can continue working indefinitely? How is that user's reckless action LBaaS's problem? Do one thing: Be a good load balancer. Let users orchestrate your APIs according to their use case and tools. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
On Jun 11, 2014, at 9:31 AM, Evgeny Fedoruk evge...@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. 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.venkatacha...@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:samu...@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:do...@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.mendiza...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 3:26 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
the backend it what's responsible for handling it from that point Right! For ex. NetScaler handles cert sync across HA nodes via its proprietary mechanisms. Since shadow copying is not required for every driver, the functionality can be implemented by the driver that needs it. Thanks, Vijay V. From: Adam Harwell [mailto:adam.harw...@rackspace.com] Sent: Wednesday, June 11, 2014 2:48 AM To: OpenStack Development Mailing List (not for usage questions) 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 do...@a10networks.commailto:do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 4:10 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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.harw...@rackspace.commailto:adam.harw...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 3:04 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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 do...@a10networks.commailto:do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 3:42 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
Excerpts from Vijay Venkatachalam's message of 2014-06-09 21:48:43 -0700: 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? Dangling reference. To avoid that, one should update all references before deleting. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
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.commailto:vijay.venkatacha...@citrix.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, 10 June 2014 05:48 To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 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.commailto: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.orgmailto: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
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.commailto:vijay.venkatacha...@citrix.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto: openstack-...@lists.openstack.or g Date: Tuesday, 10 June 2014 05:48 To: OpenStack List openstack-dev@lists.openstack.orgmailto: 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
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 do...@a10networks.commailto:do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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.orgmailto: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.netmailto:sbaluk...@bluebox.net Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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.orgmailto: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.commailto: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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
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
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.harw...@rackspace.commailto:adam.harw...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 2:19 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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 do...@a10networks.commailto:do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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.orgmailto: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.netmailto:sbaluk...@bluebox.net Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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.orgmailto: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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
I get the impression that the right place that the barbican team wants to support is in the eventing system they're already planning on implementing. But I understand that's also not on tap for Juno release, which means if we want to use barbican in how we do TLS termination on LBaaS, we need an alternate solution for at least the Juno release cycle. So far, the suggestion proposed by Adam is the best I've heard to handle this kind of thing gracefully. On Tue, Jun 10, 2014 at 1:42 PM, Doug Wiegley do...@a10networks.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. 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.harw...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 2:19 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 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
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.harw...@rackspace.commailto:adam.harw...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 3:04 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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 do...@a10networks.commailto:do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 3:42 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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.harw...@rackspace.commailto:adam.harw...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 2:19 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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 do...@a10networks.commailto:do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 2:53 PM To: OpenStack Development Mailing List
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.harw...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 4:17 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 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 do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 4:10 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 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.harw...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 3:04 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 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 do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 3:42 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 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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
It does make sense to me that this isn't something the Neutron API or LBaaS API needs to deal with directly (ie. it is more of a back-end issue). Therefore, using shadow store in the back-end isn't something which should affect Neutron or LBaaS interfaces at all. I also think Doug Wiegley is correct in that this does become a greater issue for more services which are consumers of barbican services, and that there is probably a better solution that is handled within barbican itself (though, again, I suspect this better solution is going to end up being the eventing system that barbican has said they're going to build in any case.) I can definitely see why the barbican doesn't want to support anything which looks like policy enforcement (at least, not out of the gate): It's probably not yet clear what the needs of other 3rd party services are going to be yet with regard to barbican, so developing an engine here that works great for LBaaS might not work so well for VPNaaS or whatever, and may entail compromises which would make the service more brittle in any case. And in any case, without having resources to throw at barbican at this point in time, I don't feel like it's my place to tell them how to run their project. :/ Stephen On Tue, Jun 10, 2014 at 2:17 PM, Adam Harwell adam.harw...@rackspace.com wrote: 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 do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 4:10 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 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.harw...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 3:04 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 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 do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 3:42 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 Doug: The reasons a LB might be reprovisioned are fairly important — mostly around
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.mendiza...@rackspace.commailto:douglas.mendiza...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 3:26 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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.harw...@rackspace.commailto:adam.harw...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 4:17 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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 do...@a10networks.commailto:do...@a10networks.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 4:10 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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.harw...@rackspace.commailto:adam.harw...@rackspace.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, June 10, 2014 at 3:04 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
Hi, I think that option 2 should be preferred at this stage. I also think that certificate should be immutable, if you want a new one, create a new one and update the listener to use it. This removes any chance of mistakes, need for versioning etc. -Sam. -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Friday, June 06, 2014 10: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@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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
Hi All, A Spec RST document was added to Gerrit for review https://review.openstack.org/#/c/98640 You are welcome to start commenting it for any open discussions. I tried to address each aspect being discussed, please add comments about missing things. Thanks, Evgeny -Original Message- From: Samuel Bercovici Sent: Monday, June 09, 2014 9:49 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Samuel Bercovici; Evgeny Fedoruk Subject: RE: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas Hi, I think that option 2 should be preferred at this stage. I also think that certificate should be immutable, if you want a new one, create a new one and update the listener to use it. This removes any chance of mistakes, need for versioning etc. -Sam. -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Friday, June 06, 2014 10: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@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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
Hey German, I agree with you. I don't really want to go with option #1 because making decisions on behalf of the user (especially when security is involved) can be quite tricky and dangerous. Your concerns are valid for option #2 but I still think it is the better option to go with. I believe Carlos and Adam are working with our Barbican team on a blueprint for option #2 so it would be nice if you could take a look at that and see how we can implement it to mitigate the concerns you laid out. While it would be nice for us to figure out how to ensure registration/unregistration at least the API user has the necessary info to ensure it themselves if need be. I'm not sure if I like the auto-update flag concept after all as it adds a layer of complexity depending on what the user has set. I'd prefer either an LBaaS makes all decisions on behalf of the user or LBaaS makes no deacons on behalf of the user approach with the latter being my preference. In one of my earlier emails I asked the fundamental question of whether flexibility is worthwhile at the cost of complexity. I prefer to start off simple since we don't have any real validation on whether these flexible features will actually be used. Once we have a product that is being widely deployed should flexible feature necessity become evident. Cheers, --Jorge On 6/6/14 5:52 PM, Eichberger, German german.eichber...@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.miramon...@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.w...@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.lar...@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.miramon...@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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
I understand this concern and was advocating that a configuration option be available to disable or enable auto updating of SSL certificates. But since every one is in favor of storing meta data on the barbican container directly I guess this is a moot point now. On Jun 6, 2014, at 5:52 PM, Eichberger, German german.eichber...@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.miramon...@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.w...@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.lar...@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.miramon...@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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
+1 for the idea of making certificate immutable. However, if Barbican allows updating certs/containers then versioning is a must. Thanks, Vivek On 6/8/14, 11:48 PM, Samuel Bercovici samu...@radware.com wrote: Hi, I think that option 2 should be preferred at this stage. I also think that certificate should be immutable, if you want a new one, create a new one and update the listener to use it. This removes any chance of mistakes, need for versioning etc. -Sam. -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Friday, June 06, 2014 10: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@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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
As far as I understand the Current Barbican implementation is immutable. Can anyone from Barbican comment on this? -Original Message- From: Jain, Vivek [mailto:vivekj...@ebay.com] Sent: Monday, June 09, 2014 8:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas +1 for the idea of making certificate immutable. However, if Barbican allows updating certs/containers then versioning is a must. Thanks, Vivek On 6/8/14, 11:48 PM, Samuel Bercovici samu...@radware.com wrote: Hi, I think that option 2 should be preferred at this stage. I also think that certificate should be immutable, if you want a new one, create a new one and update the listener to use it. This removes any chance of mistakes, need for versioning etc. -Sam. -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Friday, June 06, 2014 10: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@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 ___ 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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
As per current implementation, containers are immutable. Do we have any use case to make it mutable? Can we live with new container instead of updating an existing container? Arvind -Original Message- From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Monday, June 09, 2014 1:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas As far as I understand the Current Barbican implementation is immutable. Can anyone from Barbican comment on this? -Original Message- From: Jain, Vivek [mailto:vivekj...@ebay.com] Sent: Monday, June 09, 2014 8:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas +1 for the idea of making certificate immutable. However, if Barbican allows updating certs/containers then versioning is a must. Thanks, Vivek On 6/8/14, 11:48 PM, Samuel Bercovici samu...@radware.com wrote: Hi, I think that option 2 should be preferred at this stage. I also think that certificate should be immutable, if you want a new one, create a new one and update the listener to use it. This removes any chance of mistakes, need for versioning etc. -Sam. -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Friday, June 06, 2014 10: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@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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
The barbican team was considering making the container mutable but I don't think it matters now since every one has chimed in and wants the container to be immutable. The current discussion now is that the TLS container will be immutable but the meta data will not be. I'm not sure what is meant by versioning. If vivek cares to elaborate that would be helpful. On Jun 9, 2014, at 2:30 PM, Samuel Bercovici samu...@radware.com wrote: As far as I understand the Current Barbican implementation is immutable. Can anyone from Barbican comment on this? -Original Message- From: Jain, Vivek [mailto:vivekj...@ebay.com] Sent: Monday, June 09, 2014 8:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas +1 for the idea of making certificate immutable. However, if Barbican allows updating certs/containers then versioning is a must. Thanks, Vivek On 6/8/14, 11:48 PM, Samuel Bercovici samu...@radware.com wrote: Hi, I think that option 2 should be preferred at this stage. I also think that certificate should be immutable, if you want a new one, create a new one and update the listener to use it. This removes any chance of mistakes, need for versioning etc. -Sam. -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Friday, June 06, 2014 10: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@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 ___ OpenStack-dev mailing list OpenStack
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
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. 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. 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? -Doug On 6/9/14, 2:54 PM, Tiwari, Arvind arvind.tiw...@hp.com wrote: As per current implementation, containers are immutable. Do we have any use case to make it mutable? Can we live with new container instead of updating an existing container? Arvind -Original Message- From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Monday, June 09, 2014 1:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas As far as I understand the Current Barbican implementation is immutable. Can anyone from Barbican comment on this? -Original Message- From: Jain, Vivek [mailto:vivekj...@ebay.com] Sent: Monday, June 09, 2014 8:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas +1 for the idea of making certificate immutable. However, if Barbican allows updating certs/containers then versioning is a must. Thanks, Vivek On 6/8/14, 11:48 PM, Samuel Bercovici samu...@radware.com wrote: Hi, I think that option 2 should be preferred at this stage. I also think that certificate should be immutable, if you want a new one, create a new one and update the listener to use it. This removes any chance of mistakes, need for versioning etc. -Sam. -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Friday, June 06, 2014 10: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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
The impression I have from this thread is that Containers should remain immutable, but it would be helpful to allow services like LBaaS to register as interested in a given Container. This could be the full URI to the load balancer instance for example. This information would allow clients to see what services (and load balancer instances in this example) are using a Container, so they can update them if a new Container replaces the old one. They could also see what services depend on a Container before trying to remove the Container. A blueprint submission to Barbican tomorrow should provide more details on this, and let the Barbican and LBaaS communities weigh in on this feature. Thanks, John From: Tiwari, Arvind [arvind.tiw...@hp.com] Sent: Monday, June 09, 2014 2:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas As per current implementation, containers are immutable. Do we have any use case to make it mutable? Can we live with new container instead of updating an existing container? Arvind -Original Message- From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Monday, June 09, 2014 1:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas As far as I understand the Current Barbican implementation is immutable. Can anyone from Barbican comment on this? -Original Message- From: Jain, Vivek [mailto:vivekj...@ebay.com] Sent: Monday, June 09, 2014 8:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas +1 for the idea of making certificate immutable. However, if Barbican allows updating certs/containers then versioning is a must. Thanks, Vivek On 6/8/14, 11:48 PM, Samuel Bercovici samu...@radware.com wrote: Hi, I think that option 2 should be preferred at this stage. I also think that certificate should be immutable, if you want a new one, create a new one and update the listener to use it. This removes any chance of mistakes, need for versioning etc. -Sam. -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Friday, June 06, 2014 10: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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
The use case was that a cert inside the container could be updated while the private key stays the same. IE a new cert would be a resigning of the same old key. By immutable we mean to say that the same UUID would be used on the lbaas side. This is a heavy handed way of expecting the user to manually update their lbaas instances when they update a cert. Yes we can live with an immutable container which seems to be the direction we are going now. On Jun 9, 2014, at 2:54 PM, Tiwari, Arvind arvind.tiw...@hp.com wrote: As per current implementation, containers are immutable. Do we have any use case to make it mutable? Can we live with new container instead of updating an existing container? Arvind -Original Message- From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Monday, June 09, 2014 1:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas As far as I understand the Current Barbican implementation is immutable. Can anyone from Barbican comment on this? -Original Message- From: Jain, Vivek [mailto:vivekj...@ebay.com] Sent: Monday, June 09, 2014 8:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas +1 for the idea of making certificate immutable. However, if Barbican allows updating certs/containers then versioning is a must. Thanks, Vivek On 6/8/14, 11:48 PM, Samuel Bercovici samu...@radware.com wrote: Hi, I think that option 2 should be preferred at this stage. I also think that certificate should be immutable, if you want a new one, create a new one and update the listener to use it. This removes any chance of mistakes, need for versioning etc. -Sam. -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Friday, June 06, 2014 10: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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
I understand how this could be helpful, but I still don’t understand why this is Barbican’s problem to solve. From Jorge’s original email: Using this method requires services, such as LBaaS, to register in the form of metadata to a barbican container. If our assumptions are that the GUI can handle information, and that power users are savvy. Then how does that require Barbican to store the metadata? I would argue that the GUI can store its own metadata, and that Power Users should be savvy enough to update their LBs (via PUT or whatever) after uploading a new certificate. -Doug On 6/9/14, 6:10 PM, John Wood john.w...@rackspace.com wrote: The impression I have from this thread is that Containers should remain immutable, but it would be helpful to allow services like LBaaS to register as interested in a given Container. This could be the full URI to the load balancer instance for example. This information would allow clients to see what services (and load balancer instances in this example) are using a Container, so they can update them if a new Container replaces the old one. They could also see what services depend on a Container before trying to remove the Container. A blueprint submission to Barbican tomorrow should provide more details on this, and let the Barbican and LBaaS communities weigh in on this feature. Thanks, John From: Tiwari, Arvind [arvind.tiw...@hp.com] Sent: Monday, June 09, 2014 2:54 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas As per current implementation, containers are immutable. Do we have any use case to make it mutable? Can we live with new container instead of updating an existing container? Arvind -Original Message- From: Samuel Bercovici [mailto:samu...@radware.com] Sent: Monday, June 09, 2014 1:31 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas As far as I understand the Current Barbican implementation is immutable. Can anyone from Barbican comment on this? -Original Message- From: Jain, Vivek [mailto:vivekj...@ebay.com] Sent: Monday, June 09, 2014 8:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas +1 for the idea of making certificate immutable. However, if Barbican allows updating certs/containers then versioning is a must. Thanks, Vivek On 6/8/14, 11:48 PM, Samuel Bercovici samu...@radware.com wrote: Hi, I think that option 2 should be preferred at this stage. I also think that certificate should be immutable, if you want a new one, create a new one and update the listener to use it. This removes any chance of mistakes, need for versioning etc. -Sam. -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Friday, June 06, 2014 10: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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 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 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
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.commailto: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.orgmailto: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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
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 vivekj...@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.eichber...@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.miramon...@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.w...@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.lar...@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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
Excerpts from Eichberger, German's message of 2014-06-06 15:52:54 -0700: 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. Couldn't you allow a user to have multiple credentials, the way basically every key based user access system works (for an example see SSH). Users changing their credentials would create new ones, reference them in the appropriate consuming service, and dereference old ones when they are believed to be out of service. I see both specified options as overly complicated attempts to work around what would be solved gracefully with a many-to-one relationship of keys to users. 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. IMO you're doing way too much and tending toward tight coupling which will make the system brittle. If you want to give the user orchestration, there is Heat. A template will manage the sort of things that you want, such as automatic replacement and dereferencing/deleting of older credentials. But not if your service doesn't support having n+1 active credentials at one time. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
+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.eichber...@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.miramon...@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.w...@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.lar...@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.miramon...@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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
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 vivekj...@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.eichber...@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.miramon...@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.w...@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.lar...@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.miramon...@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
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.miramon...@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@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
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
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.lar...@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.miramon...@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@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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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.w...@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.lar...@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.miramon...@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@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 ___ OpenStack-dev mailing list OpenStack-dev
Re: [openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas
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.miramon...@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.w...@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.lar...@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.miramon...@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
