Open Stack

Hi,

Such use cases are in essence using affinity and anti-affinity policies.
Please consider that way Nova is handling this: https://wiki.openstack.org/wiki/InstanceGroupApiExtension

Regards,
                -Sam.



From: Stephen Balukoff [mailto:sbalukoff at bluebox.net]
Sent: Saturday, May 03, 2014 6:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS]User Stories and sruvey

On other thing:

If it helps, instead of calling that thing a 'load balancer' in my model and API, since I know there's some contention on what that term should mean in the context of this discussion, it might be more illustrative to think of it as a "VIP Group."

And to define what this means:


  *   Different VIP Groups do not share physical or virtual load balancing infrastructure
  *   VIPs within a VIP Group can be assumed to share availability properties (ie. if you have two VIPs and want to make sure that at least one of these is available at all times, they need to be in different VIP Groups)
  *   VIPs within a VIP Group might compete for performance on the physical infrastructure. VIPs in different VIP Groups do not compete for performance this way.
  *   VIP Groups might be implemented as processes on different neutron networking nodes, or different physical appliances, or different virtual appliances, or groups of physical or virtual hardware that work together to serve a common purpose that can be treated as a single entity.
  *   VIP Groups have a "flavor" that ultimately gets defined by the operator. This flavor defines the availability, security, performance, etc. of the devices or software that make up the load balancing services.

Stephen

On Fri, May 2, 2014 at 7:26 PM, Stephen Balukoff <sbalukoff at bluebox.net<mailto:sbalukoff at bluebox.net>> wrote:
Hi Carlos!

Comments in-line:

On Thu, May 1, 2014 at 7:24 PM, Carlos Garza <carlos.garza at rackspace.com<mailto:carlos.garza at rackspace.com>> wrote:
     Balukoff I'm liking your API spec so far but can you elaborate on what this loadbalancer object you refer to is. on page You declare its immutable and refer to it like an actual primitive object yet I don't
see a schema for it. I see loadbalancer_id in the vip request that reference. The top part of the doc declares a loadbalancer is is the first object created according to the definition in the glossary.
https://wiki.openstack.org/wiki/Neutron/LBaaS/Glossary#Loadbalancer where it is defined as the root Object that is first created or can be fully populated but in you API proposal it looks like the vip object is the created top level primitive with flavor attribute is apart of a VIP. Are you intending to rename what we call a loadbalancer to a VIP? Could you provide a work flow of a created loadbalancer. It looks good either way.

I interpret the part of the definition saying:

 "An object that represent a logical load balancer that may have multiple resources such as Vips, Pools, Members, etc. Loadbalancer is a root object in the meaning described above. "

...to mean that a load balancer is a container for all of the above primitives (VIPS, Listeners, Pools, Members, etc.) This is analogous to a physical device, though it doesn't necessarily need to be a physical device (it could be a process on the neutron controller, or it could be a whole grouping of physical devices that work together to serve a singular purpose). I included it in my API document as a "placeholder" of sorts to signify how the User API we're defining might interface with an Operator / Management API we have yet to define. Mostly, I was trying to capture the idea that different VIPs might have different "flavors" defined by the operator that essentially constitute different load balancing products that the operator makes available to the user, as well as the idea that VIPs probably exist in logical groupings within the load balancing infrastructure somehow. For certain kinds of users, colocation or apolocation of VIPs within these groupings of load balancing infrastructure is important.  (See use cases 11 and 12 in the use cases document for a couple examples we see with some regularity.)

The API I've proposed includes no notion of how to create a 'load balancer' in this sense because this is primarily an operator concern, and we've yet to have an in-depth discussion of the nitty-gritty details of operator concerns. Rather, my API assumes that "somehow load balancers exist" and takes it from there.

In any case, we can remove the notion of this kind of 'load balancer' from my API proposal for evaluation (since it doesn't really affect much for the user), and potentially add something like it back in later when we start to talk more in-depth about operator concerns.

Is it cool if we rename ca_certificate_id to client_ca or client_ca_certificate to make it clear the purpose of the CA is to snub clients. Later on if we need to do encryption to back end pool members that have x509s signed by their own CA we can then use a parameter like reencryption_ca_certificate.

Yep! I'm all for names that make concepts more obvious and/or remove confusion from the conversation. :)

Consider the following cases.

The user wants SSL_ID based persistence on an HTTPS LoadBalancer where the loadbalancer does not know the key or cert but has access to the unencrypted RFC5246: 7.4.1.2 uncrypted Session ID
to identify persistence to the back end HTTPS pool member?

On the pool side of the loadbalaancer can a loadbalancer still encrypt if no ca_certificate_id or client_certificate_id is present? How would they signal to the api that they extend to encrypt with out host name validation or even vert validation at all. Not sure why they would want to other then they don't feel the need to pay for certs on their backend nodes or worse yes pay for a signing cert.

No. If the load balancer didn't decrypt the SSL session with the web client on the front-end, then it makes no sense to try to re-encrypt on the back end. Futher, it also makes no sense for the load balancer to attempt verification of the back-end members' server certificates.

So, if you're asking whether those attributes only make sense when decrypting the SSL session on the front end the answer is: yes.  For all intents and purposes, not decrypting on the front end means that the session is essentially treated like a raw TCP session to the back end, with the slight difference that the load balancer can see the Session ID in order to do session persistence properly.

Note that my API proposal doesn't yet include a flag to indicate whether the load balancer should attempt decryption / re-encryption. Part of this is because I wasn't aware of this form of session persistence and therefore thought a non-decrypted HTTPS configuration would look identical to a raw TCP configuration...  However, even without this flag the notion of whether to decrypt can be determined implicitly like so:

  *   If the listener protocol is HTTPS and there is no default_server_certificate_id, then the load balancer should treat the connection like a TCP session and not attempt to decrypt, re-encrypt or verify client or server certificates anywhere.
  *   If the above point is true, and the session persistence attribute on the pool is set to 'SSL_SESSION_ID', then the load balancer should try to use the RFC5246: 7.4.1.2 uncrypted Session ID information for persistence.
If people think it's still worthwhile to have the flag (so users can easily toggle on and off decryption on the listener), it would be trivial to add this attribute to the Listener object.  What do y'all think?

The user feels secure on their network and wants SSL termination at the loadbalancer so the loadbalancer has the Cert and Key and extends to use plain old HTTP to the pool members with some headers injected. What would the protocol on the listener be "HTTPS" and would placing a CERT and KEY imply deception should happen.

Yes, the protocol on the listener would be HTTPS still. I'm not sure what you mean by "placing a CERT and KEY". Are you talking about within the HTTP headers?

Also I've been burned in an earlier project when I started noticing some CA's were using ECDSA certs instead of RSA? should we take non RSA x509s into account as well? Right now it looks like the API assumes everything is RSA.

Yeah, the API does assume everything is RSA right now. I've never been handed ECDSA certs before-- can they be converted? In any case, if we want to natively support different certificate types, this can be done by adding a 'certificate_type' attribute to the TLS_Certificate object, and presumably some detection logic when the user uploads a new cert.

Oh! One other thing: I've had a little bit of time to get an overview of barbican. From what I can tell, their main purpose is to provide a "secure" storage engine for storing any kind of sensitive information (not just RSA private keys or what have you).  I'm all for using this to store private keys instead of inventing our own system here, as I think they'll be able to do a better job in general of maintaining the security of the secrets they store since that's the whole purpose of the project. (I think it's still fine for us to store public certificates sans their private keys ourselves since that's... well, public information.)

Note that using barbican this way does introduce a couple other failure scenarios that we'll need to worry about:  Specifically, because the user is capable of deleting or changing private key data outside of the workflow or knowledge of the LBaaS API, this means that we can run into scenarios where the user wants to push a change, but the private key data might be unavailable. This can break all kinds of stuff, (especially around automated tasks having to do with orchestration and auto-scaling). So... we need to carefully consider how to handle this failure scenario if we're going to use Barbican.

Thanks,
Stephen


--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807<tel:%28800%29613-4305%20x807>



--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140504/effddf79/attachment.html>