From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Matt W. Benjamin" Subject: Re: Ceph authentication/authorization paradignms Date: Thu, 21 Aug 2014 12:44:22 -0400 (EDT) Message-ID: <1335181891.101.1408639462374.JavaMail.root@thunderbeast.private.linuxbox.com> References: <197304281.99.1408639382605.JavaMail.root@thunderbeast.private.linuxbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from aa.linuxbox.com ([69.128.83.226]:3642 "EHLO aa.linuxbox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752403AbaHUQo3 (ORCPT ); Thu, 21 Aug 2014 12:44:29 -0400 In-Reply-To: <197304281.99.1408639382605.JavaMail.root@thunderbeast.private.linuxbox.com> Sender: ceph-devel-owner@vger.kernel.org List-ID: To: Sage Weil Cc: "Christopher R. Hertel" , ceph-devel@vger.kernel.org, Gregory Farnum Sorry, s/RPCSEC_GSS/RPCSEC_GSSv3/. ----- "Matt W. Benjamin" wrote: > This approach/family of approaches is certainly the one taken by all > classical Kerberized file sharing systems, including AFS, DCE, and > NFSv4. > > There's a lot of new work just coming to fruition now in both the AFS > and NFSv4 communities (rxgk and RPCSEC_GSS, respectively) that are > specifically designed to handle important next-generation multi-party > authorization scenarios, and which I think we would be wise to at > least have a look at. > > Regards, > > Matt > > > > > > > Right. But you'll either need to plug Kerberos into the > > client<->mon > > > authentication pathways, or (this would be my naive choice) have > > some > > > sort of agent that Kerberos authenticates and then gives the > client > > > its CephX shared secret for authenticating with the monitors > > (without > > > the users having to get involved). Either way, there's at least a > > > little CephX integration going on, right? > > > Or am I completely off the mark with what you're trying to do > here? > > > > My thought is the former. We'd add a new CEPH_AUTH_* type, the > client > > > > side would call into kerberos and get a kerberos ticket to pass to > the > > > > mon, and the mon would call into kerberos to authenticate it. That > > would > > authenticate the session. > > > > I assume there will then be some futzing around to make things > behave > > so > > that the mon will provide the client cephx tickets for interactions > > with > > the rest of the cluster so that *only* the mon is doing non-cephx > > authentication. The focus now is just to make the first step work, > > > though... > > > > sage > > -- > > To unsubscribe from this list: send the line "unsubscribe > ceph-devel" > > in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > Matt Benjamin > The Linux Box > 206 South Fifth Ave. Suite 150 > Ann Arbor, MI 48104 > > http://linuxbox.com > > tel. 734-761-4689 > fax. 734-769-8938 > cel. 734-216-5309 > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" > in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Matt Benjamin The Linux Box 206 South Fifth Ave. Suite 150 Ann Arbor, MI 48104 http://linuxbox.com tel. 734-761-4689 fax. 734-769-8938 cel. 734-216-5309