Difference between revisions of "Barbican/Discussion-Federated-Barbican"
(→Federated Barbican) |
|||
| Line 43: | Line 43: | ||
3. Database Redirection | 3. Database Redirection | ||
| + | |||
| + | Below are possible implementations of the three scenarios described above. | ||
=== Proxy === | === Proxy === | ||
| + | |||
| + | [[File:Proxy_Implementation.png|1000px|thumb|center]] | ||
| + | |||
| + | The proxy proposal offloads all of the Federated Keystone work onto the proxy server. | ||
| + | The proxy would handle the authentication to the separate keystone and then forward the | ||
| + | request to the separate Barbican using the new token it received from keystone. | ||
| + | The proxy could be treated the same way plugins are currently treated. | ||
| + | In order to turn it on set a value in the conf file such as "proxy_enabled" to true which is by default | ||
| + | set to false. | ||
| + | |||
| + | There are still 2 problems: | ||
| + | # There needs to be a way to determine if the request should be forwarded at all. | ||
| + | # There would still need to be a way to tell the proxy where the barbican it needs to forward to the request to resides | ||
| + | |||
| + | Use case 1 does not seem complicated. There could be a flag added to the client such as --federate that tells the proxy to use the federated | ||
| + | barbican. If | ||
== Comments == | == Comments == | ||
Revision as of 05:35, 1 September 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.
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.
Federated Barbican
Federated Keystone offers a good amount of solutions to some issues. These include:
- Scaling Barbicans
- Multiple Crypto Devices
- Workload Distribution
- Hybrid Barbicans
However, there are still a few limitations that need to be addressed.
The biggest one that I can see is automation of the token retrieval.
This problem does not appear to be unique to us. I would think other services might have set up some kind of pipeline or middleware of some sort that automatically takes care of steps 1-5. That is currently something I am looking into right now.
The other concern is directing the secret retrieval to the correct barbican. The scenario I am thinking about is swift encryption.
There are three ideas that myself, diazjf, and edtubill have been working on:
1. Proxy redirect
2. Crypto Driver
3. Database Redirection
Below are possible implementations of the three scenarios described above.
Proxy
The proxy proposal offloads all of the Federated Keystone work onto the proxy server. The proxy would handle the authentication to the separate keystone and then forward the request to the separate Barbican using the new token it received from keystone. The proxy could be treated the same way plugins are currently treated. In order to turn it on set a value in the conf file such as "proxy_enabled" to true which is by default set to false.
There are still 2 problems:
- There needs to be a way to determine if the request should be forwarded at all.
- There would still need to be a way to tell the proxy where the barbican it needs to forward to the request to resides
Use case 1 does not seem complicated. There could be a flag added to the client such as --federate that tells the proxy to use the federated barbican. If
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.
