Open Stack

Excerpts from Carlos Garza's message of 2014-06-16 16:25:10 -0700:
> 
> On Jun 16, 2014, at 4: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
> > 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.