Open Stack

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#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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140502/1b75cce9/attachment.html>