Group filtering and mapping

[didrocks]

Hey everyone,

Authd is now mapping all the groups that the user is part of to local groups equivalent. Those are either:

• remote group (IT)
• local group (sudo, wheel)

To map between remote groups and local groups the current strategy is convention-based naming.

The convention-based naming allows the groups to be managed entirely on the IDP side of things (let's call it remote/cloud management). This relies on having the linux- prefix for any machine based group, say linux-sudo will be mapped to sudo.

This has the trade-off that administrators will have to create extra groups and assign users to them on top of the existing company’s grouping setup, therefore duplicating the operations effort. Looking at the feedback we are getting in that situation, it seems that also people operating the groups on the IDP are not necessarily the ones in control of the linux devices deployments and configurations.

The local mapping involves having a prebaked file that matches groups information from the IDP with the corresponding machine groups assigned. An example would be having a devops group defined in MSEntraID that allows a user to be a member of the wheel and lxd groups on some machines with this particular mapping configured.

The idea is thus to allow, via a broker configuration file, the IT team to define, filter and remap from remote groups to local ones. Keep in mind that those configuration files are discrete files, shipped under /var/snap/authd-<broker_name>/current/broker.conf.d/, and so can updated and managed independently, as an override, on the main configuration file broker.conf.

This approach allows more flexibility when dealing with a pre-existent setup, as it can perfectly match the complexities of an organization structure (via groups) and map it one to one. We can also then offer different configurations and mapping per machine.
At the same time, tradeoffs might be scaling as it would become an issue when there are thousands of groups that need to be sync'd.

An example of the configuration would be:

[groups.filter_and_map]
cloud-group1 = local-group1
cloud-group2 = cloud-group2
IT = sudo
DevOps = lxd,wheel

Here, as there is the section group.filter_and_map, authd will only consider cloud-group1, cloud-group2, IT and Devops remote groups. Any other groups the user is part of, like cloud-group3, are disregarded.

The corresponding local groups potentially assigned to the user (after potentially created them) on that particular would be:

• local-group1 (due to cloud-group1 = local-group1)
• cloud-group2 (due to cloud-group1 = cloud-group2)
• sudo (due to IT = sudo)
• lxd (due to DevOps = lxd,wheel)
• wheel (due to DevOps = lxd,wheel)

Of course, those assignments will be only done on the remote groups the user is part of. For instance, if the user is not part of the IT groups, then, it won’t be part of the local sudo group in the previous case.

Finally, we also want your opinion on the best section name to define this "filtering" and "mapping" functionality. Current proposals are:

• [groups.filter_and_map]
• [groups.remote_to_local]
• [groups.filtering]
• [groups.mapping]

What do you think about that feature? Is it something you would use in your current setup? If so, what is the best wording for the section itself?
Also, do you have any proposals or ideas to resolve this issue?

Thanks in advance for your contribution!