On Tue, 12 Jun 2012, John Axel Eriksson wrote: > Thanks alot for your input Sage! > > I get a feeling that this is good for a larger cluster, especially > when you have many people logging in - some without root access. > We are currently a VERY small company (two people have logins and root > access - noone else has a login at all). We've been running > another distributed object storage solution for quite some time which > has no authentication whatsoever and it has worked just fine for > us. Now we're looking for a replacement since we're not entirely happy > with our current solution - it hasn't been entirely stable and we've > lost data twice. > > I guess we could simply start off without authentication and later on > enable it if we do need it. Is that relatively easy to do in a running > cluster? Yes. The doc linked below outlines the steps that will be needed. > Also is there a good place where I could read up on exactly what > happens if an OSD or something else fails? For example with the > default two replicas - will that data be copied to another OSD if one > fails, do I have to manually do anything, can I read the data as long > as there is one copy somewhere? http://ceph.com/docs/master/ops/manage/failures/ has lots of information about managing and diagnosing failures. If there are gaps, please let us know! sage > > john > > On Tue, Jun 12, 2012 at 6:56 PM, Sage Weil <sage@xxxxxxxxxxx> wrote: > > A few things that Wido missed: > > > > On Tue, 12 Jun 2012, John Axel Eriksson wrote: > > > >> I asked a similar question in a previous email but I didn't get any > >> satisfying answers. What exactly does cephx auth secure? > >> >From the wiki I just get "this makes your cluster more secure", well > >> from what? If I run on an internal network accessible only > >> by a few trusted people - what does cephx auth secure in such a scenario? > > > > There is some very preliminary docs at > > > > http://ceph.com/docs/wip-auth/ops/manage/security/ > > > > Basically: > > > > * mutual authentication between client and server > > * capabilities limiting what clients are allowed to do > > > > But: > > > > * no encryption of over-the-wire communications > > * no protection from hijacked TCP sessions (although simpler > > man-in-the-middle attacks aren't possible) > > > >> In that previous email I got the answer that it secures the cluster > >> from mistakenly connecting to wrong cluster with rados and > >> accidentally deleting a pool... well, can rados really "accidentally" > >> connect to the wrong cluster? > > > > The client can accidentally connect to the wrong cluster if fed the > > wrong monitor address or config. > > > >> Only if I have the wrong config > >> file right? And if I have the wrong config-file won't it be possible > >> that I also have the "wrong" key in that case? > > > > Yes. > > > > That said, daemons are careful to validate the cluster fsid before > > communicating regardless of whether cephx is enabled or not. > > > > You *can* put fsid = ... in the config file, but the client side isn't > > validating it currently, and that won't help if you point at the wrong > > config file. > > > >> Another scenario would be if I take down an OSD that just sits in > >> storage for say 6 months and then someone starts that machine > >> again - with key-based auth that OSD wouldn't be able to > >> connect(somehow? but if it has a working key?) but without auth it > >> could > >> possibly connect and wreak havoc in the cluster (since it is so much > >> behind perhaps in both version of software and what's stored on it). > >> I thought marking and OSD as down or out would do that? > > > > Marking out manually will prevent the osd from being marked in > > automatically, but it will still start up and 'join' the cluster. > > However, whenever there is an incompatible change, we bump protocol > > numbers or add feature fits, so it shouldn't be able to do any damage. > > > > I think the main motivation is to prevent a non-root user from, say, > > deleting your data pool, or to limit such 'admin' activity to a select > > number of nodes (e.g., the monitor hosts). > > > > sage > > > >> Are those the main reasons for having cephx auth? Is it to secure the > >> cluster against people (myself included) making mistakes or from > >> hacking, or is there some technical reason that I don't know of or understand? > >> > >> The reason I'm asking is because having cephx enabled makes cluster > >> setup much more complicated... > >> > >> > >> Thanks, > >> > >> John > >> -- > >> 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 > >
