Open Stack

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>wrote:

> Hi Carlos!
>
> Comments in-line:
>
>
> On Thu, May 1, 2014 at 7:24 PM, Carlos Garza <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#Loadbalancerwhere 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
>



-- 
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/20140502/67dd201b/attachment.html>