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