Difference between revisions of "Barbican/Discussion-Federated-Barbican"

Revision as of 18:25, 31 August 2015

Federated Keystone Currently

The diagram below shows how Federated Keystone would currently work with Barbican. Everything that would be necessary to deploy an environment such as the one below, already exists in Barbican and Keystone.

General Federated Barbican Flow

Federated Barbican

Federated Keystone offers a good amount of solutions to some issues. These include:

Scaling Barbicans
Multiple Crypto Devices
Workload Distribution

However, there are still a few limitations that

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?
- Diazjf - Correct, The public Keystone will act as an IdP(Identity Provider), and the Private as a SP(Service Provider). The user must then use the IdP to obtain a SAML assertion and then use that assertion in order to generate an unscoped token for the SP. Then that token must be scoped, before an actions can be performed with it. For this K2K (Keystone-Keystone) Federation is required. A similar process must be done when using OpenIDC if 2 keystones are setup to use the same IdP. My concern here is that the user will need to know where the secret is stored before asking for it. I would propose for Secret objects to have a flag to check if its a link and be able to include links to a Barbican secret in another location. Hence, no special commands need to be performed for storing/getting a secret.

@@ Line 5: / Line 5: @@
 There is a current desire for Barbican to be able to federate secrets from a private cloud into a public cloud.
-== Overview ==
+== Federated Keystone Currently ==
+The diagram below shows how Federated Keystone would currently work with Barbican.
+Everything that would be necessary to deploy an environment such as the one below, already exists
+in Barbican and Keystone.
-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.
 [[File:FederatedBarbicanDiagram2.jpg|1000px|thumb|center|General Federated Barbican Flow]]
+== Federated Barbican ==
+Federated Keystone offers a good amount of solutions to some issues.
+These include:
+* Scaling Barbicans
+* Multiple Crypto Devices
+* Workload Distribution
+However, there are still a few limitations that
 ===== Comments =====