Webinar: WWDC 26: What's new for security, developers and IT teams
Register now
Security and Compliance
Guide

Configure endpoint privilege management for Workbrew

Petros Amoiridis

This guide shows you how to configure an endpoint privilege management (EPM) tool, such as CyberArk EPM or BeyondTrust, so it does not block the Workbrew Agent's privileged operations. EPM tools commonly intercept sudo, and when they do not account for the Workbrew Agent, operations that the Agent runs as root fail silently. For the reasoning behind the recommendation below, and why it is safe, see How the Workbrew Agent uses elevated privileges.

Recognize the symptom

EPM interference usually shows up as elevated operations that silently fail rather than as an obvious error in the Workbrew Console. The most common signs are:

  • Standard Users do not get brew access even though Managed brew access is enabled, and their Devices show "Access Denied" in the Console.
  • The Workbrew Agent log at /opt/workbrew/var/log/workbrew-agent.log contains sudo: a password is required.

Both happen because the Agent elevates with sudo --non-interactive, which fails immediately rather than prompting when the EPM tool does not allow the call.

Allow the Workbrew Agent's elevation

The Workbrew Agent runs as a dedicated _workbrewd system account and elevates to root through sudo for specific operations. On install, Workbrew adds a single rule at /etc/sudoers.d/workbrew:

_workbrewd ALL=(root) NOPASSWD:ALL

Your EPM policy needs to let that elevation run. EPM tools differ in how policies are expressed, so apply the following to whichever targeting your tool supports:

  • Account: _workbrewd
  • Process: the Workbrew Agent daemon, registered as the LaunchDaemon com.workbrew.workbrew-agent, with the executable at /opt/workbrew/bin/brew
  • Code signature: Apple Developer Team ID 676JW3JDLF, if your tool can scope by signed publisher rather than by path
  • Elevation it performs: /usr/bin/sudo --non-interactive -- <command>

Allow the _workbrewd account's elevation as a whole rather than allowlisting individual commands. The Agent runs a range of operations as root, and the exact set changes as Workbrew develops, so a command-level policy would need revisiting with each Agent update and would silently break Workbrew when it drifts. Scoping the policy to the daemon account covers every operation and stays correct across updates. See the explanation linked above for why this does not expand Workbrew's privileges.

Verify

Apply the policy, then trigger or wait for a Device check-in. On an affected Device, confirm an authorized Standard User is now in the workbrew_users group:

dseditgroup -o checkmember -m "USERNAME" workbrew_users

A USERNAME is a member of workbrew_users result confirms the elevation now succeeds. In the Workbrew Console, the Device's brew access status changes from "Access Denied" to "Granted via Workbrew" on the next check-in, and sudo: a password is required stops appearing in /opt/workbrew/var/log/workbrew-agent.log.

If access still does not appear, the user may genuinely lack a Secure Token rather than being blocked by the EPM tool. See Managed brew access for how accounts are selected, and Adding Users to the workbrew_users Group via MDM for adding users directly with a script.

We use cookies to analyze traffic and improve your experience. You can accept all cookies or decline non-essential ones. Read our Privacy Policy for details.