[openstack-dev] [Neutron][LBaaS] Barbican Neutron LBaaS Integration Ideas

Doug Wiegley dougw at a10networks.com
Mon Jun 16 23:10:51 UTC 2014

Hi Clint,

Comments below.

On 6/16/14, 3:06 PM, "Clint Byrum" <clint at 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
>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
>> 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,
>> 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
>> reference barbican id¹s and nothing else.  (Not including backends that
>> will already make a copy of the secret, but things like servicevm will
>> 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.


>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org

More information about the OpenStack-dev mailing list