Skip to main content

Access & Identity

People and teams are modeled as manifests. Every permission block elsewhere (projects, repositories, registries) references these by name — never a raw email or external group.

OrganizationUser​

# manifests/organization-user/jane-smith.yaml
apiVersion: lowops.manifests.v1
kind: OrganizationUser
metadata:
  name: jane-smith
  organization: fincorp
spec:
  identity:
    firstName: Jane
    lastName: Smith
  externalAccounts:
    - sourceType: GITHUB
      sourceName: default          # a GithubConnection
      username: jane-smith-gh

OrganizationUserGroup​

# manifests/organization-user-group/retail-developers.yaml
apiVersion: lowops.manifests.v1
kind: OrganizationUserGroup
metadata:
  name: retail-developers
  organization: fincorp
spec:
  members:
    users:
      - jane-smith
    external: []

Referencing groups in permissions​

Any permissions block (on a Project, GithubRepository, ArtifactRegistry, OrganizationalUnit, …) references group manifests by name. Prefer groups over individual members for production (SOC2/PCI governance).

# Inside a Project / OrganizationalUnit spec, for example:
spec:
  permissions:
    administrators:
      groups:
        - retail-cloudops
      members: []
    contributors:
      groups:
        - retail-developers
      members: []
    viewers:
      groups: []
      members: []

Rule of thumb: grant access to groups, and manage people by adding/removing them from the OrganizationUserGroup. This keeps project manifests stable as teams change and preserves a clean audit trail.