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
