> On Jun 28, 2018, at 8:27 PM, Gregory Farnum <gfarnum@xxxxxxxxxx> wrote: > > On Wed, Jun 27, 2018 at 5:28 AM, Sage Weil <sweil@xxxxxxxxxx> wrote: >> The idea is to lock an authentication key (e.g., client.foo) so that it is >> only usable from a specific host or network. At a minimum, it would mean >> modifying the MonCap to include a host field with a CIDR network/mask. >> For example, >> >> [client.foo] >> key = ... >> caps mon = allow profile rbd host 1.2.3.4/32 >> caps osd = allow profile rbd >> >> https://pad.ceph.com/p/pin_caps_to_network >> >> I see two options, one easy and one slightly harder. The first is we only >> add the host restriction to the mon cap, under the reasoning that if you >> can't get tickets from the mon then you can't talk to everyone else >> anyway, and if you do and then tunnel your OSD session (or whatever) >> through a different network who really cares. The second is that we add >> the host clause to OSDCap and MDSCap too, just because. >> >> Does this seems like a reasonable approach? > > I think if we’re going to do this we should enforce the IP check on > every daemon. It’s better for defense in depth. > That does leave us with two options though: 1) we just invisibly > propagate the IP check from the monitor cap (or some non-specific > cap?) into all the others either when we import it or when we hand out > the cephx bundle, or 2) we let users specify a source IP in each > daemon cap they want to check it on. > > (1) is simple for users to understand and safer, in that they can’t > mess it up. But (2) allows more fine-grained stuff that might be > useful in weird network layouts? Network layouts in highly virtualized environments can get weird, can’t they? Having said that, the OSDCap and MDSCap grammars really need to be overhauled. They’re hard to parse correctly and they’re hard enough to write correctly that we even implemented a workaround for MDSCap that makes them easier for users to specify. If MONCap is simple enough, it doesn’t hurt to start with (1) and then get to (2) as a part of an OSD/MDS cap overhaul. Cheers, —Doug > -Greg > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
