Difference between revisions of "Barbican/Discussion-Federated-Barbican"
< Barbican
(→Overview) |
(→Comments) |
||
| Line 20: | Line 20: | ||
* Clarification around flow: As result of step 2, client will get unscoped token for on-premise keystone and then use will that token to get scoped token for that on-premise cloud. Then client can use that scoped token <big>to talk directly</big> to on-premise Barbican. I don't think there is any Barbican to Barbican request redirection (which is more around resource federation use case which is not supported). Can someone clarify that? | * Clarification around flow: As result of step 2, client will get unscoped token for on-premise keystone and then use will that token to get scoped token for that on-premise cloud. Then client can use that scoped token <big>to talk directly</big> to on-premise Barbican. I don't think there is any Barbican to Barbican request redirection (which is more around resource federation use case which is not supported). Can someone clarify that? | ||
| − | **Silos - I think you are right. The way federated keystone is implemented now you first get a token to get access to the | + | **Silos - I think you are right. The way federated keystone is implemented now you first get a token to get access to the federated resources. The new diagram should reflect that. However I think this does raise a concern. In a production environment there would need to be some type of automation to tell barbican which keys are in the public barbican and which keys are in the federated barbican. That way the barbicanclient knows when to make a request to the public barbican or federated barbican. Does anyone else see this as a problem? |
Revision as of 22:00, 24 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 necessary a client can make requests to the private barbican by first requesting a token from the public keystone.
Comments
- Clarification around flow: As result of step 2, client will get unscoped token for on-premise keystone and then use will that token to get scoped token for that on-premise cloud. Then client can use that scoped token to talk directly to on-premise Barbican. I don't think there is any Barbican to Barbican request redirection (which is more around resource federation use case which is not supported). Can someone clarify that?
- Silos - I think you are right. The way federated keystone is implemented now you first get a token to get access to the federated resources. The new diagram should reflect that. However I think this does raise a concern. In a production environment there would need to be some type of automation to tell barbican which keys are in the public barbican and which keys are in the federated barbican. That way the barbicanclient knows when to make a request to the public barbican or federated barbican. Does anyone else see this as a problem?
