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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
