Difference between revisions of "Barbican/Discussion-Federated-Barbican"
< Barbican
(Created page with "== Contents == '''This wiki page is a work in progress, intended to get contributors thinking about how to implement a Federated Barbican.''' There is a current desire for B...") |
|||
| Line 11: | Line 11: | ||
The proposed solution is to create a federated barbican where a separate barbican is put in front of a client's KMIP device on-prem and when | The proposed solution is to create a federated barbican where a separate barbican is put in front of a client's KMIP device on-prem and when | ||
a request is made to the public barbican, it is authenticated and routed to the private Barbican when necessary. | a request is made to the public barbican, it is authenticated and routed to the private Barbican when necessary. | ||
| + | |||
| + | FederatedBarbicanDiagram.jpg | ||
Revision as of 19:31, 10 August 2015
Contents
This wiki page is a work in progress, intended to get contributors thinking about how to implement a Federated Barbican.
There is a current desire for Barbican to be able to federate secrets from a private cloud into a public cloud.
Overview
In the current Barbican implementation, only one secret crypto device may be attached to the back end. This becomes problematic when a client wants to hook up their KMIP device within a public cloud infrastructure. The proposed solution is to create a federated barbican where a separate barbican is put in front of a client's KMIP device on-prem and when a request is made to the public barbican, it is authenticated and routed to the private Barbican when necessary.
FederatedBarbicanDiagram.jpg
