Create Secret Store Resource
The blueprint proposes creating a generic secret store resource that will allow support for many new secret stores including PKCS#11, PKCS#12, and KMIP. The current implementation of Barbican currently stores all of its secrets in a database and does not provide an interface for storage outside of a database. This blueprint will allow secrets to be stored on a hardware security device or a remote secret store operated by a customer or third party.
This goal of this blueprint is to create a generic secret store interface that allows many different secret store implementations to be supported. This will require creating a new secret store interface and modifying the API to invoke the new secret store interface. The diagram below illustrates the relationship between a secret requester, Barbican, and a secret store. The secret requestor in this instance is a compute instance. It interacts with Barbican to store and retrieve secrets. Barbican then interacts with a secret store for its storage of the secrets. Barbican will still provide the needed remote service interface for access by remote services and access control while the secret store will simply store the secrets.
NOTE: HSM image created by SafeNet (http://www.safenet-inc.com/uploadedImages/images/Icons/Hardware-Security-Module-Icon.png)
The secret store interface will support the basic functionality of a secret store. This will include the following functions:
- Create secret
- Put secret
- Update secret
- Delete secret
- Add attribute
- Get attributes
- Delete attribute
The changes will involve creating a new secret store interface with a default database secret store implementation, modifying SecretsResource and SecretResource to use the new secret store interface, and modifying the BeginOrder task that creates secrets to use the new interface. A class diagram is shown below that highlights the class relationships.
 PKCS#11 - http://www.cryptsoft.com/pkcs11doc/