Cephx kerberization support

Cephx kerberization support

[Daniel Oliveira]

Hi All,  

We have been *brainstorming* on how to get "Cephx kerberization
support" done. From the initial ideas: a) GSSAPI based protocol; b)
Some sort of native Krb5 Cephx support, which means a need for a Krb5
authorizer along with some channel bindings (due to ULP principals),
where the latter seems to be a good/best approach.

As this is an important topic and we would like to discuss it during
our next CDM, your ideas and interest are greatly appreciated. 

Thanks,
-Daniel 

Re: Cephx kerberization support

[Sage Weil]

Hi Daniel,

On Tue, 23 Aug 2016, Daniel Oliveira wrote:
> Hi All,  
> 
> We have been *brainstorming* on how to get "Cephx kerberization
> support" done. From the initial ideas: a) GSSAPI based protocol; b)
> Some sort of native Krb5 Cephx support, which means a need for a Krb5
> authorizer along with some channel bindings (due to ULP principals),
> where the latter seems to be a good/best approach.
> 
> As this is an important topic and we would like to discuss it during
> our next CDM, your ideas and interest are greatly appreciated. 

Looking forward to it!

Kerberization is a pretty broad project.  FWIW I see it breaking down into 
several pieces/steps/possibilities:

1. Create a krb[5] auth method (alongside cephx and none) that can be used 
for authentication with the monitor.  That is, the client will use the krb 
library to get a ticket, send it over the wire to the monitor, and the 
monitor will use the library to authenticate it.  

Questions:
 - how do we map the kerberos identity to a ceph identity?

2. Static mapping support: have some configuration in the mon that maps 
your kerberos identity onto a ceph user so that you get their 
capabilities.  Maybe it's client.krb.$id or something, or maybe there is 
some mapping table?

3. LDAP support.  Have the mon look up the identity w/ LDAP to determine 
either (a) what your ceph capability are or (b) what group/user defined in 
cephx we can map you to to inherit their capabilities.  For (a), that 
would mean the caps go directly in LDAP (e.g., osd = allow rw, mds = allow 
r).  For (b), we'd probably map the kerberos identity to a predefined role 
(e.g., client.role.foo) that is defined the capabilities in the mon auth 
database.

4. Parse the ActiveDirectory PAC (?) so that we extra our group membership 
or capabilities from that directly.

For a minimal demonstration I think we need #1 and any of #2-4.  This 
would let a krb person on the command line invoke the ceph CLI for basic 
admin operations.

5. Have the mon then switch to cephx for the remainder of the session.  
This would make the whole thing useful for operations beyond the monitor 
(e.g., rbd CLI) with minimal additional work.

6. Full kerberos support for client/daemon auth.  This involves generating 
and authenticating a few different types of tickets, including creating 
the rotating tickets the daemons use.  It would fully replace/displace 
the cephx auth code.  This is probably where we'd want to end up on the 
cluster side.

7. CephFS support.  This is complicated because a host mounts the file 
system, but individual kerberos-authenticated users will come and go.  
The client->MDS protocol will need to be extended to set up and tear down 
these authenticated identities, map requests to an authorized user, etc.


I suspect we should start with #1 and #2 since it's the simplest to get 
going.  Then #3.  This will require lots of discussion around design since 
we'd need to figure out how to define group membership or raw capabilities 
in the LDAP schema.  Whether we do #5 or #6 depends on how weird it'd be 
for the client to switch between auth methods and whether we think #6 
(full kerberization) is inevitable.

What am I missing?

Thanks!
sage

Re: Cephx kerberization support

[Marcus Watts]

I think the two most challenging bits of integrating kerberos in w/
ceph will be dealing with authorization and dealing with keytabs.

So the keytab thing is simple.  kerberos entirely uses symmetric
encryption so it requires each host or service have a keytab.  Possession
of the keytab = ability to impersonate anyone (to that host and/or service);
hence needs to be suitably protected.  Deploying an additional osd/mon
requires properly creating or propagating a keytab to that host.  This is
just a provisioning problem, and is not really any different than cephx
of course.

Authorization is more complex.  ldap is one way to go, and particularly
for enterprise environments with lots of users, has lots of obvious
advantages.  So, for external identities, this is certainly what you want.
You probably don't want these things replicated to a "ceph identity"
or have a separate identity database replicating what ldap does for this.
At the same time, you are probably going to want a least a bit of
logic between ldap, because ldap dn's and groups are
not a thing of obvious beauty for storage acls, or, really,
ldap gives you way more rope than you want.

For internal identities (ie, the various bits of ceph as they talk to each
other) - ldap may not be a good choice.  For these you might find a more
special purpose local data store that's probably more strictly internal
to ceph to be appropriate for this.  The choices you make above for
the keytab (per host or per service) will influence your choices here.
If you go with a single global per-service key (no per-host...) for
instance, then you your internal identity authorization needs become
very simple: either it knows the per-service key (and is "god") or it
doesn't.  If you go with finer grained keytabs, then you can be somewhat
more elaborate in your security choices.

					-Marcus Watts

Re: Cephx kerberization support

[Sage Weil]

On Fri, 2 Sep 2016, Marcus Watts wrote:
> I think the two most challenging bits of integrating kerberos in w/
> ceph will be dealing with authorization and dealing with keytabs.
> 
> So the keytab thing is simple.  kerberos entirely uses symmetric
> encryption so it requires each host or service have a keytab.  Possession
> of the keytab = ability to impersonate anyone (to that host and/or service);
> hence needs to be suitably protected.  Deploying an additional osd/mon
> requires properly creating or propagating a keytab to that host.  This is
> just a provisioning problem, and is not really any different than cephx
> of course.

Yeah, AFAICS this is equivalent to the current ceph keyring.

> Authorization is more complex.  ldap is one way to go, and particularly
> for enterprise environments with lots of users, has lots of obvious
> advantages.  So, for external identities, this is certainly what you want.
> You probably don't want these things replicated to a "ceph identity"
> or have a separate identity database replicating what ldap does for this.
> At the same time, you are probably going to want a least a bit of
> logic between ldap, because ldap dn's and groups are
> not a thing of obvious beauty for storage acls, or, really,
> ldap gives you way more rope than you want.

Yeah.  Again, I see several options here:

1) No LDAP.  Create a ceph auth entry for each kerberos identity.  Trivial 
but lame.

2) LDAP maps identity into a dn/group whatever.  Create a ceph auth 
entry for the dn/group (role).

3) ActiveDirectory PAC(?).  It sounds like this is also not well defined.

I think #2 is probably the most useful/promising.  And hopefully even 
with AD there is some standardish way to map an identity into a group 
in the PAC payload that could be used?

> For internal identities (ie, the various bits of ceph as they talk to each
> other) - ldap may not be a good choice.  For these you might find a more
> special purpose local data store that's probably more strictly internal
> to ceph to be appropriate for this.  The choices you make above for
> the keytab (per host or per service) will influence your choices here.
> If you go with a single global per-service key (no per-host...) for
> instance, then you your internal identity authorization needs become
> very simple: either it knows the per-service key (and is "god") or it
> doesn't.  If you go with finer grained keytabs, then you can be somewhat
> more elaborate in your security choices.

Even with cephx there are two types of keys/tickets.  Each daemon has a 
fixed symmetric key that it uses to authenticate itself.  Then there is a 
rotate globalish "service key" that is shared amongst all OSDs (or MDSs) 
that clients tickets are authenticated against.  With cephx we rotate it 
every hour or something.

I'm guessing we want to do essentially the same thing, but just use the 
kerberos libraries to create the keys and tickets.  We can reuse all of 
the existing infrastructure for handling key rotation and so on.  The 
service keys are only kept in RAM on the daemons, so I don't think keytabs 
needs to get involved, although I suppose that depends on how the kerberos 
library API is used when you're asking it to authenticate a ticket 
we got from a client...

sage

Re: Cephx kerberization support

[Matt Benjamin]

Hi,

----- Original Message -----
> From: "Sage Weil" <sage@newdream.net>
> To: "Marcus Watts" <mwatts@redhat.com>
> Cc: ceph-devel@vger.kernel.org, "Daniel Oliveira" <doliveira@suse.com>
> Sent: Friday, September 2, 2016 10:14:38 AM
> Subject: Re: Cephx kerberization support
> 

> 
> 3) ActiveDirectory PAC(?).  It sounds like this is also not well defined.

The PAC is well defined (though extensions from Kitten WG are more expansive), but iiuc, per se it's a means for propagating group (PAC) or other (e.g., SAML?, Kitten/cammac) authorization data in the tickets not an authorization schema per se.  I'm not certain if cammac really exists yet, and as regards PAC, we'd I guess need an AD implementation, which is probably more and less than we want to require.  otoh, it's not implausible (e.g., samba4 brings one).

> 
> I think #2 is probably the most useful/promising.  And hopefully even
> with AD there is some standardish way to map an identity into a group
> in the PAC payload that could be used?

I think MS PAC fully defines it--but non-AD environments won't have the sids and other attributes that ISTR it mainly contains.  I think for non-AD cammac we'd be free to import what we like (though I think this is blue sky), but it would be possible for services to query whatever the underlying setup (e.g, LDAP dit) for authz when !MS PAC.  That's what what AFS and DCE do, at any rate.

> 
> > For internal identities (ie, the various bits of ceph as they talk to each
> > other) - ldap may not be a good choice.  For these you might find a more
> > special purpose local data store that's probably more strictly internal
> > to ceph to be appropriate for this.  The choices you make above for
> > the keytab (per host or per service) will influence your choices here.
> > If you go with a single global per-service key (no per-host...) for
> > instance, then you your internal identity authorization needs become
> > very simple: either it knows the per-service key (and is "god") or it
> > doesn't.  If you go with finer grained keytabs, then you can be somewhat
> > more elaborate in your security choices.
> 
> Even with cephx there are two types of keys/tickets.  Each daemon has a
> fixed symmetric key that it uses to authenticate itself.  Then there is a
> rotate globalish "service key" that is shared amongst all OSDs (or MDSs)
> that clients tickets are authenticated against.  With cephx we rotate it
> every hour or something.
> 
> I'm guessing we want to do essentially the same thing, but just use the
> kerberos libraries to create the keys and tickets.  We can reuse all of
> the existing infrastructure for handling key rotation and so on.  The
> service keys are only kept in RAM on the daemons, so I don't think keytabs
> needs to get involved, although I suppose that depends on how the kerberos
> library API is used when you're asking it to authenticate a ticket
> we got from a client...

That would be a pretty unusual way to integrate things (preventing use of existing tools, among other things), fwiw.

> 
> sage

Matt

-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309