One of the end goals of the kerberos work is to define caps for a few
roles and then authenticate via kerberos, with your ceph roles/caps
applied based on the kerberos group membership.
I want to lay out what the full configuration and user experience would
look like to make this work.
1. Define the roles
Currently 'ceph auth ls' will dump the cephx users. Add a new set of
commands to define roles:
$ ceph auth role create role.superuser mon 'allow *' osd 'allow *' mds 'allow *'
$ ceph auth role ls
[role.superuser]
caps mon = allow *
caps osd = allow *
caps mds = allow *
One alternative here would be to combine the role namespace with the auth
user namespace (e.g., client.role.foo, or even keep role.foo but include
it in 'ceph auth ls' output). Keeping them separate seems cleaner to me
but no strong opinion here.
1.5. Map a normal user to a role
I'm not terribly attached to any specific workflow here, but this might
work:
$ ceph auth add-role client.foo role.superuser
$ ceph auth ls
...
[client.foo]
key = ...
roles = role.superuser
...
$ ceph auth rm-role client.foo role.superuser
$ ceph auth set-roles client.foo role.superuser [...]
The role list would be a property of the user. The mon would simply take
the role caps grants and add them in to any user-specific caps. (Caps are
always additive.)
2. Map a kerberos group to a role
For the kerberos case, we'd do something similar:
$ ceph auth role add-kerberos-group role.superuser ceph_superusers/FOO.COM
$ ceph auth role ls
[role.superuser]
caps mon = allow *
caps osd = allow *
caps mds = allow *
kerberos groups = ceph_superusers/FOO.COM
This group mapping would be attached to the role instead of the user
because one of the goals of this is to not define auth user entries for
kerberos users at all. On the other hand, for the non-kerberos
user<->role mapping above, those are existing auth user entries, and there
may be a zillion of them sharing a role, so making the role list a user
proprety make more sense.
3. Authenticate with kerberos
Presumably you first do something like
$ kinit user
to authenticate with kerberos and get your TGT (or whatever).
4. Tell ceph client(s) to authenticate using kerberos instead of cephx.
By default, the ceph CLI uses client.admin and grabs the cephx key out of
/etc/ceph somewhere. Instead, we want to authenticate as user/FOO.COM.
[Question: Should our EntityName be literally "user/FOO.COM", or
"client.kerberos.user/FOO.COM", or something else?]
$ ceph --auth-kerberos -s
or probably actually
$ echo 'CEPH_ARGS="--auth-kerberos"' >> .bashrc
and then after logging in,
$ ceph -s
...
This would tell the ceph client to look for a kerberos credential in the
environment/keytab/whatever and use that to authenticate with the cluster.
5. Allow the mon to check our kerberos groups so that it can apply roles.
We have three options here.
5.1. Use the mon hosts' group membership.
$ ceph config set mon auth_kerberos_group_mode host
ceph-mon will use the normal OS calls (checking local unix groups) to see
if "user" (from "user/FOO.com") is a member of the local ceph_superusers
group.
5.2. Use LDAP
$ ceph config set mon auth_kerberos_group_mode ldap
$ ...
TBD
5.3. Use ActiveDirectory PAC
$ ceph config set mon auth_kerberos_group_mode pac
$ ...
TBD
