How policies apply to devices in multiple groups

When you create a policy in Workbrew, you can scope it to a specific Device Group or leave it as a workspace-wide policy (shown as All Devices in the Workbrew Console) that applies to every Device. Most of the time this is straightforward, but things get more nuanced when a Device belongs to multiple groups that each set a policy of the same kind.

Workspace-wide and group-scoped policies#

A policy is always one of these kinds:

• Forbidden Formulae
• Forbidden Casks
• Forbidden Licenses
• Allowed Taps
• Casks Allowlist

When you create one without selecting a Device Group, it becomes a workspace-wide policy. When you select a Device Group, it becomes a group-scoped policy.

Each kind is resolved independently per Device. A Device could get its Forbidden Formulae from one set of policies and its Allowed Taps from a completely different set.

How Workbrew resolves which policy applies#

For each kind of policy, Workbrew combines every policy that applies to the Device. Those are the workspace-wide policy of that kind, if one exists, plus the policy from each group the Device belongs to that sets that kind. Workbrew takes the union of them all, so the Device gets the combined list with duplicates removed.

There is no override and no fallback. A group-scoped policy does not replace the workspace-wide baseline, it adds to it. Belonging to more groups can only add to the combined list, never remove from it.

Forbidden lists and allowlists are opposite kinds of list, so the union has a different practical effect for each:

• For the forbidden policies (Forbidden Formulae, Forbidden Casks, Forbidden Licenses), the union restricts a Device by the combination of every policy. Anything forbidden by the workspace-wide policy or by any of the Device's group policies is forbidden on that Device.
• For the allowlist policies (Allowed Taps, Casks Allowlist), the union permits a Device the combination of every policy. A Device can use anything allowed by the workspace-wide policy or by any of its group policies.

A concrete example#

Say you have a workspace-wide Forbidden Formulae policy that forbids ffmpeg, and two Device Groups with their own Forbidden Formulae policies:

• Group A forbids node
• Group B forbids python

Here is what each Device sees:

• On a Device in Group A only, ffmpeg and node are forbidden (the workspace baseline plus Group A).
• On a Device in Group B only, ffmpeg and python are forbidden (the workspace baseline plus Group B).
• On a Device in both Group A and Group B, ffmpeg, node, and python are forbidden (the workspace baseline plus both groups).
• On a Device in neither group, only ffmpeg is forbidden (the workspace baseline on its own).

The workspace-wide policy applies in every case, and each group the Device is in adds its own restrictions on top.

What happens when there is no workspace-wide policy#

If there is no workspace-wide policy of a given kind, the Device still gets the union of every group-scoped policy that applies to it. A Device in Group A and Group B with no workspace-wide Forbidden Formulae policy is restricted by Group A and Group B combined.

A Device that is in no group with a policy of that kind, and where no workspace-wide policy exists either, has no policy of that kind in effect. There is simply nothing to apply.

Each kind of policy is independent#

Because each kind is resolved separately, a single Device can draw a different set of policies for each kind. For example, a Device in Group A and Group B might get:

• Its Forbidden Casks from Group A alone, if only Group A sets Forbidden Casks.
• Its Allowed Taps from the union of the workspace-wide policy and both groups, if all three set Allowed Taps.
• Its Forbidden Formulae from the union of both groups, if both groups set Forbidden Formulae and there is no workspace-wide policy.

When there is a conflict between two policies (e.g. Casks Allowlist and Forbidden Casks), forbidding always wins.

Recommendations#

• Use workspace-wide policies for the rules that should apply to every Device regardless of group membership. They are the baseline the union always includes.
• Use group-scoped policies to add rules for specific groups. For the forbidden policies, a Device in several groups accumulates the restrictions of all of them, so overlapping group membership makes a Device more restricted, not less.
• Be deliberate with the allowlist policies. Because Allowed Taps and Casks Allowlist union as permissions, a Device in multiple groups can use anything any of its groups allow. If you need a group to be limited to a narrow allowlist, avoid also placing those Devices in a group with a broader one.

For details on creating and managing policies, see Declare policies to block software packages and Allow installation of packages from third party Taps.