Include the URL of your launchpad blueprint:
Currently retrieving the metadata and actual decrypted data for a secret stored in Barbican uses the same URI, with only the Accept header used to determine which response to return. This complicates deployments with RBAC systems in front of Barbican (such as Repose - http://openrepose.org/) or as middleware (such as EOM - https://github.com/racker/eom). It also requires adding logic like this to the Barbican app when it is used to enforce RBAC: https://github.com/openstack/barbican/blob/master/barbican/api/controllers/__init__.py#L53
This blueprint proposes using a unique URI to access decrypted secrets, such as this: <host>/v1/secrets/<secret-UUID>/payload
Currently to retrieve a secret’s metadata and its decrypted data, the same URI is used, such as this:
It would be easier to configure RBAC systems that operate in front of a Barbican deployment if these two retrieval types were distinguished by URI.
This blueprint calls for adding a new URI structure to retrieve decrypted secrets as follows:
So this would include adding a new Pecan sub-controller to handle the ‘payload’ requests, adding unit and functional tests for the new ‘payload’ resource, and updating API documentation.
The existing Accept-based decryption approach would not be removed in the current ‘v1’ API version to avoid breaking the current API contract, but could be removed in the next version (‘v2’) of the API (not part of this blueprint).
Another option is to use a URI such as this to retrieve decrypted secrets:
This approach would require parsing within the Pecan controller logic however.
This blueprint would add a new URI to retrieve decrypted secrets:
The Accept header would still be used as now to specify the desired format to return decrypted secrets in, but the ‘application/json’ format would no longer be needed/used.
The current URI to retrieve secrets would still function as it does now, but the decryption options could be removed in the next API version (‘v2’) by a future blueprint.
None, as the same policy rule (‘secret:decrypt’) for the new decrypt action will be used as for the current header-based decryption mechanism.
None, though auditing might actually be easier due to the unique-URI per action approach taken by this blueprint.
The Python Barbican client will also need to be updated to work with this change.
The proposed change would clean up the Pecan controllers code a bit, segregating secret metadata and decrypted payload concerns from each other.
Add unit and functional tests to test decrypted secret retrievals using the new ‘payload’ resource off of the ‘secrets’ resource. These new tests should function properly in the Devstack gate job.
API documentation will need to be updated to reflect these new secret decryption API call, and to mark as ‘deprecated’ the current Accept header based approach.