You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Declare allowExternalMembers on managed groups so deploys stop re-arming the external-member purge (#140)
* Declare allowExternalMembers on managed group settings
Every pulumi up was resetting the Google Workspace per-group setting
ALLOW_EXTERNAL_MEMBERS to false on all managed groups, because the
GroupSettings resources never declared allowExternalMembers and the
provider (SamuZad/googleworkspace 0.11.1) defaults the field to false.
Google then silently purges external-email members from affected groups
roughly 1-2 days after each apply, with no audit events.
Pin the setting to true for all managed groups. External membership
itself remains governed exclusively by config/users.ts entries; this
setting only permits it.
Part of the #133 incident.
* Scope allowExternalMembers per group, derived from membership config
Instead of permitting external members on every managed group, derive
allowExternalMembers per group: true only for groups whose membership
config (config/users.ts) resolves at least one member to a
non-@modelcontextprotocol.io email. Email resolution is factored into
resolveGoogleMemberEmail and shared with GroupMember creation so the
two cannot drift. The field stays declared on every group because the
provider defaults it to false on each apply, after which Google
silently purges external members (#133 incident).
With current config, exactly these groups derive true: maintainers,
registry-wg, antitrust, catch-all. A config test pins this set so
changes to it are always deliberate.
* Make allowExternalMembers an explicit per-role opt-in with config validation
Replace the derived per-group allowExternalMembers (computed from
membership config) with an explicit opt-in: group owners set
allowExternalMembers: true on the role's google config in
src/config/roles.ts, and src/google.ts passes it straight through to
GroupSettings (defaulting to false). The field stays declared on every
group because the provider resets an omitted field to false on each
apply, after which Google silently purges external members (#133).
Roles opting in, matching current membership: maintainers,
registry-maintainers (registry-wg), antitrust, catch-all.
A validate-config check replaces the old pinned-set test: it fails with
an actionable error whenever a group has a member resolving to a
non-@modelcontextprotocol.io email but its role does not opt in, naming
the group, the member email, and the exact config line to add.
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
0 commit comments