Why both Teams and IAM exist
Vantage has two access systems that look similar at first glance but solve different problems. IAM (Identity and Access Management) controls what actions a user can perform. Teams control which resources a user can see. Removing either one leaves a gap that the other cannot fill.
Two questions, two systems
Every access decision in Vantage answers one of two questions:
| Question | System | Scope |
|---|---|---|
| Can this user create a cluster? | IAM | Organization-wide |
| Can this user see the A100 cluster? | Teams | Project-level |
IAM is the gatekeeper for capabilities. It defines verbs — create, delete, manage, administer — and groups them into permission groups. A user in the Cluster Admin group can create and manage clusters across the entire organization. A user in the Regular User group cannot, regardless of which team they belong to.
Teams are the boundary for resources. A team owns clusters, workspaces, jobs, storage, and sessions. Members of the "ML Research" team see ML Research resources; members of the "Platform Engineering" team see Platform Engineering resources. The two sets are invisible to each other unless someone explicitly shares a resource.
Why one system is not enough
Imagine Vantage had only IAM, without teams. Every user with "create jobs" permission could see every cluster in the organization, submit jobs to any of them, and browse every other user's sessions and storage. There would be no project boundaries, no resource isolation, and no way to limit a group of interns to a specific set of dev GPUs while keeping production clusters out of reach.
Now imagine the reverse — teams without IAM. You could isolate resources, but every member of a team would have identical permissions. The team lead, the intern, and the billing contact would all be able to delete clusters, manage members, and modify storage. There would be no way to say "you can see these resources but only read them."
Both systems are needed because access control has two independent dimensions: scope (which resources) and capability (which actions).
How they work together
When a user tries to do something — say, submit a training job to a cluster — Vantage checks both dimensions:
- Team membership -- Does the user's team own (or have shared access to) this cluster? If not, the cluster is invisible and the request is rejected before it even reaches IAM.
- IAM permissions -- Does the user's permission group include the ability to submit jobs? If not, the action is denied even though the user can see the cluster.
Both checks must pass. A user who has the Jobs Admin permission group but is not on a team with access to a particular cluster cannot submit jobs to it. Conversely, a user on the right team but with only Viewer role permissions can see the cluster but cannot submit anything.
A concrete example
Consider an organization with two teams and three users:
| User | Team | IAM permission group |
|---|---|---|
| Alice | ML Research | Full Admin |
| Bob | ML Research | Regular User |
| Carol | Platform Engineering | Cluster Admin |
The ML Research team owns a workspace with four A100 GPUs. The Platform Engineering team owns a separate workspace with CPU-only nodes.
- Alice can see the A100 workspace (team membership) and can do anything in it (Full Admin permissions) — create sessions, manage storage, invite members, adjust quota.
- Bob can see the same A100 workspace (same team) but can only run workloads and manage his own resources (Regular User permissions). He cannot invite new members or adjust quota.
- Carol cannot see the A100 workspace at all — she is not on the ML Research team. She can manage clusters across the organization (Cluster Admin permissions), but only within the workspaces her team owns.
If Alice shares a storage volume with Platform Engineering, Carol can see that volume. But her actions on it are still governed by her IAM permissions and any access level Alice set when sharing.
The mental model
Think of Teams as rooms and IAM as keycards.
A room contains resources — desks, equipment, whiteboards. You can only enter rooms your team has access to. Once inside, your keycard determines what you can touch. One keycard opens every cabinet; another only lets you read the whiteboard. The room decides what you can see. The keycard decides what you can do.
Cross-references
- Teams concepts — ownership boundaries, roles, membership, resource visibility
- IAM concepts — permission groups, authentication, SCIM provisioning
- Workspaces — the quota and cost envelope that sits inside a team