Access control
The organization roles themselves, viewer, developer and admin, and how people join, are on Team & roles. This page is about narrowing a role per cluster or per project.
One organization usually holds every environment a team runs: production and staging on
different clusters, or shop-prod and shop-dev side by side on one. The team, the domains,
the templates and the invoice all live there. Access control lets that one organization say who
may see and change each cluster and each project, so production does not have to become a
second organization to be safe.
Two controls
An access level on every cluster and every project says how far the organization's roles reach into it:
| Level | Organization admins | Developers and viewers | Members with a grant |
|---|---|---|---|
| Open (the default) | full access | their organization role | the higher of the two |
| Protected | full access | can look, not touch | their granted role |
| Restricted | full access | cannot see that it exists | their granted role |
A grant names one member, one service token, or one team, who holds
developer or viewer on a cluster or a project whatever its level says. A grant to a team is
held by everyone in it. Grants only ever add: a developer granted viewer
on an open project is still a developer there. To make people read-only, protect the thing;
to let three people through, grant them.
Organization admins are unaffected by all of it. They hold the agent token, the billing and the member list already, so a level that shut them out would only be theatre. What guards against an admin is the audit log: every level change and every grant is recorded with who did it.
A cluster's level applies to its projects
A project is evaluated through its cluster. Protect the cluster and every project on it is
read-only for the organization, whatever the project says. Restrict the cluster and its
projects disappear with it. A project cannot be more open than its cluster, but a grant reaches
through: someone granted developer on a restricted cluster can work on every project of it, and
someone granted on one project of a restricted cluster sees that project and the cluster's name
and connectivity, nothing else.
Previews follow the project they were made from. Templates are visible to the whole organization and take no level: capturing a project as a template is a deliberate publication.
What Protected means
Protected is exactly the viewer experience. A protected project renders the same way for an organization developer as every project does for an organization viewer: the configuration is readable, logs and metrics stream, but there is no deploy, no edit, no secret value and no terminal. Logs can carry whatever an app prints, so if "read-only" is not enough for a project, make it Restricted.
What Restricted means
A restricted cluster or project is absent from every list, from search and from the sidebar, and its URL shows the ordinary not-found page. Its events do not reach the bell or the live feed. The one thing it cannot hide is its name: creating a project with the same name on the same cluster is refused as taken, without saying why.
Setting it up
In the console, Settings → Access on a cluster or a project has the level and the grants; the members page shows what each person has been granted beyond their role. Anything that takes access away asks first: making something protected or restricted, and revoking a grant, each say what changes for whom before it happens. Opening access up applies at once. From the terminal:
anyport access show prod-eu
anyport access set-level prod-eu protected
anyport access grant prod-eu/shop alice@example.com --role developer
anyport access grant staging github-actions --role developer
anyport access grant prod-eu team:platform --role developer
anyport access list --member alice@example.comA service token is a member, so it takes a grant like anyone: a token that is an organization
viewer with developer on staging is a least-privilege deploy key.
Marking a project as production suggests protecting it, once. It never does so on its own;
the environment is a label, the level is the policy.
Config as code
The level travels in the project's anyport.yaml as accessLevel, so a repository that
recreates a production project recreates it protected. Grants do not: they name people, and
a file applied from a repository must not be able to grant anyone access. Applying a file that
changes a level needs an organization admin; anyone else's apply lands everything else and
stops there, naming the level it could not set.