Skip to content
  • nomenclature
  • groups
  • roles and permissions

Roles & Permissions

Roles are the only groups that grant permissions. A Role group ties a governing function (owner) to a system and an optional scope chain with a specific permission level. This yields clean Segregation of Duties (SoD), deterministic approvals, and auditable access.

Pattern

Section titled “Pattern”
prv-{owner}-role-{system}[-{scope}][-{env}]-{perm}@{domain}

Display name: PRV – Role – {OWNER} – {SYSTEM} – {Scope} – {Perm}

Core Principles

Section titled “Core Principles”
  1. Owner-first naming. The governing function appears first — it determines who approves and manages.
  2. Least privilege. Prefer scoped roles over broad ones.
  3. Individuals only for admin/owner roles. Never nest Teams into admin Roles.
  4. Short-lived elevation. Time-box powerful roles with ticket + approver + evidence.
  5. Groups grant access. OUs do not. OUs are policy buckets; Roles control permissions.

Choosing the Owner

Section titled “Choosing the Owner”

The owner (second octet) is the team that governs the role, not necessarily the team that uses it.

OwnerGoverns
pltOrg/tenant admin, identity control (IdP/SSO/SCIM), Workspace org settings, SaaS org ownership
secSecurity operations, vuln scanning, IR, compliance workflows
itEndpoints/MDM, Help Desk admin, corp networks
engEngineering repos, build systems, CI/CD, code-scoped permissions
opsDelivery/project execution, customer collaboration roles, PMO tooling
finBilling, ERP/GL sub-admin, payments, invoicing
mktgCMS/web, brand assets publishing, webinar production
salCRM/CPQ scoped roles, pipeline, proposal tooling
legalLegal hold operators, DMS, discovery/export
hrHRIS sub-admin, recruiting system roles (often co-owned with PLT)
bizKPI/BI workspaces, pricing, analytics
execCompany-wide comms/publishing, board packet access
archiveRecords management, ARCH snapshots, retention execution

Rule of thumb: If it changes org-wide security posture, the owner is plt (or sec for security tooling). If it changes public content, owner is typically mktg.

Role Classes

Section titled “Role Classes”
ClassExamplesMembershipExpiry
Admin/Ownerprv-plt-role-wks-drive-admin, prv-plt-role-aws-idc-adminIndividuals only (W-2), ticket+approver7-30 days max
Operator/Managerprv-sec-role-op-vault-operator, prv-plt-role-tf-operatorSmall set; partners allowed if needed30-180 days
Work rolesprv-eng-role-gl-maintainer, prv-ops-role-wks-sd-collab-editorProject/space DRIsProject-bounded

Non-Nesting Rules

Section titled “Non-Nesting Rules”
  • Do not nest Teams into admin roles.
  • Avoid role-to-role nesting (privilege sprawl). Prefer explicit membership.
  • Never add people-* or ident-* to any role group.

Description Format

Section titled “Description Format”
{Name}: {purpose} | {who is eligible} | {what it's used for} | {guardrails/expiry}
  | Security group ({concise purpose}) [| Locked group ({reason})] [| CEL: {expression}]

Group Settings

Section titled “Group Settings”
  • Security label: ON (roles grant access)
  • Membership: Only invited
  • External members: OFF for admin/owner roles; case-by-case for work roles
  • Locked: ON if automation-managed (Terraform/GAM)

Examples by System

Section titled “Examples by System”

Google Workspace

Section titled “Google Workspace”
RolePurpose
prv-plt-role-wks-sd-create-adminShared Drive creation authority
prv-plt-role-wks-sd-collab-managerManager on COLLAB drive roots
prv-plt-role-wks-sd-team-managerManager on TEAM drive roots
prv-plt-role-wks-sd-strict-managerManager on STRICT drive roots
prv-plt-role-wks-drive-adminTenant-wide Drive/Storage admin
prv-plt-role-wks-groups-adminGroups admin
prv-plt-role-wks-user-adminUser provisioning admin

AWS

Section titled “AWS”
RolePurpose
prv-plt-role-aws-idc-prd-adminIdentity Center production admin
prv-plt-role-aws-org-adminAWS Organizations admin
prv-eng-role-aws-dev-developerDevelopment environment developer
prv-fin-role-aws-billing-readBilling read-only

GitLab

Section titled “GitLab”
RolePurpose
prv-eng-role-gl-org-adminGitLab org admin
prv-eng-role-gl-maintainerRepository maintainer
prv-eng-role-gl-developerRepository developer

Other Systems

Section titled “Other Systems”
RolePurpose
prv-plt-role-tf-cloud-adminTerraform Cloud admin
prv-plt-role-op-vault-admin1Password vault admin
prv-plt-role-slack-adminSlack workspace admin
prv-plt-role-zm-adminZoom account admin

Lifecycle

Section titled “Lifecycle”

Create

Section titled “Create”
  1. Identify the owner (governing function).
  2. Choose the system, scope chain, and permission level.
  3. Build the canonical email/name/description.
  4. Label as Security. Set Locked if automation-managed.
  5. Add CEL restriction if needed (e.g., W-2 only).
  6. Add minimum 2 owners.

Operate

Section titled “Operate”
  • Admin/Owner roles: monthly attestation.
  • Operator roles: quarterly attestation.
  • All roles: log grant/revoke events to alerts.

Retire

Section titled “Retire”
  • Revoke all members. Lock group. Keep 1 year for audit. Delete.

Metrics

Section titled “Metrics”
MetricTarget
Admin roles with expired time-box0
Roles with fewer than 2 owners0
Teams nested in admin roles0
Quarterly attestation completion100%