Access profiles

An access profile is a named set of environment roles, such as "Developers: Editor on every development and staging". Instead of granting the same environments to each new developer one by one, you add them to the access profile. When the access profile changes, everyone in it gets the change.

Example. Kiteline is a fictional company. Its Developers access profile makes members Editors on development and staging of payments-api and web-app, and gives no access to production. Jonas joins through this access profile and can work in staging right away.

Creating an access profile

Open Access profiles and choose New access profile. Give it a name, then Add environments…. The picker shows role cards, Editor, Reader, Specific files and Operator, and a matrix of projects by environments. Quick picks such as All development select a whole column. (whole project) selects every environment of one project.

Only owners and admins manage access profiles.

Using an access profile

• When inviting. The Invite member dialog lets you pick access profiles. The new member gets their environments when you confirm them.
• For an existing member. Add the member to the access profile.
• Changing an access profile. Add or remove environments, or change a role. Everyone in the access profile gets the new access.

On a member's page, the Environment access matrix marks access that comes from an access profile as via access profile, separately from direct grants and grants made by request.

When a change takes someone out of an environment where they had the key, that environment is marked as needing rotation, as with any removal. See Rotate environment keys.

Why access profiles are signed

The server stores access profiles, but it isn't trusted with them. If the server could quietly add production to an access profile, it would only need to wait until an admin added someone to that access profile, and the admin's own app would then seal the production key to that person.

So every version of an access profile is a document signed by the owner or admin who changed it. The access profile's page shows the version and who signed it. Versions form a chain:

• each version has a number one higher than the previous one and refers to the previous version's hash;
• the app applies an access profile's grants only from a version whose signature and chain it has verified;
• your device remembers the latest version it verified and rejects an older one, or a different version with the same number.

An invitation refers to the exact access profile version its creator saw. When an admin confirms the new member, their app finds that version and checks the chain from it to the latest. It applies the latest version's grants, because an owner or admin signed that one too.

Access profiles and roles

An access profile grants environment roles. It doesn't change anyone's organization role. Members, admins and owners can all be in an access profile. Admins and owners reach shared environments through the organization recovery key anyway, so an access profile matters most for members.

A member can be in several access profiles and also have direct grants. Each environment has one role per person in its access list.

When someone leaves

Removing a member from the organization takes them out of every access profile, together with their direct grants. The member removal wizard shows this in its plan. See Offboarding a teammate.

For production, consider granting access directly or through access requests rather than through a broad access profile. Every grant made through an approved request is recorded with its reason.

Limits

An environment access list holds up to 5,000 entries. An access profile is applied by writing ordinary access entries, so the same limit applies.

There are no time limits on access granted through an access profile. To make access temporary, remove the member from the access profile when the work is done.