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 that applies to all devices. Most of the time this is straightforward, but things get more nuanced when a device belongs to multiple groups that each define the same type of policy.

Workspace-wide and group-scoped policies#

Every policy is tied to a specific policy variable (Forbidden Formulae, Forbidden Casks, Forbidden Licenses, Allowed Taps, or Casks Allowlist). When you create a policy without selecting a device group, it becomes a workspace-wide policy. When you select a device group, it becomes a group-scoped policy.

Each Brew Configuration is resolved independently per device. A device could get its Forbidden Formulae value from one source and its Allowed Taps value from a completely different source.

How Workbrew resolves which policy applies#

For each Brew Configuration, Workbrew follows this logic:

1. If the device is in exactly one group that defines that Brew Configuration, the group-scoped policy applies.
2. If the device is in multiple groups that define the same Brew Configuration, Workbrew falls back to the workspace-wide policy.
3. If no group defines that Brew Configuration, the workspace-wide policy applies (if one exists).

The key rule here is that Workbrew does not attempt to merge or rank competing group-scoped policies. When there is ambiguity, it sidesteps the conflict entirely by falling back to the workspace-wide default.

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 ffmpeg and node
• Group B forbids ffmpeg and python

Here is what each device sees:

• A device in Group A only gets the Group A policy: ffmpeg and node are forbidden.
• A device in Group B only gets the Group B policy: ffmpeg and python are forbidden.
• A device in both Group A and Group B gets the workspace-wide policy: only ffmpeg is forbidden. Both group policies are ignored because there is ambiguity.
• A device in neither group gets the workspace-wide policy: only ffmpeg is forbidden.

What happens when there is no workspace-wide fallback#

If a device is in multiple groups that define the same Brew Configuration and there is no workspace-wide policy to fall back to, the device gets no restrictions for that Brew Configuration. Both group policies are ignored due to ambiguity, and there is nothing to fall back to.

This is worth keeping in mind when designing your policy structure. If you rely exclusively on group-scoped policies, a device that belongs to multiple groups could end up with no restrictions at all for that variable.

Each policy variable is independent#

Because each variable is resolved separately, a single device can end up with policies from different sources for different Brew Configurations. For example, a device in Group A and Group B might get:

• Its Forbidden Casks from Group A (if only Group A defines Forbidden Casks)
• Its Allowed Taps from the workspace-wide policy (if both groups define Allowed Taps, triggering the fallback)
• No Forbidden Formulae restrictions (if both groups define Forbidden Formulae but there is no workspace-wide policy)

There is no interaction between different policy variables. Forbidden Casks and Casks Allowlist, for instance, are checked independently at different layers of the system.

Recommendations#

To avoid unexpected gaps in coverage:

• Define workspace-wide policies as your baseline. These act as the safety net when group-scoped policies conflict.
• Use group-scoped policies to override the baseline for specific groups, not as your only layer of policy enforcement.
• Be mindful of devices that belong to multiple groups. If two groups both define the same policy variable, neither group's policy will apply, and the device falls back to the workspace-wide default.

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