Jump to: navigation, search

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

(Related Articles)
(Proxy)
 
(3 intermediate revisions by 2 users not shown)
Line 40: Line 40:
  
 
2. Crypto Driver  
 
2. Crypto Driver  
 +
 +
We have also found that the community might be working on a related solution to this already.
 +
Posted in the 'Related Articles' section are two projects that appear to be working on a solution
 +
to automatically federate resources between multiple clouds. There is a more in in depth explanation
 +
in the 'Related Articles' section.
  
  
Line 46: Line 51:
 
[[File:Proxy_Implementation.png|1000px|thumb|center]]
 
[[File:Proxy_Implementation.png|1000px|thumb|center]]
  
The proxy proposal offloads all of the Federated Keystone work onto the proxy server.  
+
The proxy proposal offloads all of the Federated Keystone work onto a proxy server.  
The proxy would handle the authentication to the separate keystone and then forward the  
+
The proxy would handle the keystone to keystone federation and forward the Barbican request
request to the separate Barbican using the new token it received from keystone.  
+
to the correct Barbican server.
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
+
The plugin can be controlled via a variable in the barbican.conf file.
set to false.  
+
When "proxy_enabled" is set to true and then the proxy is started.  
  
 
There are still 2 problems:  
 
There are still 2 problems:  
Line 101: Line 106:
 
== Comments ==
 
== 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 <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?
+
* arunkant- 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 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?
 
**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.
 
**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.

Latest revision as of 20:07, 9 November 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.


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
  • 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.

There are two ideas that myself, diazjf, and edtubill have been working on:

1. Proxy redirect

2. Crypto Driver

We have also found that the community might be working on a related solution to this already. Posted in the 'Related Articles' section are two projects that appear to be working on a solution to automatically federate resources between multiple clouds. There is a more in in depth explanation in the 'Related Articles' section.


Proxy

Proxy Implementation.png

The proxy proposal offloads all of the Federated Keystone work onto a proxy server. The proxy would handle the keystone to keystone federation and forward the Barbican request to the correct Barbican server.

The plugin can be controlled via a variable in the barbican.conf file. When "proxy_enabled" is set to true and then the proxy is started.

There are still 2 problems: 1. There needs to be a way to determine if the request should be forwarded at all. 2. There would still need to be a way to tell the proxy where the barbican it needs to forward the request to resides.

Problem one does not seem very problematic. A new optional parameter could be added to the client, ex: --federated, which notifies the proxy to forward the request to a federated Barbican instead. I think -f is actually already taken by the client so the flag would need to be something different.

Problem two is the more challenging one. The proxy needs to know where to forward the request. There are a couple of ways to resolve this:

1. Store the location's of each barbican the user has access to

  • This would need to be more flushed out but the general idea is store the barbican's to which each tenant has access. Then

the proxy can handle all of the authorization in order forward the request to the correct barbican. There would be special cases such as what if a customer deploys multiple clouds and has access to multiple barbicans. It becomes trickier maintaining all of that data and handling the redirection.

2. Poll the IDP Keystone for each Service Provider to which it has access.

  • From what I understand you can see a list of services you have access to on the Identity Provider, which in this case is keystone.

Keystone can present a list of services the user has access to, which in this case includes all the barbican's to which the user can federate. Then the proxy can check all available barbican's for the secret on gets and distribute the jobs equally on puts.


Those are two possible solutions we have been working onbut I'm really interested in getting other people's thoughts and ideas on this.

Crypto Driver

The Driver would be similar to the Proxy in almost every way. The only difference is that instead of sitting in front of Barbican the driver would sit on top of the crypto device. Hence the redirection and authentication to federated keystone takes place after the API call has already begun to be filtered through barbican's pipeline. Essentially the proxy functionality would be handled on Barbican itself using a driver that can be turned on or off using the configuration file.

Related Articles

Special thanks to Steve Martinelli for relaying this information. There appears to be a group at Boston University who is working on something similar such as setting up Federated access between multiple clouds that can all bring up a single public cloud with shared services from different clouds.

Mix-And-Match-Federation

It looks like there's also a project called Mercador which is a system for federating independent OpenStack Clouds.

Project Mercador

They have meetings scheduled Fridays at 1700 UTC time. I'll try to attend these meetings and see what they are up to and maybe start asking around for how this could help with Barbican.

Comments

  • arunkant- 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.