On Sat, Jan 6, 2018 at 3:26 AM, Juan Antonio Osorio <jaosor...@gmail.com> wrote: > > > On 4 Jan 2018 23:35, "Alan Bishop" <abis...@redhat.com> wrote: > > Has there been any previous discussion on providing a mechanism for > transferring ownership of a secret from one user to another? > > For castellan there isn't a discussion AFAIK. But it sounds like something > you can enable with Barbican's ACLs.
Conceptually, the goal is to truly transfer ownership. I considered Barbican ACLs as a workaround, but that approach isn't sufficient. A Barbican ACL would allow the new owner to read the secret, but woun't take into account whether the new owner happens to be an admin. Barbican secrets owned by an admin can be read by other admins, but an ACL would not allow other admins to read the secret. The bigger problem, though, is what happens when the new owner attempts to delete the volume. This requires deleting the secret, but the new volume owner only has read access to the secret. Cinder blocks attempts to delete encrypted volumes when the secret cannot be deleted. Otherwise, deleting a volume would cause the secret to be leaked (not exposed, but unmanaged by any owner). > https://docs.openstack.org/barbican/latest/api/reference/acls.html > > You would need to leverage Barbican's API instead of castellan though. > > > Cinder supports the notion of transferring volume ownership to another > user, who may be in another tenant/project. However, if the volume is > encrypted it's possible (even likely) that the new owner will not be > able to access the encryption secret. > > The new user will have the > encryption key ID (secret ref), but may not have permission to access > the secret, let alone delete the secret should the volume be deleted > later. This issue is currently flagged as a cinder bug [1]. > > This is a use case where the ownership of the encryption secret should > be transferred to the new volume owner. > > Alan > > [1] https://bugs.launchpad.net/cinder/+bug/1735285 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
