Re: [openstack-dev] [Neutron][LBaaS] Interaction with Barbican and Keystone
Hi Adam, For me the thing needs to be user friendly. So my main question is how do things look in Horizon? Will there just be a popup saying Establish Trust (Y/N). I am wondering as you how other teams are handling that... Thanks, German -Original Message- From: Adam Harwell [mailto:adam.harw...@rackspace.com] Sent: Thursday, September 18, 2014 3:16 PM To: OpenStack Development Mailing List (not for usage questions) Cc: sbaluk...@bluebox.net; Doug Wiegley; Eichberger, German; Adam Young; Balle, Susanne; Douglas Mendizabal Subject: [openstack-dev] [Neutron][LBaaS] Interaction with Barbican and Keystone I've made an attempt at mapping out exactly how Neutron Advanced Services will communicate with Barbican to retrieve Certificate/Key info for TLS purposes. This is far from solidified, since there are some issues that I'll go over momentarily. First, here is a *high level* diagram of the process flow: http://i.imgur.com/VQcbGJS.png (I use the term hijack purposefully) And here is a more detailed flow, including each and every operation: http://goo.gl/Wc8oIj There are some valid concerns about this workflow, and at least one issue that may be a blocker. Following are the two main issues that I've run into: 1) Possible blocker: Keystone won't allow Trust creation using a Trust Token. Example: A user creates a Trust for Heat, and gives Heat their TrustID. The user configures Heat to spin up Load Balancers. Heat contacts LBaaS on behalf of the user with a Trust Token. LBaaS contacts Keystone to create a Trust using the token received from Heat. LBaaS would be unable to create a Trust because the Token we're trying to use doesn't have the ability to create Trusts, and our operation would fail. 2) Security concern: If the Neutron/LBaaS config contains a Service Account's user/pass and Database URI/user/pass, then anyone with access to the config file would be able to connect to the DB, pull out TrustIDs, and use the Neutron Service Account to execute them. Essentially, the only difference between storing private keys directly in the database and storing them in Barbican is that there's one additional (trivial) step to get the key data (contact the Barbican API). The keystone folks I talked to (primarily Adam Young) suggested that the solution to issue #1 is to require the user to create the Trust beforehand in Keystone, then pass the TrustID to Neutron/LBaaS along with the ContainerID. This could originally be based on a template we provide to the user, probably in the form of a suggested JSON body and keystone URI. Eventually, there could/should/might be a system in place to allow services to pre-define a Trust with Keystone and the user would just need to tell Keystone that they accept that Trust. Either way, this would require action by the user before they could create a TLS Terminated LB. I don't particularly LIKE that option, but if 90% of our users come through Horizon anyway, it should be as simple as having Horizon pop up a Yes/No box prompting to enable the Trust when the user creates their first TLS LB. As for issue #2, I don't really have a solution to propose. There was some talk about the Postern project, but there isn't really any usable code yet, or even solid specs from what I can tell -- it looks like the project was proposed and never went past the PoC stage. https://github.com/cloudkeep/postern I know there are some other teams looking into very similar issues, so I have a bit of research to do on that front, but in the meantime, what are people's thoughts? I've cc'd a few of the people who were already in the IRC version of this discussion (I may have missed anyone who wasn't already in my address book, sorry), but I'd love to hear from anyone who has ideas on the subject. --Adam https://keybase.io/rm_you ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Interaction with Barbican and Keystone
Yeah, I was hoping for something like that... Essentially, Horizon would need to detect that particular response and be prepared to make a simple Yes/No dialog pop up to create that Trust, then continue with the original operation again automatically afterwards. That said, I have not looked at programming Horizon interfaces at all yet, so I don't know how feasible that is. --Adam https://keybase.io/rm_you On 9/24/14 5:02 PM, Eichberger, German german.eichber...@hp.com wrote: Hi Adam, For me the thing needs to be user friendly. So my main question is how do things look in Horizon? Will there just be a popup saying Establish Trust (Y/N). I am wondering as you how other teams are handling that... Thanks, German -Original Message- From: Adam Harwell [mailto:adam.harw...@rackspace.com] Sent: Thursday, September 18, 2014 3:16 PM To: OpenStack Development Mailing List (not for usage questions) Cc: sbaluk...@bluebox.net; Doug Wiegley; Eichberger, German; Adam Young; Balle, Susanne; Douglas Mendizabal Subject: [openstack-dev] [Neutron][LBaaS] Interaction with Barbican and Keystone I've made an attempt at mapping out exactly how Neutron Advanced Services will communicate with Barbican to retrieve Certificate/Key info for TLS purposes. This is far from solidified, since there are some issues that I'll go over momentarily. First, here is a *high level* diagram of the process flow: http://i.imgur.com/VQcbGJS.png (I use the term hijack purposefully) And here is a more detailed flow, including each and every operation: http://goo.gl/Wc8oIj There are some valid concerns about this workflow, and at least one issue that may be a blocker. Following are the two main issues that I've run into: 1) Possible blocker: Keystone won't allow Trust creation using a Trust Token. Example: A user creates a Trust for Heat, and gives Heat their TrustID. The user configures Heat to spin up Load Balancers. Heat contacts LBaaS on behalf of the user with a Trust Token. LBaaS contacts Keystone to create a Trust using the token received from Heat. LBaaS would be unable to create a Trust because the Token we're trying to use doesn't have the ability to create Trusts, and our operation would fail. 2) Security concern: If the Neutron/LBaaS config contains a Service Account's user/pass and Database URI/user/pass, then anyone with access to the config file would be able to connect to the DB, pull out TrustIDs, and use the Neutron Service Account to execute them. Essentially, the only difference between storing private keys directly in the database and storing them in Barbican is that there's one additional (trivial) step to get the key data (contact the Barbican API). The keystone folks I talked to (primarily Adam Young) suggested that the solution to issue #1 is to require the user to create the Trust beforehand in Keystone, then pass the TrustID to Neutron/LBaaS along with the ContainerID. This could originally be based on a template we provide to the user, probably in the form of a suggested JSON body and keystone URI. Eventually, there could/should/might be a system in place to allow services to pre-define a Trust with Keystone and the user would just need to tell Keystone that they accept that Trust. Either way, this would require action by the user before they could create a TLS Terminated LB. I don't particularly LIKE that option, but if 90% of our users come through Horizon anyway, it should be as simple as having Horizon pop up a Yes/No box prompting to enable the Trust when the user creates their first TLS LB. As for issue #2, I don't really have a solution to propose. There was some talk about the Postern project, but there isn't really any usable code yet, or even solid specs from what I can tell -- it looks like the project was proposed and never went past the PoC stage. https://github.com/cloudkeep/postern I know there are some other teams looking into very similar issues, so I have a bit of research to do on that front, but in the meantime, what are people's thoughts? I've cc'd a few of the people who were already in the IRC version of this discussion (I may have missed anyone who wasn't already in my address book, sorry), but I'd love to hear from anyone who has ideas on the subject. --Adam https://keybase.io/rm_you ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] Interaction with Barbican and Keystone
I've made an attempt at mapping out exactly how Neutron Advanced Services will communicate with Barbican to retrieve Certificate/Key info for TLS purposes. This is far from solidified, since there are some issues that I'll go over momentarily. First, here is a *high level* diagram of the process flow: http://i.imgur.com/VQcbGJS.png (I use the term hijack purposefully) And here is a more detailed flow, including each and every operation: http://goo.gl/Wc8oIj There are some valid concerns about this workflow, and at least one issue that may be a blocker. Following are the two main issues that I've run into: 1) Possible blocker: Keystone won't allow Trust creation using a Trust Token. Example: A user creates a Trust for Heat, and gives Heat their TrustID. The user configures Heat to spin up Load Balancers. Heat contacts LBaaS on behalf of the user with a Trust Token. LBaaS contacts Keystone to create a Trust using the token received from Heat. LBaaS would be unable to create a Trust because the Token we're trying to use doesn't have the ability to create Trusts, and our operation would fail. 2) Security concern: If the Neutron/LBaaS config contains a Service Account's user/pass and Database URI/user/pass, then anyone with access to the config file would be able to connect to the DB, pull out TrustIDs, and use the Neutron Service Account to execute them. Essentially, the only difference between storing private keys directly in the database and storing them in Barbican is that there's one additional (trivial) step to get the key data (contact the Barbican API). The keystone folks I talked to (primarily Adam Young) suggested that the solution to issue #1 is to require the user to create the Trust beforehand in Keystone, then pass the TrustID to Neutron/LBaaS along with the ContainerID. This could originally be based on a template we provide to the user, probably in the form of a suggested JSON body and keystone URI. Eventually, there could/should/might be a system in place to allow services to pre-define a Trust with Keystone and the user would just need to tell Keystone that they accept that Trust. Either way, this would require action by the user before they could create a TLS Terminated LB. I don't particularly LIKE that option, but if 90% of our users come through Horizon anyway, it should be as simple as having Horizon pop up a Yes/No box prompting to enable the Trust when the user creates their first TLS LB. As for issue #2, I don't really have a solution to propose. There was some talk about the Postern project, but there isn't really any usable code yet, or even solid specs from what I can tell -- it looks like the project was proposed and never went past the PoC stage. https://github.com/cloudkeep/postern I know there are some other teams looking into very similar issues, so I have a bit of research to do on that front, but in the meantime, what are people's thoughts? I've cc'd a few of the people who were already in the IRC version of this discussion (I may have missed anyone who wasn't already in my address book, sorry), but I'd love to hear from anyone who has ideas on the subject. --Adam https://keybase.io/rm_you ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
