Skip to main content

Access Control

Access control decides which members of your organization can see and work with each part of your fleet. Access is scoped to projects and cohorts, so you can keep production devices visible to a smaller group of engineers while the rest of the team works with staging.

The permission model​

Access is granted at two levels:

  • Project access: Who can see the project's runtimes, cohorts, and deployments.
  • Cohort access: Who can see the devices in a specific cohort inside the project and open tunnels to them.

Project access gates cohort access: a member who can't access a project can't access any of its cohorts. Both levels support grants to individual users and to groups, and grants are additive: a member has access if any direct grant or any group they belong to gives it to them.

Organization owners and admins always have access to every project and cohort, regardless of grants. Project and cohort access applies to members with the member role. Creating and changing runtimes, cohorts, deployments, and devices requires the owner or admin role. See Team for what each role allows.

Restrict a project or cohort​

By default, a new project is open to every member of the organization, and a new cohort is open to everyone with access to its project. To restrict a project, open it, go to Settings, turn off Organization-wide access, and add the members or groups who should keep access. Cohorts work the same way from their own Settings page. You can also turn the setting off when you create the project or cohort.

Only owners and admins can change access.

Common patterns​

  • Small teams: Leave projects open to everyone, and restrict only the production cohort.
  • Larger organizations: Create a group per team and grant each group the projects and cohorts it works on.
  • Least privilege: Grant each person or group the smallest set of projects and cohorts they need.

Manage access with the API​

Grant access by user ID or group ID:

# Project access
curl -X POST "https://connect.peridio.com/api/orgs/$ORG_ID/projects/$PROJECT_ID/access/users" \
  -H "Authorization: Bearer $AVOCADO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"user_id": "<USER_ID>"}'

curl -X POST "https://connect.peridio.com/api/orgs/$ORG_ID/projects/$PROJECT_ID/access/groups" \
  -H "Authorization: Bearer $AVOCADO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"group_id": "<GROUP_ID>"}'

# Cohort access
curl -X POST "https://connect.peridio.com/api/orgs/$ORG_ID/projects/$PROJECT_ID/cohorts/$COHORT_ID/access/users" \
  -H "Authorization: Bearer $AVOCADO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"user_id": "<USER_ID>"}'

curl -X POST "https://connect.peridio.com/api/orgs/$ORG_ID/projects/$PROJECT_ID/cohorts/$COHORT_ID/access/groups" \
  -H "Authorization: Bearer $AVOCADO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"group_id": "<GROUP_ID>"}'

Revoke a grant with DELETE on …/access/users/<USER_ID> or …/access/groups/<GROUP_ID>. To turn organization-wide access off, update the project with PUT /api/orgs/$ORG_ID/projects/$PROJECT_ID and the body {"project": {"everyone_enabled": false}}. For a cohort, send {"cohort": {"everyone_enabled": false}} to PUT …/projects/$PROJECT_ID/cohorts/$COHORT_ID. See the Projects & Cohorts API for every endpoint.