The /people directory
We store relevant data about (mostly technical) Lyceum employees in the /people directory. This includes personal
information, group memberships, public keys etc.
Planned direction: this directory drives Google Workspace, not the reverse
/people stays the source of truth. Who exists and who is in which group is declared here, in git, and
reviewed like any other change. What changes is the other end: membership SHOULD be applied from these files
by Terraform rather than clicked into the Workspace admin console. Workspace could not replace this directory
anyway. .sops.yaml binds secret access to personal GPG fingerprints it has nowhere to hold. See
/people.
Structure
Within /people, every person has their own /people/<first-name>.<last-name> directory which is laid out as follows:
<first-name>.<last-name>/
├── profile.yml
├── ssh
| └── ...
└── gpg
└── ...
The profile.yml file is structured as follows:
id: foo.bar
name: Foo Bar
email: foo.bar@lyceum.technology
groups:
- ...
Elements of groups are tags that can e.g. be used by infra tooling to determine which user should have access to which
resources.
The ssh directory contain separate SSH keys for our three deployment environments, created e.g. via
ssh-keygen -t ed25519 -C "<your-name>@lyceum.technology".
The gpg directory contains the users' GPG keys.
Tasks
| Task | What it does |
|---|---|
mise run //people:list-emails |
Print every address. --group <group> filters, --as-json emits an array |
mise run //people:import-gpg-keys |
Import everyone's GPG keys and mark them ultimately trusted |
mise run //people:import-keys |
All of the above |
Adding yourself here does not grant you anything on its own. Someone on the platform team has to apply the Terraform,
and adding a SOPS recipient additionally needs the encrypted files re-encrypted.
Groups
There are currently the following groups:
gcp-owner: Owners of our GCP project(s).tailscale: People in this group should be able to access our tailnet.