settingsLogin | Registersettings

[openstack-dev] [oslo][trove][dev] oslo_messaging.rpc message signing and verification

0 votes

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 oslomessaging/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 oslomessaging/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
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.




OpenStack Development Mailing List (not for usage questions)

asked Nov 7, 2016 in openstack-dev by Amrith_Kumar (10,500 points)   2 4 4
retagged Jan 26, 2017 by admin

1 Response

0 votes

Excerpts from Amrith Kumar's message of 2016-11-07 21:00:06 +0000:

  • 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,

I think this is a bit premature for the arch-wg, though I think there is
something for us to do here. What may make sense is to propose that we
dive into documenting and possibly improving how agents for service vms
behave in general, as I suspect this is definitely one of those things
where a multitude of projects have come up with slightly different
patterns that all have the same inputs and outputs.

However, for now it's not in our list of proposals. We're still getting
our proposal process up and running, but it would be great to bring this
up at our next meeting for discussion, and then we might want to get a
proposal started moving through the tubes:

OpenStack Development Mailing List (not for usage questions)
responded Nov 8, 2016 by Clint_Byrum (40,940 points)   4 5 9