On Wed, 18 Jul 2018, Gregory Farnum wrote:
> On Wed, Jul 18, 2018 at 8:40 AM, Sage Weil <sweil@xxxxxxxxxx> wrote:
> > I'm going to miss the Friday call again (meetings... yay). My main status
> > update is that I'm most of the way through changing the monmap to use
> > addrvecs and adjusting all of the bootstrap-related behaviors so that both
> > the old and new ports are initially probed. Once monclient gets a "real"
> > monmap it'll then know the correct mon addresses and connect the "right"
> > way.
> >
> > Also, I had a product kerberos requirements conversation with an initial
> > customer and as a first plass simply authenticating a krb user, then
> > checking on the local (mon) host via OS calls to check group membership
> > ("is user bob in group ceph-admins") would be sufficient. We're going to
> > end up with several modes here, including
> >
> > - checking local group membership (requires that mons are part of the
> > same kereros domain etc)
> > - use AD PAC
> > - query LDAP
> >
> > but the local group membership is actually easiest to implement and
> > probably a good place to start?
>
> Is this actually plausible from a cluster administrator's point of
> view? I've never come close to deploying and running these systems,
> but it seems like trying to get kerberos roles "inside of" your
> infrastructure layer might be a big no-no both in terms of security
> (you'd have accounts for your users on your infrastructure!) and in
> terms of organizational layout and access permissions.
It surprised me too, but this is a big (BIG) kerberos user and this is
what they asked for. They prefer this over the LDAP or AD approaches
because it's simpler for us to implement, is more portable (no AD
dependency), and it will work in any environment where their kerberos
users and groups are visible to the OS. Shrug. We'll do the other
options as well sooner or later...
> > The user stories I think we should initial target are:
> >
> > User stories
> >
> > 1. As a Ceph administrator, I can define roles and associated Ceph
> > caps/capabilities by defining a Ceph auth user (e.g., client.role.foo) for
> > each role in the Ceph auth database.
> >
> > 2. As a Kerberos administrator, I can map Ceph administrators to Ceph
> > roles by adjusting AD credentials in the AD database, without registering
> > users in the Ceph auth database (or otherwise making any per-user changes
> > in Ceph).
> >
> > 3. As a Ceph administrator, I can log into a host, authenticate with
> > kerberos (kinit user@DOMAIN), and then issue ceph or rbd CLI commands
> > based on my kerberos/AD credentials and associated role.
> >
> > 4. As a Ceph administrator, I can examine the cluster’s audit log and
> > determine the (kerberos) identity (as opposed to only the ceph role) of
> > any commands that were executed (see #3).
>
> Ah, I've seen this come up before in similar contexts — do we have
> tickets for it or anything yet? We could make some progress on this
> without the Kerberos work (eg, embedding a user ID in commands passed
> from the ceph cli).
Well, 4 is really about ensuring the logging isn't negatively impacted by
the role concept. I think they key piece is #3: the ceph cli
authenticates with the mon as sage@DOMAIN (or whatever), and we add some
magic in the mon that says "oh, sage is in group ceph-admins, which is a
role I recognized, so I'm going to apply those capabilities to the
session".
The open questions here include at a minimum:
- What is the client EntityName for the session? client.sage/DOMAIN?
client.krb.DOMAIN.sage? I think it can't be client.role.admin because
that makes 4 harder, and also means that the identity is obscured to the
rest of the system (not just the mon).
- Does the client decide the name by explicitly specifying it (e.g., 'ceph
-n client.krb.sage/DOMAIN status'), or do we make the default magically
get set somehow when kerberos credentials are present?
- How does the client know to pass the kerberos credential instead of
looking for client.admin in /etc/ceph/keyring? FWIW this particular user
was fine with .bashrc bits that populate CEPH_ARGS with '-n ...' or
related options.
- How do we define the roles in such a way that on auth we know to check
whether the role applies to the given user? We might have a special
"role" property/flag for auth entries, and some fields indicating how they
are matched against users... or maybe a magic client.role.
prefix?
I agree that some of this can proceed without being blocked on kerberos,
and we can certainly work out how the UX should work. For example, mapping
entities to role defintiions via group membership is something that could
implemented independent of the kerberos piece. e.g.,
ceph -n client.unixuser.sage -k mykeyring status
could map to a ceph auth entry for client.unixuser.sage with a key defined
but no caps, and a separate role definition (say client.role.cephadmins)
could say something like
user_prefix = client.unixuser.*
user_group = cephadmins
cap mon = ...
It's kind of a silly example in the absence of a kerberos domain (I don't
think anyone would do the above), but the implementation is modular.
Eventually user_prefix would be client.krb.* or something instead...
Does this seem like it's going in the right direction?
sage
