Jump to: navigation, search

Difference between revisions of "Barbican/Policy"

Line 39: Line 39:
 
| POST ||  || x || x ||  ||  ||  ||  || key_manager:store_secrets
 
| POST ||  || x || x ||  ||  ||  ||  || key_manager:store_secrets
 
|-
 
|-
−
| rowspan="3" | /v1/secrets/{secret-id}/metadata/{meta-key} || GET
+
| rowspan="3" | /v1/secrets/{secret-id}/metadata/{meta-key} || GET || x || x || x ||  ||  ||  ||  || key_manager:get_secret_meta
 
|-
 
|-
−
| PUT
+
| PUT ||  || x || x ||  ||  ||  ||  || key_manager:store_secrets
 +
|-
 +
| DELETE ||  || x || x ||  ||  ||  ||  || key_manager:delete_secret_meta
 +
|-
 +
| /v1/secrets/{secret-id}/payload || GET ||  || x || x ||  ||  ||  ||  || key_manager:decrypt_secrets
 
|-
 
|-
−
| DELETE
+
| rowspan="2" | /v1/transport_keys || GET ||  ||  ||  ||  ||  ||  ||  || key_manager:list_transport_keys
 
|-
 
|-
−
| /v1/secrets/{secret-id}/payload || GET
+
| POST || ||  ||  ||  ||  ||  ||  || key_manager:add_transport_keys
 
|-
 
|-
−
| rowspan="2" | /v1/transport_keys || GET
+
| rowspan="2" | /v1/transport_keys/{key-id} || GET ||  ||  ||  ||  ||  ||  ||  || key_manager:get_transport_keys
 
|-
 
|-
−
| POST
+
| DELETE ||  ||  ||  ||  ||  ||  ||  || key_manager:delete_transport_keys
 
|-
 
|-
−
| rowspan="2" | /v1/transport_keys/{key-id} || GET
+
| rowspan="2" | /v1/containers || GET || x || x || x ||  ||  ||  ||  || key_manager:list_containers
 
|-
 
|-
−
| DELETE
+
| POST ||  || x || x ||  ||  ||  ||  || key_manager:create_containers
 
|-
 
|-
−
| rowspan="2" | /v1/containers || GET
+
| rowspan="2" | /v1/containers/{container-id} || GET ||  || x || x ||  ||  ||  ||  || key_manager:get_containers
 
|-
 
|-
−
| POST
+
| DELETE ||  ||  || x ||  ||  ||  ||  || key_manager:delete_containers
 
|-
 
|-
−
| rowspan="2" | /v1/containers/{container-id} || GET
+
| rowspan="4" | /v1/containers/{container-id}/acl || GET || x || x || x ||  ||  ||  ||  || key_manager:get_acl
 
|-
 
|-
−
| DELETE
+
| PATCH ||  || x || x ||  ||  ||  ||  || key_manager:manage_acl
 
|-
 
|-
−
| rowspan="4" | /v1/containers/{container-id}/acl || GET
+
| PUT || || x || x ||  ||  ||  ||  || key_manager:manage_acl
 
|-
 
|-
−
| PATCH
+
| DELETE ||  || x || x ||  ||  ||  ||  || key_manager:manage_acl
 
|-
 
|-
−
| PUT
+
| /v1/containers/{container-id}/consumers || GET || x || x || x ||  ||  ||  ||  || key_manager:list_container_consumers
 
|-
 
|-
−
| DELETE
+
| rowspan="2" | /v1/containers/{container-id}/secrets || POST ||  || x || x ||  ||  ||  ||  || key_manager:create_containers
 
|-
 
|-
−
| /v1/containers/{container-id}/consumers || GET
+
| DELETE  || ||  || x ||  ||  ||  ||  || key_manager:delete_containers
 
|-
 
|-
−
| rowspan="2" | /v1/containers/{container-id}/secrets || POST
+
| /v1/secret-stores || GET || x || x || x || x || x || x ||  || key_manager:list_backends
 
|-
 
|-
−
| DELETE
+
| /v1/secret-stores/global-default || GET || x || x || x || x || x || x ||  || key_manager:list_backends
 
|-
 
|-
−
| /v1/secret-stores || GET
+
| /v1/secret-stores/preferred || GET || x || x || x ||  ||  ||  ||  || key_manager:get_preferred_backend
 
|-
 
|-
−
| /v1/secret-stores/{ss-id} || GET
+
| /v1/secret-stores/{ss-id} || GET || x || x || x || x || x || x ||  || key_manager:list_backends
 
|-
 
|-
−
| rowspan="2" | /v1/secret-stores/{ss-id}/preferred || POST
+
| rowspan="2" | /v1/secret-stores/{ss-id}/preferred || POST ||  ||  || x ||  ||  ||  ||  || key_manager:set_preferred_backend
 
|-
 
|-
 
| DELETE
 
| DELETE
Line 114: Line 118:
 
** (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) 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?
 
** (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_secret
+
* key_manager:store_secrets
 
** (dmendiza) Is it ok to use this for adding metadata to a secret?  I think it is.
 
** (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?

Revision as of 01:08, 14 June 2018

Project-scope System-scope
Route Method reader member admin reader member admin no auth Tag
/ GET x x x x x x x key_manager:get_home
/v1 GET x x x x x x key_manager:get_v1
/v1/secrets GET x x x key_manager:list_secrets
POST x x key_manager:store_secrets
/v1/secrets/{secret-id} GET Accept:application/json x x x key_manager:get_secret_meta
DEPRECATED

GET Accept:{secret-mime}

x x key_manager:decrypt_secrets
PUT x x key_manager:store_secrets
DELETE x key_manager:delete_secrets
/v1/secrets/{secret-id}/acl GET x x x key_manager:get_acl
PATCH x x key_manager:manage_acl
PUT x x key_manager:manage_acl
DELETE x x key_manager:manage_acl
/v1/secrets/{secret-id}/metadata GET x x x key_manager:get_secret_meta
PUT x x key_manager:store_secrets
POST x x key_manager:store_secrets
/v1/secrets/{secret-id}/metadata/{meta-key} GET x x x key_manager:get_secret_meta
PUT x x key_manager:store_secrets
DELETE x x key_manager:delete_secret_meta
/v1/secrets/{secret-id}/payload GET x x key_manager:decrypt_secrets
/v1/transport_keys GET key_manager:list_transport_keys
POST key_manager:add_transport_keys
/v1/transport_keys/{key-id} GET key_manager:get_transport_keys
DELETE key_manager:delete_transport_keys
/v1/containers GET x x x key_manager:list_containers
POST x x key_manager:create_containers
/v1/containers/{container-id} GET x x key_manager:get_containers
DELETE x key_manager:delete_containers
/v1/containers/{container-id}/acl GET x x x key_manager:get_acl
PATCH x x key_manager:manage_acl
PUT x x key_manager:manage_acl
DELETE x x key_manager:manage_acl
/v1/containers/{container-id}/consumers GET x x x key_manager:list_container_consumers
/v1/containers/{container-id}/secrets POST x x key_manager:create_containers
DELETE x key_manager:delete_containers
/v1/secret-stores GET x x x x x x key_manager:list_backends
/v1/secret-stores/global-default GET x x x x x x key_manager:list_backends
/v1/secret-stores/preferred GET x x x key_manager:get_preferred_backend
/v1/secret-stores/{ss-id} GET x x x x x x key_manager:list_backends
/v1/secret-stores/{ss-id}/preferred POST x key_manager:set_preferred_backend
DELETE
/v1/quotas GET
/v1/project-quotas GET
/v1/project-quotas/{project-id} GET
PUT
DELETE
DEPRECATED - To be removed in P
/v1/orders GET
PUT
POST
/v1/orders/{order-id} GET
DELETE
  • 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?
Retrieved from "https://wiki.openstack.org/w/index.php?title=Barbican/Policy&oldid=161928"