Skip to main content
Perimeters are boundaries within your platform that isolate and group the work of a team or project. Each perimeter carries its own governance policy, which defines the resources and access available to the team or project. Administrators can create as many perimeters as needed.

​
Why perimeters matter

Access to resources is inherited from access to a perimeter. A user who can access a perimeter can use the compute, packages, and models registered to it, while a user without access cannot. This keeps one team’s resources and workloads separate from another’s within the same platform.

​
Perimeters and the data plane

The data plane is the part of the platform that runs in your cloud: the cluster where tasks execute and the storage where your data is kept. Creating a perimeter provisions a dedicated slice of the data plane for a team or project. Each perimeter has:
  • Its own namespace, where all of the perimeter’s tasks run
  • Its own cloud identity (an IAM role or service account) that the perimeter’s tasks assume
  • Its own database schema and artifact storage, holding the perimeter’s run metadata and results
  • Its own set of secure package channels and policies, governing which packages are available to the perimeter’s workloads
Cloud permissions attach to the perimeter’s identity, so a task in one perimeter cannot authenticate as another perimeter’s identity, and cannot reach that perimeter’s storage or data sources. Compute pools are the exception to this per-perimeter provisioning. Pools are shared data plane infrastructure, and a perimeter’s policy grants its workloads access to specific pools, so teams share the underlying hardware while their workloads stay isolated.

​
What a perimeter governs

Each perimeter carries its own configuration and policy, including:
User access
Which human users and machine users can work in the perimeter, and whether they can view results or run workloads. See Roles and privileges.
Compute
Which compute pools workloads can run in, which queues users can submit to, and the default and maximum CPU and memory available to each task.
Package channels
Which channels are available, including the secure channels every perimeter receives and any external channels that you register. Channel policies filter the packages available from those channels by CVE score, CVE status, and license family.
Container images
Which images tasks can use, and the default image and registry for tasks that don’t specify one.
Models
Which models from the model catalog are accessible, filtered by attributes such as publisher, license, and country of origin.
Data integrations
Which external data sources workloads can read from and write to, accessed through governed credentials so users never handle secrets directly.
Security
The cloud identity tasks assume (an IAM role or service account) and the security integrations that define who can enter the perimeter and how they authenticate.
Because most governance features attach to a perimeter, configuring package channels, model access policies, or compute limits is almost always done for a specific perimeter rather than for the platform as a whole.

​
Working with perimeters

For details on the policies a perimeter can carry, see Channel governance and Model governance.