On Wed, 18 Jul 2018, Gregory Farnum wrote:
> 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.
I agree. I'm looking forwrd o hearing Daniel's take (as he has a
different set of users/customers he's thinking about), or any other
kerberos users on this list who want to chime in!
> [...]
> 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!
Yeah, I agree. We started doing something sort of like this with the
client hostname and crush_location, but there's certainly an opportunity
to log more metadata (trusted or otherwise) about the client.
sage
--
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
