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.
>
> 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).
-Greg
--
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
