Open Stack

At the oslo-meeeting[1] on 11/7 we discussed a proposal[2] to enable message
signing and verification for oslo_messaging.rpc. The use-case for this is to
ensure that when RPC's are used with service VM's there is a possible attack
vector that involves a compromised service VM. While there are several other
mitigations that make this harder, adding message signing was felt to be an
added layer of protection.

The essence of the proposal is that asymmetric keys would be used to sign
and verify messages. A control plane keypair, and a keypair per service VM
would be used. Consumers of oslo_messaging.rpc would register callbacks in
the client and server, and a signing callback would be invoked for each
message that was to be sent and a verification callback would be invoked for
each message received. The manner of signing and verification would be left
up to the consumer. In the reference implementation, Trove would use
asymmetric keypairs for signing and verification to ensure that the message
was in fact from a legitimate source, and the source could be used to
further determine whether the message was appropriate or not.

At the meeting, the primary questions that I sought to address were:
    
• do we believe that it is still interesting to oslo to support message
signing and verification for oslo_messaging/rpc
• are we ok with an approach where oslo_messaging/rpc provides a framework
for consumers to define the signer and verifier, and not directly perform
the signing and verification

The discussion at the meeting (transcript at [1]) surfaced the following:
    
• the use of oslo_messaging/rpc by service vm's is not a pattern that is
favored; service vm's should instead make calls to a REST API or some kind
of service hook to inform the controlling service to then poll the service
VM, 
• there is no necessity to do the message signing and verification in
oslo.messaging, it can be done using a decorator in the consumer,
• while signing and verification can be done in the consumer, it is much
cleaner and makes handling upgrades much easier if it was done in
oslo.messaging as oslo_messaging.rpc could treat the signature as special
message metadata which the consumer cannot do; all the consumer can do is
insert and manipulate formal parameters to an RPC call,
• trove should have a conversation with the architecture working group to
see if there are improvements in the architecture that could address some of
the problems faced,
• if signing were implemented in oslo.messaging, the entire message
(including version, and other fields like namespace) can be signed; if it
were implemented in the consumer, not all fields can be signed. Furthermore,
if signing and verification were driven from oslo.messaging, the impact on
consumers would be dramatically lower, and handling of upgrades would also
be much easier.

It was my take-away from the meeting that the proposed use-case did not seem
like a sufficient reason to introduce message signing and verification into
oslo_messaging.rpc, at this stage. I'll take the recommendations of the
meeting and instead implement this using the decorators and hooks proposed
and the implementation will not be part of oslo.

Thanks,

-amrith

[1]
http://eavesdrop.openstack.org/meetings/oslo/2016/oslo.2016-11-07-16.00.log.
html
[2] https://etherpad.openstack.org/p/secure-oslo-messaging

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4805 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161107/160665e3/attachment.bin>