On Wed, Jul 18, 2018 at 2:08 PM, Sage Weil <sweil@xxxxxxxxxx> wrote:
> 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...
Okay, I just don't want us to get fixated on a single big user and
make an MVP that nobody else can work with.
>
>> > 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?
Yeah; these are good questions. What I was thinking of in particular
is that if the client libraries are providing the "real user" info[1]
somehow, then we can start logging *more* details like login names to
the ceph audit log (or other places!) even if it's not fully signed.
That's not a firm constraint but it might be useful.
-Greg
[1]: Obviously we can't *rely* on the client libraries for real
secured data, so kerberos identities need to also be checked on the
monitor as well. But voluntary compliance satisfies a lot of people!
--
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
