opschain admin groups
Included from Basic tier
Local group membership for any OpsChain user, over the admin-gated v2
GroupService verbs (the v1 /api/admin/groups surface
remains for older callers). Local groups share one namespace with
directory group names by design: a principal's effective groups are its
provider snapshot groups plus its local memberships, so a single
group-named policy assignment covers both provider populations — and
adding a local membership in a directory-named group grants a user that
group's policies without touching the directory.
Local groups are stored records in their own right: a group may exist with zero members —
create makes one empty, and delete removes a group and its
memberships, refused by name while policy assignments reference the
group (the refusal lists them). The membership verbs resolve the
username to its user id first (the v2 membership key), so add-member
into an unknown group answers not_found — create the group first
(the v1 surface's implicit create-on-first-add does not carry over).
Groups a provider keeps reporting remain visible through the snapshot
catalog regardless.
| Subcommand | Purpose |
|---|---|
list | List local groups and their members — opschain docs cli/admin-groups-list |
create | Create an empty local group — opschain docs cli/admin-groups-create |
delete | Delete a local group (assignment-free only) — opschain docs cli/admin-groups-delete |
add-member | Add a user to a local group — opschain docs cli/admin-groups-add-member |
remove-member | Remove a user from a local group — opschain docs cli/admin-groups-remove-member |
admin groups itself takes no flags; each subcommand carries the admin
connection pair (--server, --auth-token) with the same resolution and
named errors as the users verbs — see opschain docs cli/admin-users.
See also
opschain docs cli/admin-authz-policies-assign— where group names earn their authority.