Open Stack

Hi all,

To implement kite we need the ability to sign and encrypt the message and the
message data. This needs to happen at a very low level in the oslo.messaging
stack. The existing message security review
(https://review.openstack.org/#/c/109806/) isn't going to be sufficient. It
allows us to sign/encrypt only the message data ignoring the information in the
context and not allowing us to sign the message as a whole. It would also
intercept and sign notifications which is not something that kite can do.

Mostly this is an issue of how the oslo.messaging library is constructed. The
choice of how data is serialized for transmission (including things like how
you arrange context and message data in the payload) is handled individually by
the driver layer rather than in a common higher location. All the drivers use
the same helper functions for this and so it isn't a problem in practice.

Essentially I need a stateful serializing/deserializing object (I need to store
keys and hold things like a connection to the kite server) that either extends
or replaces oslo.messaging._drivers.common.serialize_msg and deserialize_msg
and their exception counterparts.

There are a couple of ways I can see to do what I need:

1. Kite becomes a more integral part of oslo.messaging and the marshalling and
verification code becomes part of the existing RPC path. This is how it was
initially proposed, it does not provide a good story for future or alternative
implementations. Oslo.messaging would either have a dependency on kiteclient,
implement its own ways of talking to the server, or have some hack that imports
kiteclient if available.

2. Essentially I add a global object loaded from conf to the existing common
RPC file. Pro: The existing drivers continue to work as today, Con: global
state held by a library. However given the way oslo messaging works i'm not
really sure how much of a problem this is. We typically load transport from a
predefined location in the conf file and we're not really in a situation where
you might want to construct different transports with different parameters in
the same project.

3. I create a protocol object out of the RPC code that kite can subclass and
the protocol can be chosen by CONF when the transport/driver is created. This
still touches a lot of places as the protocol object would need to be passed to
all messages, consumers etc. It involves changing the interface of the drivers
to accept this new object and changes in each of the drivers to work with the
new protocol object rather than the existing helpers.

4. As the last option requires changing the driver interface anyway we try and
correct the driver interfaces completely. The driver send and receive functions
that currently accept a context and args parameters should only accept a
generic object/string consisting of already marshalled data. The code that
handles serializing and deserializing gets moved to a higher level and kite
would be pluggable there with the current RPC being default.

None of these options involve changing the public facing interfaces nor the
messages emitted on the wire (when kite is not used).

I've been playing a little with option 3 and I don't think it's worth it. There
is a lot of code change and additional object passing that I don't think
improves the library in general.

Before I go too far down the path with option 4 I'd like to hear the thoughts
of people more familiar with the library.

Is there a reason that the drivers currently handle marshalling rather than the
RPC layer?

I know there is ongoing talk about evolving the oslo.messaging library, I
unfortunately didn't make it to the sessions at summit. Has this problem been
raised? How would it affect those talks?

Is there explicit/implicit support for out of tree drivers that would disallow
changing these interfaces?

Does anyone have alternative ideas on how to organize the library for message
security?

Thanks for the help.


Jamie