Jump to: navigation, search

Barbican/Policy

Project-scope System-scope
Route Method reader member admin reader member admin no auth Tag RBAC Name Notes
/ GET x key_manager:get_home (none) N/A No restrictions on this route
/v1 GET x key_manager:get_v1 (none) N/A No restrictions on this route
/v1/secrets GET x key_manager:list_secrets secrets:get
POST x key_manager:store_secrets secrets:post
/v1/secrets/{secret-id} GET x key_manager:get_secret_meta secret:get
PUT x key_manager:store_secrets secret:put
DELETE x key_manager:delete_secrets secret:delete
/v1/secrets/{secret-id}/acl GET x key_manager:get_acl secret_acls:get
PATCH x key_manager:manage_acl secret_acls:put_patch
PUT x key_manager:manage_acl secret_acls:put_patch
DELETE x key_manager:manage_acl secret_acls:delete
/v1/secrets/{secret-id}/metadata GET x key_manager:get_secret_meta secret_meta:get
PUT x key_manager:store_secrets secret_meta:put
POST x key_manager:store_secrets secret_meta:post
/v1/secrets/{secret-id}/metadata/{meta-key} GET x key_manager:get_secret_meta secret_meta:get
PUT x key_manager:store_secrets secret_meta:put
DELETE x key_manager:delete_secret_meta secret_meta:delete
/v1/secrets/{secret-id}/payload GET x key_manager:decrypt_secrets secret:decrypt
/v1/transport_keys GET x x key_manager:list_transport_keys transport_keys:get
POST x key_manager:add_transport_keys transport_keys:post
/v1/transport_keys/{key-id} GET x x key_manager:get_transport_keys transport_key:get
DELETE x key_manager:delete_transport_keys transport_key:delete
/v1/containers GET x key_manager:list_containers containers:get
POST x key_manager:create_containers containers:post
/v1/containers/{container-id} GET x key_manager:get_containers container:get
DELETE x key_manager:delete_containers container:delete
/v1/containers/{container-id}/acl GET x key_manager:get_acl container_acls:get
PATCH x key_manager:manage_acl container_acls:put_patch
PUT x key_manager:manage_acl container_acls:put_patch
DELETE x key_manager:manage_acl container_acls:delete
/v1/containers/{container-id}/consumers/{consumer-id} GET x x key_manager:list_container_consumer consumer:get
DELETE x x key_manager:list_container_consumers consumers:delete
/v1/containers/{container-id}/consumers GET x x key_manager:list_container_consumers consumers:get
POST x x key_manager:list_container_consumers consumers:post
/v1/containers/{container-id}/secrets POST x key_manager:create_containers container_secret:post
DELETE x key_manager:delete_containers container_secret:delete
/v1/secret-stores GET x x key_manager:list_backends secretstores:get
/v1/secret-stores/global-default GET x x key_manager:list_backends secretstores:get_global_default
/v1/secret-stores/preferred GET x key_manager:get_preferred_backend secretstores:get_preferred
/v1/secret-stores/{ss-id} GET x x key_manager:list_backends secretstore:get
/v1/secret-stores/{ss-id}/preferred POST x key_manager:manage_preferred_backend secretstores_preferred:post
DELETE x key_manager:manage_preferred_backend secretstores_preferred:delete
/v1/quotas GET x key_manager:list_quotas quotas:get
/v1/project-quotas GET x key_manager:get_system_quotas project_quotas:get
/v1/project-quotas/{project-id} GET x key_manager:get_system_quotas project_quotas:get
PUT x key_manager:set_system_quotas project_quotas:put
DELETE x key_manager:set_system_quotas project_quotas:delete
/v1/orders GET x key_manager:list_orders orders:get
PUT x key_manager:submit_orders orders:put
POST x key_manager:submit_orders orders:post
/v1/orders/{order-id} GET x key_manager:get_orders order:get
DELETE x key_manager:delete_orders order:delete

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
  • 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