Barbican/Policy

Questions (tied to tags):


 * key_manager:manage_acl
 * (dmendiza) Is this too broad?
 * (dmendiza) Should we have separate key_manager:(secret|order)_manage_acl?
 * (dmendiza) Should member be allowed to manage ACL? Would private secrets break if we don't?  Are private secrets really private it we do?
 * (dmendiza) Is there a way to reference the User by ID to introduce the concept of a secret owner into this policy?
 * key_manager:store_secrets
 * (dmendiza) Is it ok to use this for adding metadata to a secret? I think it is.
 * key_manager:delete_secret_meta
 * (dmendiza) Is it ok for a member to delete secret meta?
 * key_manager:get_secret_meta
 * (hrybacki): we use the same rule for both /v1/secrets/{secret-id}/metadata and /v1/secrets/{secret-id}/metadata/{meta-key}. Should we break these into separate rules so we can properly use the DocumentedRuleDefault description field?
 * key_manager:store_secrets
 * (hrybacki): Same as above only for PUT rather than GET
 * key_manager:get_secret_meta
 * (hrybacki): The deprecated code path for this route (one way of decrypting secrets) should be removed. Can we create a user story for this?
 * key_manager:list_container_consumers
 * (hrybacki) Can we rename this policy `consumerS:delete -> consumeR:delete` ?
 * (hrybacki) I chose member role for this but should it be admin level?
 * key_manager:submit_orders
 * The PUT request lives in policy but was missing from the [API reference docs](https://docs.openstack.org/barbican/latest/api/reference/orders.html). I've created [a story to remove this](https://storyboard.openstack.org/#!/story/2002579).
 * key_manager:list_transport_keys
 * (hrybacki): Does this need any auth at all?
 * routes: /v1/secrets/{secret-id}/acl and /v1/containers/{container-id}/acl
 * (hrybacki) need to verify existing rules with the new member (secret non-private read and container non-private read). Check with Ade